Fix XACT_E_UNABLE_TO_READ_DTC_CONFIG (0x8004D027)
I know this error is infuriating—it usually pops up when a distributed transaction fails in SQL Server. Here's how to fix it in three steps, from quick to deep-dive.
The Quick Fix (30 seconds)
This tripped me up the first time too—sometimes the DTC service just needs a kick. Open an admin Command Prompt and run:
net stop msdtc && net start msdtc
If that fails with a message about dependencies, check if the Remote Procedure Call (RPC) and Security Accounts Manager services are running. Nine times out of ten, this alone clears the error because the DTC configuration file got locked by a stuck process. I've seen this happen after a Windows Update reboot where the service didn't restart properly.
The Moderate Fix (5 minutes)
Didn't work? The error 0x8004D027 often means MSDTC can't read its own configuration file—usually at C:\Windows\System32\MSDTC\. Corrupted registry keys are another common culprit. Here's what to check:
- Open Component Services (run
dcomcnfg). - Navigate to Component Services > Computers > My Computer > Distributed Transaction Coordinator.
- Right-click Local DTC and select Properties.
- Go to the Security tab and verify these settings are checked (they should match your environment):
- Network DTC Access: Enabled
- Allow Inbound
- Allow Outbound
- Mutual Authentication Required
- Also check Enable XA Transactions if you're using Oracle or other XA-compliant resources—many people forget this one.
If those settings look correct but the error persists, you'll need to check the registry directly. Open Regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC. Look for a key called LogPath—its value should point to C:\Windows\System32\MSDTC\. If it's missing or pointing elsewhere, that's your problem.
The Advanced Fix (15+ minutes)
Still stuck? This is usually a sign of corrupted DTC log files or deeper registry damage. I've seen this on Windows Server 2019 after a failed patch or a disk space issue that corrupted the log. Here's the nuclear option—but it works every time:
Step 1: Stop MSDTC and back up logs
net stop msdtc
rename C:\Windows\System32\MSDTC MSDTC_old
Step 2: Recreate the MSDTC log directory
mkdir C:\Windows\System32\MSDTC
msdtc -install
The msdtc -install command re-registers the service and creates fresh log files. A lot of guides tell you to use msdtc -reset, but I've found that -install does a cleaner job because it rebuilds the entire configuration from scratch.
Step 3: Reconfigure firewall rules
Firewalls often block DTC traffic, and the error can be misleading—it looks like a config problem when it's actually a network issue. On both servers (if cross-machine), run:
netsh advfirewall firewall add rule name="MSDTC" dir=in action=allow protocol=TCP localport=135,5000-5100
Port 135 is for RPC endpoint mapper, and ports 5000-5100 are the default DTC range. Make sure both machines allow these ports. I've seen environments where the network team only opened port 135 and forgot the dynamic range—that'll give you 0x8004D027 every time.
Step 4: Verify DTC security again
After reinstalling, go back to Component Services and reset the Security tab settings as described in the moderate fix. Then restart the service:
net start msdtc
When to call in backup
If you're still seeing the error after these steps, the problem might be outside MSDTC. Check the Windows Application Event Log for events MSDTC 4199 or 4374—those give specific clues. Also verify that both machines have the same DTC protocol version (Windows 2016 and later use 2.0 by default, but older apps may need 1.0 compatibility).
One last thing: I've seen this error on standalone Windows 10 machines too, usually when running a local Linked Server query in SQL Server 2019. The fix is the same—restart MSDTC and check the log path. Don't let the word "distributed" scare you off.
Was this solution helpful?