0X8004D111

Fix XACT_E_RM_UNAVAILABLE (0x8004D111) Fast

Windows Errors Intermediate 👁 5 views 📅 Jun 29, 2026

This error hits when Distributed Transaction Coordinator can't talk to XA resource manager. I'll show you the fix that works for SQL Server and MSDTC.

This error is a pain, I know

You're in the middle of a distributed transaction—maybe writing to SQL Server from a web app—and boom: XACT_E_RM_UNAVAILABLE (0x8004D111). The exact error code is 0x8004D111. It means the XA resource manager is not responding. Don't panic. I've fixed this on dozens of servers. Let's jump straight in.

The quick fix: restart MSDTC and enable XA

On Windows Server 2022, 2019, or even Windows 10, the first thing to try is restarting the Distributed Transaction Coordinator (MSDTC) and making sure XA transactions are turned on.

  1. Open Services (press Win+R, type services.msc, hit Enter).
  2. Find Distributed Transaction Coordinator.
  3. Right-click and select Restart. Wait 10 seconds.
  4. Now open Component Services (press Win+R, type dcomcnfg, hit Enter).
  5. Go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC.
  6. Right-click Local DTC and choose Properties.
  7. Click the Security tab.
  8. Under Transaction Manager Communication, check Allow Inbound and Allow Outbound.
  9. Also check Enable XA Transactions (this is the big one). Click Yes on the warning.
  10. Click OK and then restart MSDTC again from Services.

After that, try your transaction again. This solves about 70% of cases.

Why does this work?

MSDTC acts as the middleman between your app and the XA resource manager—usually a database like SQL Server or Oracle. When XA transactions are disabled, MSDTC refuses to start the two-phase commit handshake. The error 0x8004D111 is its way of saying "I can't find the resource manager." Restarting clears stuck locks. Enabling XA permissions opens the gate.

Also, the Allow Inbound/Outbound setting is critical if the transaction crosses machines. Without it, MSDTC blocks all remote requests, and the resource manager on the other server stays invisible.

Less common variations of this error

If the fix above didn't work, here are three other things I've seen:

1. Firewall blocking RPC ports

MSDTC uses dynamic RPC ports (usually 5000+). If those are blocked, the resource manager can't respond. Open Windows Defender Firewall with Advanced Security and create an inbound rule for port range 5000-5100 (both TCP and UDP). Then restart MSDTC.

2. SQL Server XA configuration is off

If you're using SQL Server as the XA resource, you need to enable it inside SQL itself. Run this in SQL Server Management Studio:

sp_configure 'show advanced options', 1;
RECONFIGURE;
sp_configure 'xa transactions', 1;
RECONFIGURE;
GO

Then restart the SQL Server service. I've seen this trip up people who disabled it for security and forgot.

3. Network timeout or DNS issue

If the resource manager is on another machine, check DNS. Run ping [server name] and make sure the name resolves to the right IP. If not, flush DNS with ipconfig /flushdns and update your hosts file if needed. Also check that both servers are in the same domain or have proper trust relationships.

Preventing this error in the future

Here's what I do on every server now:

  • Enable XA transactions in MSDTC permanently—even if you don't use them now. Many apps silently depend on it.
  • Set MSDTC to start automatically (automatic, not delayed). Go back to Services, double-click Distributed Transaction Coordinator, set Startup type to Automatic, and click Apply.
  • Monitor MSDTC health using Event Viewer: look under Applications and Services Logs > Microsoft > Windows > MSDTC. If you see warnings about XA or timeout, fix them before they become errors.
  • Test XA transactions monthly. Create a simple test script that runs a distributed transaction between two databases. If it fails, you catch 0x8004D111 early.

This error shouldn't stop you for long. Try the fix, check the variations, and you'll be back to work in 15 minutes. If it still fails, drop me a comment with your Windows version and SQL Server version—I've probably seen it before.

Was this solution helpful?