Objective
Restore a stable VSS state so Windows and application-consistent backups can run by identifying the writer or provider that is actually failing, checking shadow-storage capacity, and applying the smallest corrective action before rerunning the full backup job.
Prerequisites
- The exact backup-software error message, including code and failure time.
- Administrative access to the server and the Application and System event logs.
- A maintenance window if an application service or the server may need to be restarted.
- Available disk space and visibility into the configured shadow storage.
- A backup or rollback plan before changing a provider, VSS storage, or application configuration.
Step-by-step procedure
Collect the error before any retry
Keep the backup job report, VSS error code, and the phase where the backup fails. Record the time to the second when possible and inspect the Application and System logs around that time. Look for VSS, VolSnap, and application-writer events. This correlation prevents an unrelated older event from being treated as the current root cause.
- The error code and events from the same time window are preserved.
List VSS writers
Run vssadmin list writers and identify every writer whose state is not Stable or whose Last error is not No error. Record the exact writer name and ID. If no writer is listed, treat that as a separate symptom that can indicate an unregistered VSS component or a broader VSS service failure.
vssadmin list writers- Failing writers are identified precisely, or the complete absence of writers is confirmed.
List providers, shadow copies and shadow storage
Review installed providers, existing shadow copies, and shadow-storage associations. A third-party provider can interact with the Microsoft provider. Shadow storage that is too small, or a nearly full volume, can make snapshot creation fail. Do not delete anything at this stage; collect the current state first.
vssadmin list providersvssadmin list shadowsvssadmin list shadowstorage- The installed providers and the capacity reserved for shadow copies are known.
Check free space on the affected volumes
Check free space on the backed-up volume and the volume that hosts shadow storage. Look for recent growth in logs, snapshots, or temporary files. Free non-critical space when a volume is close to saturation. Do not resize shadow storage arbitrarily without first recording its current size and the server requirement.
Get-Volume | Select-Object DriveLetter,FileSystemLabel,Size,SizeRemaining- The volumes have enough free capacity to create a new shadow copy.
Map the failing writer to its service or application
Identify the component that provides the writer, such as System Writer, WMI Writer, Hyper-V VSS Writer, or SQL Server Writer. Review application-specific events and verify the relevant service state. Do not restart multiple services at the same time, because that removes the evidence needed to identify which corrective action actually worked.
Get-Service VSS,swprv | Format-Table Name,Status,StartType- The failing writer is mapped to a component and a probable cause is documented.
Apply the minimum corrective action
Correct the identified issue: insufficient space, a stopped service, an application error, a failing provider, or an unregistered component. If a supported service restart is appropriate, perform it during the maintenance window and then list the writers again. If several writers remain inconsistent with no precise cause, a planned server restart can be safer than a series of destructive VSS manipulations.
vssadmin list writers- The writers return to Stable with No error after the correction.
Handle the case where no VSS writer is listed
If vssadmin list writers returns no writers, review VSS events and follow the corresponding Microsoft guidance. This can be caused by a required component that is not registered and is not fixed by deleting snapshots. Check system integrity and updates before manually re-registering components with unvalidated scripts.
sfc /scannowDISM /Online /Cleanup-Image /ScanHealth- The absence of VSS writers is handled as a distinct diagnostic condition.
Test a small job or controlled snapshot
After the writers are stable, run a limited backup or the affected job while you can monitor the event logs. Confirm that the shadow copy is created and then released correctly. If the backup job uses additional application components, review their logs as well before declaring VSS healthy.
- The controlled test finishes without a new VSS error.
Rerun the full job and test a restore
Rerun the full backup job only after the short test succeeds. After the job completes, restore at least one test file or item to verify that the produced backup is usable. A job marked Success does not by itself guarantee application consistency; keep the restore result with the incident record.
- The full backup job succeeds and a test restore is possible.
Document the cause and preventive action
Record the affected writer, error code, corrective action, and relevant capacity values. For a recurring incident, add capacity monitoring, update the backup agent or provider, or schedule periodic writer checks. Avoid scheduled tasks that automatically purge every shadow copy in response to any VSS error.
- The root cause and preventive action are added to the operational documentation.
Validation
The procedure is validated when:
- vssadmin list writers returns the expected writers in Stable state with No error.
- Shadow storage and the affected volumes have sufficient capacity.
- A test job and then the full backup job complete without a VSS error.
- A controlled restore succeeds from the resulting backup.
Rollback
- Restore the previous shadow-storage configuration if it was changed and documented before the intervention.
- Re-enable services that were stopped temporarily and verify their startup mode.
- Reinstall or re-enable a provider only according to its vendor procedure if removal was part of the diagnosis.
- If writers remain unstable after targeted corrections, return to the previous application state or schedule a restart instead of deleting shadow copies in bulk.
Troubleshooting / common errors
- A specific writer is Failed: troubleshoot its application or service and the corresponding events first.
- No writers are listed: follow Microsoft guidance for missing VSS writers instead of purging snapshots.
- Writers are stable but the job still fails: verify the provider in use, the backup agent, permissions, and the exact failing phase.
- Shadow-copy creation fails because of space: increase free capacity or shadow-storage capacity after analysis.
- The error returns after several hours: look for a concurrent task, a third-party provider, an application that leaves a writer inconsistent, or recurring capacity exhaustion.