Fix 0XC0190025: Can't Open Miniversion With Modify Intent

Quick Answer

Restart the Volume Shadow Copy service and close any database applications (like SQL Server or Exchange) that hold a write lock on the volume. If that fails, run vssadmin list writers and restart the failing writer service.

Why You're Seeing This Error

This error—0XC0190025: STATUS_CANT_OPEN_MINIVERSION_WITH_MODIFY_INTENT—pops up when something tries to open a shadow copy (a "miniversion" in Microsoft's terminology) with write permission, but the snapshot is read-only or locked by another process. I've seen this most often with SQL Server databases during VSS-based backups. A client last month was backing up a SQL 2019 database using Windows Server Backup, and every night it threw this error. The database was fine, but the backup kept failing because SQL's VSS writer was holding a write lock on the volume's shadow copy.

The root cause is almost always a VSS writer that's in a bad state—it thinks it still has a pending write operation on the snapshot. Less common scenarios: a file system filter driver (like antivirus or backup software) interfering, or a corrupted shadow storage area.

Fix Steps (In Order)

1. Identify the locking process. Open Event Viewer, go to Applications and Services Logs / Microsoft / Windows / VolumeShadowCopy. Look for events with ID 13 or 21 around the time of the error. They'll tell you which VSS writer or file is causing the issue.
2. Run vssadmin list writers in an elevated command prompt. Look for any writer with a state other than "Stable." A writer in "Failed" or "Waiting for completion" state is your culprit.
3. Restart the failing writer's service. For SQL Server, that's SQL Server VSS Writer. For Exchange, it's Microsoft Exchange Information Store. In the client's case, restarting the SQL VSS Writer service fixed it immediately.
4. If no writer is broken, restart the VSS service itself. Run net stop vss /y then net start vss from an admin prompt. This will interrupt any running backups, so do it during a maintenance window.
5. Clear the shadow copies on the affected volume. Run vssadmin delete shadows /for=C: /all (replace C: with your drive). This removes all existing snapshots and forces the system to create fresh ones.

Alternative Fixes If the Main One Fails

• Disable antivirus real-time scanning on the volume's shadow copy storage area. VSS writes to C:\System Volume Information. If your AV is scanning that folder, it can cause lock conflicts. Temporarily disable the AV and retry the backup.
• Run sfc /scannow to check for corrupted system files that might affect VSS. I've seen a corrupted vssvc.exe cause this error on Windows Server 2016.
• Use chkdsk on the volume. Disk errors can make VSS think a snapshot is corrupt and refuse write access. Run chkdsk C: /f and restart.
• If you're using a third-party backup tool (like Veeam or Acronis), check if it has a specific VSS integration setting. Sometimes disabling the app's VSS writer registration and letting Windows handle it resolves the conflict.

Prevention Tips

• Keep VSS writers updated. For SQL Server, install the latest cumulative update—Microsoft fixes VSS-related bugs regularly.
• Don't let shadow copies fill the storage area. Set a maximum size for shadow storage (vssadmin resize shadowstorage /for=C: /on=C: /maxsize=10GB). A full storage area can cause this error during backup.
• Schedule backups during low-activity periods when databases aren't processing heavy transactions. The fewer open write handles, the less likely VSS writers will conflict.
• Monitor Event Viewer for VSS warnings (ID 13, 21, 36) before they escalate into full errors. Catching a writer in "Waiting for completion" early can save you a failed backup later.

In my experience, 90% of these errors come from a single VSS writer that needs a kick. Restarting the writer's service is your first and best move. Don't waste time digging into registry hacks or reinstalling VSS—keep it simple and you'll be back in business in five minutes.