XACT_E_LU_RECOVERY_MISMATCH (0X8004D110) Fix

Simplest Fix: Restart the MSDTC Service (30 seconds)

This clears the in-memory recovery state. Nine times out of ten, that's all you need.

1. Open an admin Command Prompt or PowerShell.
2. Run:

   net stop msdtc && net start msdtc

3. Test your transaction again.

If you're on a cluster, do this on every node that hosts the MSDTC resource. Don't bother restarting the whole server — that's overkill and wastes everyone's time.

Still broken? Move to the moderate fix.

Moderate Fix: Reset MSDTC Log and Cluster Resource (5 minutes)

When the log file itself is corrupt or has a stale recovery record, restarting won't cut it. Here's the real fix:

1. On each cluster node, stop MSDTC:

   net stop msdtc

2. Delete the log file. Path:

   C:\Windows\System32\MSDTC\msdtc.log

   Just delete it — MSDTC recreates it on startup. Make sure you're not deleting the folder, only the .log file.
3. On the active cluster node, start MSDTC:

   net start msdtc

4. Then bring the MSDTC cluster resource online in Failover Cluster Manager. Right-click it -> Bring Online.

If that fails to come online, you've got a deeper issue — move to the advanced fix.

Advanced Fix: Cluster Resource Metadata Cleanup (15+ minutes)

This is for when the cluster resource itself has cached a bad recovery state. I've seen this happen after a node was forcefully removed from a cluster and then added back.

1. Open Failover Cluster Manager.
2. Navigate to your MSDTC resource. Right-click it -> Properties.
3. Go to the Advanced Policies tab. Set Possible Owners to only the single node that's currently online.
4. Take the resource offline:

   Stop-ClusterResource "Your MSDTC Resource Name" -Force

5. Clear the private properties that point to the old recovery log:

   Get-ClusterResource "Your MSDTC Resource Name" | Clear-ClusterParameter LogPath

6. Bring it back online:

   Start-ClusterResource "Your MSDTC Resource Name"

7. If it works, add the other nodes back as possible owners.

Still failing? You might need to delete and recreate the MSDTC resource entirely.

Warning: This will drop all in-flight distributed transactions. Make sure the application is stopped first.

Technical background: The XACT_E_LU_RECOVERY_MISMATCH error means MSDTC's local recovery log says "I was coordinating transactions with this LU (logical unit)", but the actual LU partner (like SQL Server) doesn't match. This mismatch is a classic symptom of a cluster failover where the log wasn't properly migrated, or the MSDTC instance was started on a node that had a stale copy of the log.

Common scenario: SQL Server Availability Group listener moves, MSDTC resource follows, but the log on the new node is from an older restart. Deletion + restart fixes it.

One more thing — check Windows Event Log under Applications and Services Logs > Microsoft > Windows > MSDTC. If you see Event ID 4159, that confirms the mismatch. If you see Event ID 4097, you've got a corrupted log — go straight to the moderate fix and skip the simple restart.