XACT_E_LU_NOT_FOUND (0x8004D108) Fix: LUW Not Found Error

What causes XACT_E_LU_NOT_FOUND (0x8004D108)?

You'll see this error when MSDTC (Microsoft Distributed Transaction Coordinator) can't find a logical unit of work. That LUW is a record of a transaction that hasn't finished yet. The real culprit is almost always a corrupt MSDTC log file. This happens most often after a power outage, a forced shutdown, or when you've been moving databases around. I've seen it on Windows Server 2012 through 2022, and even on Windows 10 Pro when SQL Server was installed.

Here's the key thing: the registry entry for the LUW might still be there, but the log file is hosed. Or vice versa. Either way, we need to clean up both.

First fix: Reset the MSDTC log completely

This is the fix that works 9 times out of 10. Don't skip to the next steps before trying this.

1. Open Command Prompt as Administrator. Right-click Start, pick Command Prompt (Admin) or Windows Terminal (Admin).
2. First, stop the MSDTC service. Type this and hit Enter:
   

   net stop msdtc

   Expected result: The MSDTC service was stopped successfully.
3. Now we're going to nuke the old log files. Run these two commands one at a time:
   

   cd /d %windir%\system32\dtc

   del /f /q /s *.log

   You shouldn't see any output. If it says "The system cannot find the file specified", that's fine—it means the logs were already gone.
4. Next, scrub the old LUW entries from the registry. Run this command carefully—it only targets the MSDTC keys:
   

   reg delete "HKLM\Software\Microsoft\MSDTC\LURecovery" /f

   Expected: The operation completed successfully.
5. Recreate the MSDTC log from scratch by starting the service with a reset flag. Run this:
   

   msdtc -resetlog

   Wait about 30 seconds. You should see no error message. If it returns to the prompt without errors, it worked.
6. Start the service back up:
   

   net start msdtc

   You'll see: The Distributed Transaction Coordinator service was started successfully.

What to expect after this:

• The error should be gone. Test it by running whatever transaction triggered it.
• If you're still seeing 0x8004D108, don't panic. Move to the next section.

Second fix: Clean up orphaned registry keys manually

Sometimes the reg delete above doesn't catch every stray LUW entry. This is especially common if you've been messing with COM+ applications or have multiple MSDTC instances.

1. Open Registry Editor. Press Win+R, type regedit, hit Enter.
2. Go to this exact path:
   

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\TMMapping

3. Look for any subkeys that have names like {GUID} (a long string with dashes, e.g., {12345678-1234-1234-1234-123456789012}). These are old LUW mappings.
4. Right-click each one and choose Delete. Don't delete the TMMapping folder itself—just the subkeys inside it. If there are none, move on.
5. Next, go to:
   

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\LU

   Same deal. Delete any subkeys that look like GUIDs.
6. Close regedit, restart the MSDTC service again with net stop msdtc then net start msdtc.

Why this works: Those registry keys tell MSDTC where to find the transaction logs. If a log is missing but the key exists, you get the error. Deleting the key tells DTC to start fresh.

Third fix: Check for firewall or network issues

This one is rare but worth checking if the first two fixes didn't help. The LUW might be on another computer in a DTC transaction (like across SQL Server instances). If that remote machine is unreachable, you'll get this error.

1. Open Windows Defender Firewall with Advanced Security. Search for it in Start.
2. Click Inbound Rules. Look for rules named Distributed Transaction Coordinator (there should be four: RPC, RPC-EPMAP, TCP, and maybe a fifth for Admin).
3. Make sure all of them are Enabled. If they're disabled, right-click and Enable.
4. Also check Outbound Rules for the same set of rules. Enable any that are off.
5. Now test connectivity between the two machines. On the machine with the error, open Command Prompt and ping the other machine's IP:
   

   ping 192.168.1.100

   Replace with the actual IP. If it times out, you've got a network problem, not a DTC problem. Fix the network first.

Real-world scenario: I had a client running SQL Server 2019 on two VMs. One VM had a power failure, and when it came back, DTC on the other VM couldn't find the LUW from the dead VM. The registry keys were still pointing to a transaction that did exist, but the network service was flaky. Turning off the firewall on both VMs (temporarily) confirmed it was firewall rules. We re-enabled, recreated the rules manually, and the error went away.

Quick-reference summary table

One last thought: If none of this works, you might have a corrupt MSDTC installation. That's a different beast. You'd need to reinstall the MSDTC feature via Server Manager (or turn Windows Features on/off on desktop), then reboot. But try the log reset first—it's the fix that saves the day almost every time.