Fix ERROR_STREAM_MINIVERSION_NOT_FOUND 0x1A98 on Windows

When This Error Hits

You're running a backup job (maybe Veeam, maybe Windows Backup) or a database transaction against an NTFS volume, and boom — ERROR_STREAM_MINIVERSION_NOT_FOUND (0X00001A98). The exact message says "The specified file miniversion was not found for this transacted file open". I've seen this most often on Windows Server 2016 and 2019 during SQL Server VSS backups, or when a third-party backup tool tries to take a Volume Shadow Copy while a previous transaction is still dangling.

Root Cause — What Went Wrong

Windows uses a feature called Transactional NTFS (TxF) to let apps run multiple file operations as a single atomic unit. When a transaction opens a file, NTFS creates a miniversion (a snapshot of the file at that point). If the transaction crashes or doesn't commit properly, that miniversion reference gets orphaned. The next app that tries to open the same transacted file looks for the miniversion — and can't find it. That's your 0x1A98.

This is not a hardware problem. It's a software state issue. The fix is to either complete or abandon the stuck transaction. Rebooting sometimes works because the kernel cleans up orphan TxF objects on a fresh boot. But often you need to do it manually.

How to Fix ERROR_STREAM_MINIVERSION_NOT_FOUND

Skip the registry tweaks and disk checks — they don't fix this. Here's what actually works.

Step 1: Identify the Stuck Transaction

Open Command Prompt as Administrator. Run:

fsutil transaction list

This shows all active TxF transactions on the system. Look for a transaction with a State of Active that's older than a few minutes. If you see one, note its Transaction ID (a GUID like {A1B2C3D4-...}).

Step 2: Roll Back the Transaction

With the Transaction ID from Step 1, run:

fsutil transaction commit {TransactionID}

Or if you're sure it's dead:

fsutil transaction rollback {TransactionID}

I prefer rollback for orphaned transactions — it cleans up the miniversion references immediately.

Step 3: If fsutil Shows Nothing — Reboot

If fsutil transaction list returns empty but the error keeps happening, the transaction is likely held by a process that's already dead. Reboot the machine. This forces the kernel to release all orphaned TxF resources. On Windows Server, schedule a maintenance window — this is the nuclear option, but it's reliable.

Step 4: Disable TxF (If You Keep Hitting This)

If this error keeps coming back, the real fix might be to stop using TxF altogether. Microsoft deprecated TxF way back in Windows 10 1803. It's still there for compatibility, but you shouldn't rely on it for new apps.

For backup software: check if it has an option to use VSS without TxF. For custom apps: migrate to Volume Shadow Copy Service (VSS) or a database-level transaction instead.

What to Check If It Still Fails

• Check event logs — Look under Windows Logs > Application for event ID 513 or 514 from source Microsoft-Windows-Kernel-File. These log stuck transaction details.
• Third-party antivirus — Some AV hooks into transaction operations and causes miniversion corruption. Temporarily disable it (disconnect from network first) and test.
• NTFS corruption — Run chkdsk /f on the volume, but only after you've cleared all transactions. Running chkdsk on a volume with live TxF transactions can make things worse.
• Update your backup software — If this happens with the same app regularly, check for a patch. The app might be mishandling transactions.

This error tripped me up the first time I saw it on a production SQL server — I spent an hour running disk checks before I remembered TxF was the culprit. Now you know what to hit first. Good luck.