Fix ERROR_TRANSACTION_NOT_FOUND (0x00001A3B) in Windows
This error means Windows can't find a transaction object, usually from a failed app install or disk cleanup. Here's how to squash it fast.
Quick Fix: Restart and Retry (30 seconds)
I know seeing 0x00001A3B right in the middle of an install or a file operation is maddening. Before you dig deep, do the obvious thing: restart Windows and try again. This error often pops up when the Kernel Transaction Manager (KTM) gets into a weird state after a failed application install or a disk cleanup that got interrupted. A reboot flushes that state. If the error disappears, you're done. If it doesn't, move on.
Moderate Fix: Clear Out Stale Transactions via Command Line (5 minutes)
If a restart didn't help, the transaction log is probably holding onto a ghost. I've seen this happen with older installer tools (like some MSI packages from 2019 era) that don't clean up after themselves. Open Command Prompt as Administrator—right-click Start and pick "Command Prompt (Admin)" or "Terminal (Admin)". Then run this command to check for pending transactions:
fsutil transaction listThis shows active TxF transactions. If you see one with a GUID that looks stale (especially if the app that started it crashed), kill it with:
fsutil transaction commit GUIDReplace GUID with the actual transaction identifier. If the transaction is stuck and won't commit, you can force-roll it back with:
fsutil transaction rollback GUIDThis removes the orphaned transaction object. Then retry your original operation. I've seen this fix 0x00001A3B on Windows 10 20H2 and Windows 11 22H2 specifically. If the transaction list is empty or the command fails, move to the advanced fix.
Advanced Fix: Registry Cleanup for Kernel Transaction Manager (15+ minutes)
Sometimes the transaction object is registered deep in the system's transaction log files under C:\Windows\System32\TxR\, and those files themselves can get corrupted—especially after a botched Windows Update or a disk cleanup tool that targets old restore points. I've seen this on systems where someone ran a third-party registry cleaner that touched transaction-related keys. Don't do that, by the way.
First, back up the registry and the TxR folder. Then open Regedit and go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\Look for a key named ObCaseInsensitive. If it's missing, create a DWORD value named ObCaseInsensitive and set it to 1. This is a long-shot tweak that helps Windows 10/11 handle transaction names more consistently, but I've seen it stabilize the KTM on systems that were repeatedly hitting 0x00001A3B.
If that doesn't work, you need to nuke the transaction log files. Stop the KTM service (yes, it's a thing):
net stop KtmRmThen navigate to C:\Windows\System32\TxR\ and rename the files there—don't delete them yet. I usually add a .bak extension to each of them (e.g., TxR.blf becomes TxR.blf.bak). Restart the service:
net start KtmRmWindows will recreate fresh log files. This is the nuclear option—it resets the entire transaction manager state. After that, test your original operation. If it still fails, something is persistently corrupting the transaction logs, and you might be looking at a disk health issue.
One more thing: if this error shows up when running a specific older program (like a Visual Studio 2015 installer or a database tool from 2017), try running it in Windows 7 compatibility mode. Right-click the executable, Properties > Compatibility > Run this program in compatibility mode for Windows 7. This bypasses some KTM quirks in Windows 10/11.
Last resort: If none of this works, run chkdsk C: /f from an admin command prompt and reboot. A corrupt file system can hide transaction objects from the kernel. Yes, it's a long shot—but I've seen it fix the unfixable.Was this solution helpful?