I know that 0XC0190039 error is infuriating — you're mid-install or mid-update, everything stops, and Windows gives you a cryptic message about a directory you've never heard of. Let's fix it.
What's Actually Happening
Windows uses a thing called Transactional NTFS (TxF) for file operations that need to be atomic — meaning they either fully complete or roll back completely. When an installer or update starts writing files, it creates transaction records under $Extend\$Txf on the volume. If the process crashes, gets killed by antivirus, or loses power mid-write, those transaction files stay behind. The next operation that needs a clean TxF state throws 0XC0190039 because the directory isn't empty.
The Fix (Do This First)
Boot into Safe Mode. You can't safely delete $Txf while Windows is running — the transaction manager will just recreate the lock or corrupt the volume.
- Hold Shift while clicking Restart from the Start menu.
- Troubleshoot → Advanced options → Startup Settings → Restart.
- Press 4 for Safe Mode.
- Open an elevated Command Prompt (right-click, Run as administrator).
Now check what's actually in there:
dir /a C:\$Extend\$TxfIf you see files with names like $TxfLog.blf, $TxfLogContainer00000000000000000001, or GUID-named entries, those are your stuck transactions. Delete the container files and GUID entries — leave the log files alone for now:
del /f /q C:\$Extend\$Txf\*On a system volume, Windows may block even Safe Mode deletion. If del gives you "access denied," take ownership first:
takeown /f C:\$Extend\$Txf /r /d y
icacls C:\$Extend\$Txf /grant administrators:F /tThen run the delete again. Reboot normally and retry your update or installer.
If That Doesn't Work: Use fsutil
Sometimes the transaction manager itself is holding a lock. You can force the TxF recovery:
fsutil resource info C:\
fsutil resource setautoreset true C:\That second command tells the resource manager to auto-reset on next boot if it finds inconsistencies. Reboot, then check the directory again.
Why This Works
The error is literal — the directory has to be empty for the new transaction to initialize. TxF doesn't clean up orphaned transactions from crashed processes on its own; it assumes the process will come back and finish. When it doesn't, you're left manually clearing the debris. Deleting the container files removes the stale locks; the $TxfLog files rebuild themselves from scratch on the next transaction.
Don't delete the entire $Extend folder. That houses the USN journal, quota data, and reparse point info. You'll break the volume and end up at a recovery prompt.
Less Common Variations
Error appears during Windows Update specifically
Windows Update has its own transaction layer. Stop the update services first, then clear $Txf:
net stop wuauserv
net stop bits
net stop cryptsvcAfter clearing $Txf, delete the software distribution cache:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.oldRestart the services and retry. I've seen this exact combo fix 0XC0190039 on Windows 10 22H2 and Windows 11 23H2 more times than I can count.
Error on a secondary data drive (D:, E:, etc.)
Run the same commands against that volume letter. You don't need Safe Mode for non-system drives, but you do need to make sure nothing is writing to the drive — close Explorer windows, stop any backup software, and kill sync clients like OneDrive or Dropbox from Task Manager first.
Error after a failed large installer (Adobe, Visual Studio, SQL Server)
These leave the worst TxF debris because they write thousands of transaction entries. After clearing $Txf, run:
chkdsk C: /f /rThis catches any half-written NTFS metadata the transaction left behind. Schedule it for next reboot if Windows won't run it live.
$Txf directory itself is missing or inaccessible
If dir says the path doesn't exist, the attribute is hidden at a level Explorer can't show. Use:
attrib -h -s C:\$Extend
attrib -h -s C:\$Extend\$TxfThen try the delete. If it still fails, the volume may need an offline repair — boot from Windows install media, choose Repair, and run chkdsk from the recovery environment.
Preventing It From Coming Back
- Turn off antivirus during big installs. Third-party AV (especially older Bitdefender and Kaspersky builds) intercepts file writes and kills transactions mid-flight. This is the #1 cause I see.
- Don't hard-power-off during updates. Let the "Working on updates" screen finish, even at 30%.
- Keep 15%+ free space on your system drive. TxF needs room to write transaction logs; a full drive causes partial rollbacks.
- Patch regularly. Microsoft quietly fixed several TxF cleanup bugs in cumulative updates through 2023 and 2024.
- If you use backup software that does volume snapshots (Veeam Agent, Macrium), make sure it's not running when you install updates. Snapshot VSS writers and TxF conflict more often than people realize.
Once $Txf is clear and the update or installer completes, you shouldn't see 0XC0190039 again unless something kills a transaction mid-write. If it returns within a week, the culprit is whatever's crashing your installs — check Event Viewer under Applications and Services Logs → Microsoft → Windows → TxF for the real story.