When does this error appear?
You'll see STATUS_TXF_METADATA_ALREADY_PRESENT (0X80190041) when your system or an app tries to start a new file transaction on a file that already has transaction data inside it. This is common with SQLite databases (like those used by Firefox, Chrome, or some backup tools) after a sudden power loss or crash. I've also seen it when restoring system state from a backup that wasn't fully flushed.
The exact scenario: your app calls CreateFileTransacted or WriteFileTransacted, but the target file still has leftover metadata from a previous transaction that wasn't cleaned up. The OS won't let you overwrite or supersede it—so you get this error code.
Root cause
Windows Transactional NTFS (TxF) marks files with metadata when a transaction starts. If that transaction gets interrupted (crash, forced reboot, storage removal), the metadata stays. On next attempt, the system sees it and blocks the new transaction. SQLite has a similar mechanism internally with its journal files—and if those get corrupted, same error pops up.
The fix is simple: remove the leftover transaction metadata. This usually means deleting a specific file or clearing a journal.
Fix steps
- Identify the file causing the problem. Check your app's error log or event viewer (Event ID 7031 or 7034 in System log). Look for file paths like
C:\Users\[username]\AppData\Local\*.dborC:\ProgramData\*.sqlite. If you're running a database tool, the error message will tell you the exact file. - Close the app that threw the error. If it's a system service, stop it via Services.msc (look for SQL Server, Windows Search, or similar).
- Delete the transaction metadata file. For SQLite databases, look for a
-journalor-walfile next to the main database (e.g.,mydb.sqlite-journal). Delete it. For TxF-related errors (rare in modern Windows), use this command in an elevated command prompt:
This clears the transaction metadata from the file's NTFS stream.fsutil resource setresume C:\path\to\file.db - If the file is locked, boot into Safe Mode with Networking (press F8 during startup) and try again. Or use a tool like Process Explorer to find what's holding the handle.
- Restart the app or service. The transaction should now start cleanly.
- In SQLite-based apps only, run a
PRAGMA integrity_checkon the database to confirm no corruption remains:
If it reports errors, restore from backup.sqlite3 mydb.sqlite "PRAGMA integrity_check;"
If it still fails
Check if the file is stored on a network drive or removable media—TxF doesn't work well there. Move the file to a local NTFS drive and try again.
Also verify you have full permissions on the file and its parent folder: right-click the folder > Properties > Security > Full Control for your user.
If you're doing this on a system file (like one in C:\Windows\System32), stop. Don't delete files there. Instead, run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth in an admin command prompt. Those will fix any corruption without removing transaction metadata manually.
Last resort: restore the file from a backup before the error started. TxF cleanup can be tricky, and sometimes it's faster to rebuild.