Fix ERROR_RM_ALREADY_STARTED (0X00001AA6) on Windows

Quick answer (for advanced users)

Stop and restart the MSDTC service from an admin command prompt: net stop msdtc && net start msdtc. If that fails, clear the MSDTC log with msdtc -resetlog.

What's actually happening

ERROR_RM_ALREADY_STARTED (0X00001AA6) shows up when your system tries to initialize a transactional resource manager—usually the Microsoft Distributed Transaction Coordinator (MSDTC) or the Kernel Transaction Manager (KTM)—but that manager is already running. This commonly happens on Windows Server 2019 and Windows 10/11 after a service crash, a failed update, or when a database application like SQL Server or a .NET app using System.Transactions calls TransactionManager.RecoveryComplete() twice.

The root cause is that the resource manager's internal state machine got stuck in an inconsistent state. Windows tracks these managers in the registry under HKLM\SYSTEM\CurrentControlSet\Services\MSDTC and in the KTM log files. When something goes wrong—a power loss, a hung service, or a buggy driver—the manager's start flag doesn't get cleared properly, so the next attempt to start it triggers this error.

Step-by-step fix

1. Open an admin Command Prompt — not PowerShell, the old cmd.exe works best here because net stop behaves more predictably. Right-click Start > Command Prompt (Admin).
2. Stop MSDTC: net stop msdtc. If it's hung, use taskkill /f /im msdtc.exe instead.
3. Reset the MSDTC log: msdtc -resetlog. This wipes the log files in C:\Windows\System32\MsDtc\Log and resets the registry state. The reason step 3 works is that msdtc -resetlog doesn't just delete bytes—it creates a fresh log file and clears the RM_NODE_STARTED flag in the registry.
4. Start MSDTC: net start msdtc.
5. If you're dealing with KTM (common when using TransactionScope in .NET), you can restart the Kernel Transaction Manager by rebooting. KTM is a kernel driver, not a service—you can't stop it without a restart. To verify, check fltmc instances for ktm filter presence.

Alternative fixes if the main one fails

Scenario A: MSDTC won't start at all

Check the Event Viewer logs under Applications and Services Logs > Microsoft > Windows > MSDTC. Look for event ID 4159 or 4096. If you see Log file is corrupted, delete the log manually: del C:\Windows\System32\MsDtc\Log\*.* /q then run msdtc -install. This re-registers the service. You'll lose in-flight transactions—that's the cost.

Scenario B: Error comes from an app, not the service

If a specific app (like SQL Server or a custom .NET app) throws 0X00001AA6, the issue is that the app is calling ResourceManagerReenlistment or RecoveryComplete twice. The fix is code-side: wrap the recovery logic in a flag check. For SQL Server, restart the SQL Server service—it reinitializes its internal RM handle.

Scenario C: After Windows Update (KB5036892, 2024-05)

Some Windows 10 22H2 updates change MSDTC's security settings, which can cause an RM conflict. Open dcomcnfg, navigate to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC, right-click > Properties > Security tab, and enable Allow Remote Clients and Allow Inbound, then restart MSDTC.

Prevention

Don't let MSDTC stay running if you're not using distributed transactions. Set it to Manual startup in Services.msc. For developers: never call TransactionManager.RecoveryComplete() more than once. If you're using .NET's TransactionScope, the framework handles RM recovery internally—you don't need to touch it. Also, keep Windows updated but stagger updates: apply them to a test server first to catch regressions like KB5036892.

One more thing: If you're on a domain-joined machine, check Group Policy. Some domain policies pre-start MSDTC with a specific security configuration that can cause a double-start. Run gpresult /h gp.html and look for MSDTC policies under Computer Configuration.