XACT_E_NORESOURCE (0x8004D00C) – No Resource for This Enlistment

Cause #1: MSDTC Security Configuration Is Wrong or Not Running

This is the culprit 80% of the time. The Distributed Transaction Coordinator service either isn't started, or its security settings block the resource manager from seeing the transaction. You'll see this error when a .NET app or SQL Server tries to promote a local transaction to a distributed one and fails because MSDTC isn't listening properly.

Check if MSDTC is running

Open services.msc, find Distributed Transaction Coordinator. If it's stopped, start it and set it to Automatic. Don't assume it's fine just because it's running—check the Log On tab: it should use the Network Service account, not Local System. Local System breaks network transactions every time.

Fix the security config

1. Run dcomcnfg, go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC.
2. Right-click Local DTC > Properties > Security tab.
3. Check these boxes:
   • Network DTC Access
   • Allow Remote Clients (if this is a client app calling a remote server)
   • Allow Inbound and Allow Outbound
   • No Authentication Required for quick LAN scenarios, or leave it on Mutual Authentication for domain-joined boxes. I've seen No Auth fix the issue faster when you're not in a domain.
4. Click OK, restart MSDTC.

Test by running a simple distributed transaction—like inserting a row into two SQL Server instances in the same transaction. If it works, you're done. If not, move on.

Cause #2: Stale or Orphaned Transaction Enlistments

Sometimes the resource manager (like SQL Server) holds onto a transaction enlistment that's already been committed or aborted. The next time a new transaction tries to use that same enlistment handle, boom—XACT_E_NORESOURCE. This happens after a crash, a forced kill of a transaction, or when a connection pool reuses a broken transaction context.

How to clear stale enlistments

For SQL Server specifically:

-- Check for active transactions
SELECT * FROM sys.dm_tran_active_transactions

-- Find any orphaned DTC transactions
SELECT * FROM sys.dm_tran_dtc_transactions

-- If you see stuck transactions, kill them with:
KILL 'transaction_guid'

-- Or purge all DTC transactions if you're sure it's safe:
EXEC sp_reset_connection

For COM+ applications, restart the COM+ application pool from Component Services. Right-click the app, Shut Down, then start it fresh. That clears any lingering enlistment handles. If you're dealing with a web app, recycle the app pool in IIS—that forces a new transaction context.

Check for connection pool corruption

If the app uses connection pooling, stale transaction contexts can get cached. Add Pooling=False to the connection string temporarily to test. If the error stops, you need to clear the pool programmatically with SqlConnection.ClearAllPools() or restart the app. But don't leave pooling off in production—it kills performance.

Cause #3: A Recent Windows Update Broke MSDTC

This one's sneaky. Microsoft has shipped patches that messed up MSDTC, especially the KB5004442 and its successors that tightened DCOM security. After installing those updates, older apps using DCOM calls to MSDTC suddenly fail with XACT_E_NORESOURCE. You'll see this on Windows Server 2016, 2019, and 2022.

How to confirm it's the update

Check the Application event log for event ID 7034 or 7031 from MSDTC. If you see those alongside the error, the patch is the problem. Also look for DCOM error 10016 in the System log—that's a dead giveaway.

The fix: adjust DCOM authentication level

1. Open dcomcnfg > Console Root > Component Services > Computers > My Computer > Properties > COM Security tab.
2. Under Access Permissions, click Edit Limits. Make sure ANONYMOUS LOGON has Remote Access allowed (add it if missing).
3. Under Launch and Activation Permissions, do the same—add ANONYMOUS LOGON with Remote Launch and Remote Activation.
4. Restart MSDTC and the COM+ app.

If that doesn't work, uninstall the offending update. Run wusa /uninstall /kb:5004442 from an admin prompt. Reboot. Then hide that update with the wushowhide.diagcab tool so it doesn't come back. I've had to do this on four customer servers this year alone.

Quick-Reference Summary Table

Start with MSDTC config—that's the low-hanging fruit. If it's not that, check for stale enlistments. Only go nuclear with patch removal if everything else fails. You'll have this fixed in 10 minutes, not 10 hours.