Fix XACT_E_WRONGSTATE (0x8004D011) on Windows

Yeah, this error is annoying

You're in the middle of something — maybe running a SQL Server script, maybe a COM+ component, maybe some custom app — and boom: XACT_E_WRONGSTATE (0x8004D011). The message says "This method was called in the wrong state." Doesn't tell you much, does it? Let me save you the headache.

The fix: Restart MSDTC or clear the stuck transaction

Nine times out of ten, this is a dead transaction that the Distributed Transaction Coordinator (MSDTC) hasn't released. Here's what you do:

Open Command Prompt as Administrator.
Run:
```
net stop msdtc
```
Then:
```
net start msdtc
```
If that doesn't work — and it sometimes doesn't — kill the stuck transaction manually. Run:
```
msdtc -resetlog
```
This clears the MSDTC log and resets its state. You'll lose any unresolved transactions, but that's usually fine in development or small business environments.
Reboot the machine to be safe.

Had a client last month whose entire print queue died because of a stuck MSDTC transaction from a billing app. Restarting the service fixed it in 30 seconds.

Why this works

XACT_E_WRONGSTATE is error code 0x8004D011. It happens when a transaction coordinator — usually MSDTC — is in a state that doesn't allow the method call you're making. Most common cause: a previous transaction didn't complete cleanly. The coordinator still holds a lock or a reference, and your new call sees the wrong state.

Restarting MSDTC forces the coordinator to release all locks and clear its internal state. Running msdtc -resetlog goes a step further by wiping the transaction log. Think of it like rebooting your router — same principle.

Less common variations

If restarting MSDTC doesn't fix it, check these:

1. SQL Server linked server transactions

If you're getting this error in SQL Server Management Studio when running a query across linked servers, the fix is often to kill the SPID that has the transaction open. Run:

KILL

Find the SPID with DBCC OPENTRAN. This is a SQL Server-specific variation — the transaction coordinator is SQL Server itself, not MSDTC.

2. COM+ application crashes

If you're writing a COM+ component and get this error, it's usually because you called Commit or Abort on a transaction that's already done. Fix: check your code for double commits. Use SetAbort and SetComplete correctly. One call per transaction, not two.

3. DTC security settings

On Windows Server, if MSDTC keeps getting stuck, check DTC security. Open Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC > Properties > Security. Make sure "Network DTC Access" and "Allow Remote Clients" are checked if you're working across machines.

Prevention

Once you've fixed it, here's how to stop it from happening again:

Set a transaction timeout. In MSDTC, you can set a timeout via registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\Timeout. Set it to something sane, like 60 seconds. This kills hung transactions automatically.
Monitor MSDTC logs. Use Event Viewer under Applications and Services Logs > Microsoft > Windows > Dtc. Look for warnings about long-running transactions.
Code hygiene. If you're writing apps that use transactions, always wrap them in try-catch-finally blocks. Ensure Commit() or Rollback() is called exactly once. I've seen too many developers forget the finally block and leave a transaction hanging.

Real talk: this error is rarely hardware or OS corruption. It's almost always a transaction that didn't finish. Restart MSDTC, kill the SPID, or fix your code. You'll be back up in minutes.

If none of this works — and I've only seen it fail twice in 10 years — then you might have a corrupted MSDTC installation. Reinstall it via Control Panel > Programs and Features > Turn Windows features on or off > uncheck Microsoft Distributed Transaction Coordinator, reboot, recheck it, reboot again. That's the nuclear option.