STATUS_TRANSACTIONMANAGER_NOT_ONLINE (0XC0190052) Fix

You boot a machine (or spin up a VM) and instead of a desktop you get a blue screen or a boot loop with STATUS_TRANSACTIONMANAGER_NOT_ONLINE and hex code 0xC0190052. That's the Kernel Transaction Manager telling you it can't bring its transaction log online. Something corrupted the KTM log, the TxF (transactional NTFS) journal, or a registry hive that depends on it.

I see this most often after a dirty shutdown — power cut during a Windows Update, a VM host that got hard-reset, or a laptop battery dying mid-write. Had a client last month whose entire SQL Server dev box went down this way after their UPS decided to take a nap during a cumulative update. The KTM log was toast. Took us 20 minutes to get back to a login screen.

Work through these in order. Stop as soon as you can boot.

The 30-second fix: cold power cycle (yes, really)

Half the time this error is transient. The KTM service failed to start during boot because of a race with a pending write. A full cold boot flushes it.

1. Shut the machine down completely. Not restart — shut down.
2. If it's a laptop, pull the charger. If it's a desktop or server, flip the PSU switch off or pull the cord.
3. Hold the power button for 15 seconds to drain residual charge.
4. Plug back in, boot.

For a VM: shut it down from the hypervisor, don't just reset it. If it won't respond, kill the VM process on the host and start it fresh. VMware Workstation and Hyper-V both cache VM state in memory that survives a reset — a full shutdown clears it.

If Windows comes up, run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth from an elevated prompt to catch any file damage that led to the corrupted log. Move on if it boots clean.

If it still won't boot, go to the next section.

The 5-minute fix: boot into WinRE and repair the KTM log

You need to get into the Windows Recovery Environment. From a boot loop, Windows usually offers it after three failed attempts. If not, force it by holding Shift while clicking Restart, or boot from Windows install media and pick Repair your computer.

Once you're at the recovery menu, choose Troubleshoot → Advanced options → Command Prompt.

Step 1: Identify your Windows drive

In WinRE, drive letters shift. The OS is rarely C:. Run:

diskpart
list volume
exit

Look for the volume with your Windows folder. Note the letter. I'll use D: in the examples below — swap for yours.

Step 2: Run chkdsk to clear dirty bits and rebuild the journal

chkdsk D: /f /r

The /f clears dirty bits and /r finds bad sectors. This is what actually fixes a corrupted NTFS transaction log the majority of the time. On a big drive this can take a while — don't skip it because it's slow. Feed it a coffee.

Step 3: Scan and repair system files offline

sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
DISM /Image:D:\ /Cleanup-Image /RestoreHealth

DISM needs a working source. If it complains, add /Source:E:\sources\install.wim /LimitAccess where E: is your install media.

Reboot. Most machines come back here. If yours doesn't, keep going.

The 15+ minute fix: rebuild the transaction log by hand

If chkdsk and SFC didn't do it, the KTM log itself is broken beyond automatic repair. The file lives in %SystemRoot%\System32\config\TxR and the KTM logs sit alongside it. We rebuild by removing the corrupt log and letting Windows recreate it — but only after backing it up, because if there's an in-flight transaction you care about, this can lose it.

Step 1: Back up the current logs

mkdir D:\KTM_Backup
copy D:\Windows\System32\config\TxR\*.* D:\KTM_Backup\

Step 2: Rename the corrupt KTM log

Boot back into WinRE command prompt. The KTM log files are *.blf (Common Log File System) and *.regtrans-ms files. Rename them so Windows starts with a clean slate:

cd /d D:\Windows\System32\config\TxR
ren *.blf *.blf.bak
ren *.regtrans-ms *.regtrans-ms.bak

Do the same for D:\Windows\System32\SMI\Store\Machine if it exists — that's where the registry's transactional hive shadows live.

Step 3: Check the KTM service startup type in the offline registry

Sometimes the service got disabled by a bad imaging tool or a GPO that landed wrong. Load the offline SYSTEM hive:

reg load HKLM\OfflineSystem D:\Windows\System32\config\SYSTEM

Then check:

reg query HKLM\OfflineSystem\ControlSet001\Services\KtmRm /v Start

You want Start to be 0x3 (manual) or 0x2 (automatic). If it's 0x4, that's disabled, which will absolutely cause this error. Fix it:

reg add HKLM\OfflineSystem\ControlSet001\Services\KtmRm /v Start /t REG_DWORD /d 3 /f
reg unload HKLM\OfflineSystem

Step 4: Boot and verify

Reboot. Windows should rebuild clean KTM logs on first boot. It'll feel slow on that first login — that's the KTM replaying and verifying. Give it a full five minutes before you panic.

After it's up, run:

fsutil resource info C:\

You should see the transaction manager listed as online. If it reports not online, the log directory is still broken and you're looking at restoring from a system image or doing an in-place repair install with setup.exe /auto upgrade /quickupgrade.

Things that don't help (skip these)

• Running startup repair repeatedly. It usually can't touch KTM logs. One pass to clear simple issues is fine, ten passes is a waste of time.
• System Restore from WinRE. It often fails when the error is active because the restore operation itself uses transactional NTFS. Don't count on it.
• Bootrec /fixmbr and /fixboot. Wrong problem. The MBR and boot sector are fine; the issue is in the OS transaction layer.
• Disabling the KtmRm service to "make it boot." You'll get an unbootable Windows that fails even harder the next time a transactional write happens.

If the disk is a cheap consumer SSD that's been in service 3+ years and this happened without a dirty shutdown, run chkdsk /r and then check SMART with wmic diskdrive get status. Failing flash is a common root cause and no amount of log surgery will hold if the NAND is on its way out.

If it's a VM specifically

Hyper-V and VMware can throw this error from inside the guest even when the guest disk is fine. Check the host first:

• Is the VHDX or VMDK on a network share or iSCSI LUN that just dropped? Reconnect storage, then boot.
• Did a snapshot get merged while the VM was running? Orphaned snapshot avhd files cause exactly this symptom in Hyper-V. Use Edit Disk → Merge to fix.
• VMware: check vmware.log in the VM folder for SCSI errors. A parent snapshot gone missing will show up there.

Once the host side is clean, the guest usually boots and the KTM log repairs itself.

Bottom line: cold boot, then chkdsk from WinRE, then manual log surgery. That order saves you the most time. If none of it works and the disk is healthy, an in-place repair install is faster than chasing the log further.