VSS Snapshot Failures: Writers, Event IDs and Shadow Storage

vssadmin list writers
# healthy writer:   State: [1] Stable,  Last error: No error
# broken writer:    State: [8] Failed   / [10] Waiting for completion forever

A failed writer means the application's VSS component could not prepare its data (SQL, Exchange, NTDS, System Writer...). Identify which writer, then look at the application's own log — the writer's failure is a symptom of the app's state: a hung SQL backup thread, a domain controller under load, a System Writer blocked by permission drift on system files.

# restart just the affected writer's service instead of rebooting:
net stop w32time && net start w32time        # example pattern; per-writer service
# System Writer specifically:
swsc / regsvr32 patterns aside, check the event log Security for
# access-denied on %windir%\system32 files (a classic System Writer killer)

vssadmin list shadowstorage
# shows Used / Allocated / Maximum per volume
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=20%
# delete old copies when stuck:
vssadmin delete shadows /all /quiet      # or /oldest for one at a time

Event 13/20 pairs with "Maximum" too small or the host volume near-full. A shadow storage area on a different, fuller volume is a common misconfiguration — snapshots for D: living on C: which is at 99%. Also: an unbounded maxsize is not free, it lets snapshots eat the disk until the application starves; size it on purpose.

• Third-party filter drivers (antivirus, encryption, some backup agents) can abort creation — event 12292 with a provider name you don't recognise. Clean-boot diagnosis or the vendor's exclusion list.
• Too many snapshots pending: the 64-snapshot-per-volume limit; a backup tool that never deletes its copies fills it. vssadmin list shadows shows the pile.
• Cluster/shared volumes (CSV): redirected I/O mode during a snapshot adds latency; coordinate with cluster health before blaming VSS.
• Reboot as triage, not therapy: a reboot clears hung writers, but if the writer fails again next run, the application-side cause was never fixed — you have simply scheduled the reboot.

• After any fix, run a manual snapshot (vssadmin create shadow /for=C:) and a real backup before trusting the schedule.
• Alert on writer state != Stable from your monitoring (many RMMs collect it), not on backup failure alone — writers rot days before the job dies.
• Keep shadow storage sized and on a volume with headroom; document the pairing.
• Track the event-ID map in the runbook; 8193 goes to the app team, 13/20 to the storage admin, 12292 to the AV/filters owner — incidents end faster with the right first responder.

Backing up a VM has two snapshot layers and confusing failures when they mix. Hypervisor-level snapshots (VMware Tools / Hyper-V integration services providing the guest VSS provider) produce application-consistent images only if the guest services are installed and healthy — a VM with broken or outdated tools silently degrades to crash-consistent backups, which databases notice at restore. Inside-guest backup agents use the guest's own VSS stack with its own writers and shadow storage, independent of the hypervisor. When a "VSS failed" error arrives, first answer: which layer reported it? The event source (guest Application log vs. the backup product's host-side log) tells you, and the fix lives entirely in that layer — updating tools for the hypervisor path, repairing writers/storage for the guest path.

Run a manual vssadmin create shadow immediately, then let the next scheduled job complete and confirm the backup software reports an application-consistent result (not crash-consistent). Two consecutive clean runs, plus all writers Stable, is the definition of closed for a VSS incident — one clean run is a coin flip wearing a lab coat.