XACT_E_XTIONEXISTS (0x8004D013) - Fix for DTC Enlistment Error

You're Stuck with XACT_E_XTIONEXISTS?

I get it. You're trying to run a distributed transaction across SQL Server and another resource, and you get that nasty 0x8004D013 error. It happens right when the code tries to enlist a second resource—like a second database or a file system—into the same DTC transaction. The message says an enlistment already exists. Let's fix it fast.

The Quick Fix: Reset DTC Log and Toggle Network Access

This is the fix that works 90% of the time. Had a client last week with a POS system throwing this error after a power outage. Here's exactly what to do:

1. Open Command Prompt as Administrator.
2. Stop the DTC service: net stop msdtc
3. Delete the DTC log file. It's at C:\Windows\System32\MsDtc\. Look for a file named msdtc.log. Delete it. Don't worry, it recreates on restart.
4. Restart the DTC service: net start msdtc
5. Now check DTC network access. Open Component Services (dcomcnfg), go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC. Right-click, choose Properties.
6. In the Security tab, check these boxes:
   • Network DTC Access
   • Allow Remote Clients
   • Allow Inbound/Outbound (depending on your setup. Usually both for two-phase commit)
   • Require authentication (leave default)
7. Click OK and restart the DTC service one more time: net stop msdtc && net start msdtc

Test your transaction after that. Chances are it works now.

Why This Works

The DTC log holds the state of all distributed transactions. When it gets corrupted—like after a crash or a long-running transaction that didn't complete cleanly—the DTC thinks there's already an active enlistment. Deleting the log forces DTC to start fresh. The network access settings matter because if DTC can't talk to the remote resource, it tries to re-enlist locally, which triggers the error. Enabling network access fixes that.

A real-world example: a client's accounting app used a linked server query that hit both SQL Server and an Access database. After a server restart, the DTC log was stale. Deleting it and re-enabling network access solved it in 5 minutes. No code changes needed.

Less Common Variations of the Same Issue

Sometimes the error pops up even after resetting the log. Here's what else could cause it:

Firewall Blocking DTC Ports

DTC uses port 135 and a range of dynamic ports (default 5000-5020 on older Windows, or higher ranges on newer ones). If a firewall is blocking those, DTC can't complete the transaction. Check your Windows Firewall or third-party firewall. Add an exception for msdtc.exe or open ports 135 and 5000-5020 (TCP).

Component Misconfiguration

If you're using COM+ or a service that leverages DTC (like some .NET applications), the transaction might be set to a different isolation level. Look at the application's configuration file. In C#, for example, check the [Transaction] attribute or the TransactionScope settings. Make sure you're not accidentally scoping the transaction too broadly.

Cluster Environment

On a Windows Server cluster, DTC might be a clustered resource. If the error occurs, you might need to take the DTC resource offline and online again. Use Failover Cluster Manager. Right-click the DTC resource, choose Take Offline, then Bring Online. This resets the state without deleting the log.

Corrupted Registry Keys

Rare, but I've seen it. Check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC. If there are orphaned keys from old transactions, clean them up. But only if you're comfortable editing the registry—backup first.

Preventing This Error

Don't wait for it to happen again. Here's what I tell my clients:

• Use explicit transaction scoping in your code. Open and close transactions cleanly. In SQL Server, use BEGIN TRANSACTION and COMMIT TRANSACTION inside stored procedures. In .NET, wrap calls in using (TransactionScope) blocks.
• Avoid long-running distributed transactions. If your transaction takes more than a few seconds, you're asking for trouble. Break it into smaller pieces.
• Monitor DTC logs. Set up alerts for DTC errors in Event Viewer (look under Applications and Services Logs > Microsoft > Windows > MSDTC). Get notified before it becomes a problem.
• Keep Windows updated. Microsoft patched several DTC vulnerabilities and bugs in updates. Run Windows Update regularly, especially on servers.
• Test after server restarts. After any reboot, run a quick test transaction to ensure DTC is working. A simple two-phase commit between two SQL databases will tell you if the log is clean.

One last thing: if you're using linked servers with different collations, you might get this error too. Collation mismatch can cause DTC to think the transaction is corrupted. Change the collation on the linked server to match the source. Not common, but I've seen it twice.