Transaction Manager Init Failure 0x1A32 — Fixes That Work
Your transaction manager won't start, usually because of a corrupted log file or bad registry key. Here's the exact fixes I've used for years.
Corrupted MSDTC Log File — The Usual Suspect
If you're seeing ERROR_TM_INITIALIZATION_FAILED (0X00001A32), nine times out of ten it's a corrupted Microsoft Distributed Transaction Coordinator (MSDTC) log file. This pops up when your system crashed during a transaction, the disk ran out of space, or someone force-killed the MSDTC service. Windows 10 / Server 2016+ systems hit this regularly after unexpected power loss.
Don't waste time reinstalling services. The fix is straightforward:
- Open Command Prompt as Administrator.
- Stop MSDTC:
net stop msdtc - Delete the log file:
del /f /q C:\Windows\System32\MsDtc\Msdtc.log - Restart the service:
net start msdtc
If the log file is locked (rare, but happens), boot into Safe Mode or use sc queryex msdtc to find the PID and kill it with taskkill /pid [PID] /f. Then delete the log.
After restarting, run msdtc -install to re-register the service components. That's it. The transaction manager will rebuild the log file fresh.
Registry Permissions Broken on MSDTC Node
When the log reset doesn't work, check the registry. A common cause: a third-party app or a botched security scan changed permissions on the MSDTC registry key. You'll see the error in Event Viewer under "Distributed Transaction Coordinator" with source "MSDTC" and event ID 4372.
Here's the exact path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC
Right-click the MSDTC key, go to Permissions. The SYSTEM account needs Full Control. Administrators group needs Full Control. Network Service needs Read. If those are missing, add them.
Quick fix when you're in a hurry:
regini c:\msdtc_perms.txt
Create a file msdtc_perms.txt with this content:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC [1 5 17]
Where 1 = Administrators, 5 = SYSTEM, 17 = Network Service. Run the command and restart the service.
If regini isn't available (it's deprecated in newer Windows builds), use PowerShell instead:
$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey('SOFTWARE\\Microsoft\\MSDTC', $true)
$acl = $key.GetAccessControl()
$rule = New-Object System.Security.AccessControl.RegistryAccessRule('SYSTEM','FullControl','Allow')
$acl.SetAccessRule($rule)
$key.SetAccessControl($acl)
Run that for Administrators and Network Service too. Reboot after.
Missing DTC Network Access or Firewall Block
Rarer but still common in domain environments: someone disabled DTC network access via Group Policy, or a firewall blocked the RPC ports. You'll see the error when trying to start a distributed transaction across SQL Server instances.
Check the MSDTC security settings:
- Open Component Services (dcomcnfg.exe)
- Expand Component Services > Computers > My Computer > Distributed Transaction Coordinator
- Right-click Local DTC > Properties
- Go to the Security tab
Enable these if they're off:
- Network DTC Access
- Allow Inbound
- Allow Outbound
- Mutual Authentication Required (unless your apps use older auth)
Apply and restart MSDTC. The service won't start if firewall rules block TCP port 135 (RPC Endpoint Mapper) and dynamic RPC ports (49152-65535). On Windows Firewall, run:
netsh advfirewall firewall add rule name="MSDTC RPC" dir=in action=allow protocol=TCP localport=135
netsh advfirewall firewall add rule name="MSDTC Dynamic" dir=in action=allow protocol=TCP localport=49152-65535
Don't bother with the "COM+ Network Access" setting — that's for COM calls, not DTC transactions. I've seen people waste hours on that.
Quick Reference Table
| Cause | Symptom | Fix |
|---|---|---|
| Corrupted MSDTC log | Error 0x1A32 on service start, event ID 4372 | Stop service, delete Msdtc.log, restart |
| Registry permissions | Error after security change, access denied | Fix ACLs on HKLM\SOFTWARE\Microsoft\MSDTC |
| DTC network disabled / firewall | Error in distributed transaction scenario | Enable DTC network access, open RPC ports |
Try those in order. 90% of you will be done after the first fix. The other 10% — check event logs for something more exotic like a disk driver failing or a system file corruption you can fix with sfc /scannow. But start with the log file. It's always the log file.
Was this solution helpful?