Fix ERROR_STREAM_MINIVERSION_NOT_VALID (0x00001A99) on Windows

This error is a pain — I've been there

I know how frustrating it is to see ERROR_STREAM_MINIVERSION_NOT_VALID (0x00001A99) pop up just when you need to access a critical file. It usually happens when you're trying to open a document over an SMB share or restore a previous version from a Volume Shadow Copy (VSS) snapshot. The file looks fine in Explorer, but the OS can't read the miniversion data. Let's get this sorted.

The fast fix: delete stale shadow copies

In 9 out of 10 cases, this error means your existing VSS snapshots are corrupted or inconsistent with the current file state. The quickest fix is to remove all shadow copies on the volume and create a fresh one.

1. Open Command Prompt as Administrator.
2. Type vssadmin delete shadows /all /quiet and press Enter. This wipes every shadow copy on the system.
3. Then run vssadmin list shadows to confirm the list is empty.
4. If you need a new restore point, create one manually: vssadmin create shadow /for=C: (swap C: for your drive letter).
5. Retry the operation that triggered the error. In most cases, it works immediately.

Why does this work? The error code 0x00001A99 specifically means the miniversion metadata exists but the data itself is invalid — think of it like a corrupted index in a library. Deleting all shadows forces Windows to rebuild that index cleanly from scratch. I've seen this fix work on Windows 10 22H2, Windows 11 23H2, and Windows Server 2019/2022.

When the simple fix isn't enough

If deleting shadow copies doesn't solve it, the problem might be deeper. Here are three variations I've run into over the years:

1. File-level corruption on an SMB share

This error can strike when you're opening a file from a network drive, especially on an older SMB protocol like SMB 1.0 or SMB 2.0. The miniversion data gets mangled during transfer. Check the server's event log for Event ID 59 or 50 — those point to disk I/O issues. On the client side, try accessing the file directly via \\server\share\path\file from a local admin prompt. If it still fails, copy the file to a local drive with robocopy /COPY:DAT /R:2 /W:5 and work on the local copy.

2. NTFS metadata corruption

Sometimes the file's alternate data streams (ADS) get scrambled. Run chkdsk /f /r C: from an elevated command prompt. Yes, you'll need a reboot. Let it scan the entire volume — it can take an hour on a large drive. Afterward, try accessing the file again. I've seen this fix work on a client's Windows Server 2016 file server where VSS snapshots kept failing silently.

3. Third-party backup software interference

Tools like Acronis, Veeam, or even older versions of Carbonite can leave orphaned miniversion markers. Temporarily disable any real-time file protection or backup agent, then delete the shadow copies again using the vssadmin steps above. Re-enable the software after and see if the error returns. If it does, update the backup software to its latest version — buggy VSS writers are a common culprit.

Prevention: stop it from coming back

Once you've fixed the immediate error, a few changes will keep it from recurring:

• Limit VSS snapshot storage. Set a maximum size using vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10GB. Too many snapshots increase the chance of metadata corruption.
• Update your SMB configuration. On Windows 10/11, run Set-SmbServerConfiguration -EnableSMB1Protocol $false and enable SMB 3.0 encryption if possible. This reduces transfer-induced errors.
• Run regular chkdsk. Schedule a weekly chkdsk /scan using Task Scheduler. It catches NTFS issues before they become file-level errors.
• Keep backup software current. If you use third-party tools, enable automatic updates. Old VSS writers are the sneakiest cause of this error.

I know this error can make you want to throw your laptop across the room, but it's almost always fixable without reinstalling Windows. Start with deleting shadow copies — that's the cure in the majority of cases. If you're still stuck after trying everything above, drop a comment on the original blog post and I'll help you dig deeper.