Fix 0x80030101: Storage Changed Since Last Commit

You're running a backup or System Restore point creation on Windows 10 Pro (build 19041+) or Windows Server 2016/2019/2022. Midway through, it chokes with STG_E_NOTCURRENT (0x80030101): "The storage has been changed since the last commit." This almost always happens when you've got multiple backup tools running — like Windows Backup plus a third-party tool (Acronis, Veeam), or after a disk defrag or partition resize while a VSS snapshot was still open. The Volume Shadow Copy (VSS) snapshot that was taken at the start of the operation no longer matches the disk state.

What Actually Causes This

VSS creates a point-in-time snapshot of the volume. If anything modifies the underlying storage between the snapshot creation and the commit step — even a file write or a metadata update from another backup — the snapshot is invalidated. The error code 0x80030101 specifically means the VSS writer detected the snapshot's storage location changed after the snapshot was taken. It's a safety feature, not a bug. But it's annoying because it usually kills the entire backup job.

The two most common triggers:
- Running a disk defrag (even the built-in Windows defrag) while a VSS snapshot exists.
- Another backup tool taking a snapshot on the same volume while one's already pending.

Step-by-Step Fix

Stop all backup jobs. Close any open backup software (Windows Backup, third-party tools). Don't skip this — stale writers keep the snapshot locked.
Open an elevated Command Prompt. Click Start, type cmd, right-click it, select "Run as administrator".
List all shadow copies: Run vssadmin list shadows. You'll likely see one or more old snapshots on the affected volume (e.g., C:).
Delete all shadow copies: Run vssadmin delete shadows /all. Confirm with 'Y'. This clears the VSS cache — no data loss, just removes old snapshots.
Reset VSS writers: Run vssadmin list writers. Note any writers in a "Stable" state — if any show "Failed" or "Not Responding", restart the Volume Shadow Copy service next.
Restart the VSS service: In the same cmd window, run
```
net stop vss
net start vss
```
Retry your backup or restore operation. If it still fails, proceed to the advanced check below.

That fixes about 90% of cases. The snapshot cache gets cleared, VSS writers reset, and the next backup creates a fresh consistent snapshot.

If It Still Fails After That

You've got something persistently locking VSS. Check these:

Check for competing backup schedules. Open Task Scheduler and look for any backup tasks overlapping. Stagger them by at least 30 minutes.
Disable Windows System Restore temporarily. Go to Control Panel > System > System Protection, select the drive, click Configure, then "Disable system protection". Reboot, then re-enable it. This forces a clean VSS reset.
Check disk health: Run chkdsk C: /f (replace C: with your volume). Bad sectors or file system corruption can cause VSS to bail with this error.
Third-party drivers: If you use antivirus with backup features (like McAfee or Norton), disable its backup module. They sometimes intercept VSS operations and clobber the snapshot.

One more thing: on Windows Server, if you're using deduplication, make sure you're running the latest cumulative update. Older builds (pre-2020) had a known bug where dedup volume operations could trigger this exact error during VSS backup.

If none of that works, you're likely dealing with a corrupt VSS writer. Open an admin cmd and run vssadmin list writers. If any writer is persistently in "Failed" state, note its ID and check Event Viewer under Applications and Services Logs > Microsoft > Windows > VSS for the specific error. That'll point you to a missing registry key or a corrupt COM class — but honestly, that's rare. 99% of the time, deleting shadows and restarting the service gets it done.