STATUS_CANNOT_EXECUTE_FILE_IN_TRANSACTION (0XC0190044) Fix

Cause #1: A SQL Server transaction hasn't committed or rolled back

This is the one I see most often. You're running a SQL script or a backup job, something crashes mid-way, and the transaction log has a file handle stuck in limbo. The OS uses Kernel Transaction Manager (KTM) under the hood, and SQL Server leans on it for certain file operations when it's doing things like VSS backups or DBCC checks.

Had a client last month whose nightly backup script failed halfway through because the SAN ran out of space. Next morning, every .mdf file in that database threw 0XC0190044 when they tried to run a simple SELECT. The backup process had created a transaction on the file, never rolled it back, and the OS was still holding the file as "in transaction".

Fix it: Commit or roll back the pending transaction

First, find the transaction ID. Open SQL Server Management Studio and run:

SELECT transaction_id, name, transaction_begin_time, transaction_type, transaction_state, dtc_state FROM sys.dm_tran_active_transactions WHERE transaction_state = 2

Transaction state 2 = active. If you see one that's been running for hours or days, that's your culprit. Note the transaction_id. Then find what it's doing:

SELECT session_id, transaction_id, open_transaction_count, is_user_transaction, database_id FROM sys.dm_tran_session_transactions WHERE transaction_id = [your_id]

If you get a session_id, you can kill it:

KILL [session_id]

That'll roll back the transaction and release the file handle. If the session is already dead but the transaction is still pending, you've got an orphaned transaction. In that case, run:

DBCC OPENTRAN

It'll show you the oldest active transaction. You can roll it back with:

KILL [transaction_id] WITH STATUSONLY

Wait—KILL with a transaction_id only works if you're in a distributed transaction (DTC). If it's a local transaction, you need the session_id. If DBCC OPENTRAN shows no open transactions but the file is still locked, jump to Cause #2.

Cause #2: A Windows update or installer left a file in a transaction

Windows uses KTM for things like Windows Update, MSI installers, and even some .NET framework updates. If a system update gets interrupted—power loss, forced reboot, disk full—the file stays in a pending transaction state. You'll see this with .exe and .dll files, especially in System32 or Program Files.

Real example: I had a client whose Windows Update got stuck at 30% for three hours. They hard-rebooted. Next boot, every time they tried to launch Chrome, they got 0XC0190044. The update had a pending transaction on chrome.dll.

Fix it: Use the System File Checker or clean the KTM transaction

Run SFC first—it's the low-hanging fruit:

sfc /scannow

If that finds corrupted files, it'll replace them. But SFC doesn't always clear KTM transactions. If SFC comes back clean, you need to dig into the Kernel Transaction Manager directly.

Open an elevated Command Prompt and check for pending transactions on the specific file:

fsutil transaction list

That'll show you active transactions. But fsutil doesn't give you the file path directly—it shows a GUID. To find the file, you need to use the Sysinternals tool handle64.exe (or handle.exe on 32-bit):

handle64.exe -a -p System | findstr /i "transaction"

That'll show you file handles being held in a transaction by the System process. Note the handle number. Then you can close it with:

handle64.exe -c [handle_number] -p [PID]

But be careful—closing the wrong handle can crash your system. A safer route: reboot into Safe Mode and run the Windows Update troubleshooter. More often than not, that'll force-close the transaction and let you delete or rename the file.

If it's a specific file you know is bad, you can also use the takeown and icacls commands to force ownership, then delete it. But if you delete a file that's in a transaction, you might break the transaction log for that volume. Only do this if you've got a backup.

Cause #3: Corrupted Registry key in the KTM transaction store

This one's rare but nasty. The Registry itself has a transaction store under HKLM\SYSTEM\CurrentControlSet\Control\KernelTransactionManager. If that gets corrupted—say, from a disk write error during a transaction—every file operation on the volume can trigger 0XC0190044.

I've only seen this twice in 15 years. Once on a Windows Server 2016 box that had a failing hard drive. The other time on a Windows 10 machine after a botched Registry cleaner tool (yes, those things are still around).

Fix it: Rebuild the KTM transaction store

This requires a Registry backup first—don't skip it:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\KernelTransactionManager" C:\backup_ktm.reg

Then delete the key entirely:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\KernelTransactionManager" /f

Reboot. Windows will recreate the key with default values on next boot. If the error persists, you've got deeper disk corruption—run chkdsk /f /r on the affected drive.

One important note: if you're running a SQL Server cluster or any application that uses KTM explicitly, deleting this key can break that application's transaction support until you reinstall the application. So only try this after exhausting Causes #1 and #2.

Quick reference summary table