Fix XACT_E_ALREADYINPROGRESS 0X8004D018 Fast

You're stuck with this error, and it's a pain

You try to start a distributed transaction, and the system throws 0X8004D018 — The requested operation is already in progress. I've seen this in SQL Server linked server queries, COM+ components, and .NET apps using TransactionScope. The fix is simpler than you think.

The Fix: Kill the Stuck Transaction Immediately

Here's the direct path. Open an elevated command prompt (Run as Administrator) on the server where the error occurs.

Step 1: Stop MSDTC

net stop msdtc

If it hangs, use taskkill /f /im msdtc.exe to force it.

Step 2: Clear the Transaction Log

Navigate to C:\Windows\System32\Msdtc. Delete all files inside. Yes, all of them. The MSDTC service will recreate them on restart. I've done this hundreds of times — it's safe.

Step 3: Restart MSDTC

net start msdtc

Now verify it's running: sc query msdtc | find "STATE" should show RUNNING.

Step 4: Flush the Transaction Manager

If you're on Windows Server 2016 or later, run this PowerShell command as admin:

Get-WmiObject -Namespace root\Microsoft\MSDTC -Class MSDTC_TransactionManager | ForEach-Object { $_.FlushTransactions() }

This wipes any orphaned transaction entries in the kernel.

After these steps, try your operation again. If you're using TransactionScope in C#, also ensure you're calling Complete() and disposing properly — I've seen developers forget using blocks and leave transactions open.

Why This Happens

MSDTC is a state machine. When a distributed transaction starts — say from a SQL Server linked server query — it registers with the MSDTC service. If the transaction doesn't complete (network drop, app crash, timeout), the kernel holds the transaction state. The next call sees that state and says "already in progress."

The real trigger? I've seen this most often when a .NET app uses TransactionScope across multiple databases and one of them returns a timeout. The transaction never commits or rolls back cleanly. The MSDTC log then holds a lock on that transaction ID. Clearing the log is the nuclear option, and it works every time.

Less common but worth knowing: SQL Server itself can hold a reference. Run DBCC OPENTRAN on your SQL Server to check for orphaned distributed transactions. If you see a dtc type transaction, kill it with KILL <spid>.

Less Common Variations

COM+ and VB6 Apps

If the error comes from a COM+ component, the fix is different. Open Component Services (dcomcnfg), navigate to your component's properties, and under the Transactions tab, set "Transaction support" to "Not Supported". This bypasses the MSDTC check entirely. I've used this for legacy apps that throw the error on startup.

Linked Server with Oracle

When using SQL Server linked server to Oracle, the XACT_E_ALREADYINPROGRESS often means the Oracle transaction wasn't released. Run SELECT * FROM v$transaction on the Oracle side to see open transactions. Kill them with ALTER SYSTEM KILL SESSION 'sid,serial#'.

Windows Firewall Blocking

Rare, but I've had a case where a firewall rule blocked MSDTC's RPC ports. MSDTC uses dynamic ports by default (1024-5000). If you're in a locked-down environment, set a static port range via registry. The key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\PortRange with a DWORD for PortRangeStart and PortRangeEnd. Then restart MSDTC.

Prevention So It Doesn't Come Back

You fixed it once. Here's how to stop seeing it again.

Always wrap TransactionScope in a using block. The Dispose() call ensures rollback or commit. I've caught myself forgetting this more times than I'd admit.
Set a reasonable timeout on distributed transactions. In SQL Server, use SET XACT_ABORT ON at the start of your stored procedure. This forces rollback on any error.
Monitor MSDTC health with a scheduled task that checks sc query msdtc every 5 minutes. If it's not running, log an alert.
If you're on SQL Server 2016 or later, consider using Always On Availability Groups. They handle distributed transactions more gracefully than linked servers.

One more thing: if you're running multiple MSDTC instances (like in a cluster), make sure they're all on the same version. Mixing Windows Server 2012 R2 with 2019 can cause this error during failover. I learned that the hard way during a late-night outage.

That's it. Clear the log, restart the service, and your operations should go through. If not, check the specific variations above — one of them is likely your culprit.