Volume Shadow Copy Service writer failures can cause application-aware backups, system-state backups, virtual-machine snapshots, and replication jobs to fail. The safest way to resolve them is to identify which part of the VSS workflow failed, preserve the evidence, and apply the narrowest supported correction.
This guide applies to Windows Server 2016, Windows Server 2019, Windows Server 2022 and Windows Server 2025, including Server Core installations. Microsoft documents vssadmin and DiskShadow on these releases.
Quick answer
- Confirm that no backup, snapshot, or production-checkpoint job is currently running.
- Open an elevated Command Prompt or Windows PowerShell session.
- Capture the current writer state:
vssadmin.exe list writers
- A writer is ready when it reports:
State: [1] Stable
Last error: No error
- Waiting states can be normal while a snapshot is in progress. Do not treat every non-stable state as a failure.
- If a writer has failed, record its name, state, writer ID, last error, and the time of the failed backup.
- Check the Application and System event logs and the backup product’s own logs.
- Identify the application, Windows role, or service that owns the writer.
- Apply only the correction documented for that writer and error condition.
- Validate the fix with a new application-consistent backup and a restore test. A stable writer list alone does not prove that backups are recoverable.
Microsoft defines Stable as writer state 1. It also defines several waiting states that form part of a normal snapshot lifecycle, including waiting for freeze, thaw, post-snapshot, and backup completion.
What is the Volume Shadow Copy Service?
VSS is a Windows framework that coordinates point-in-time snapshots of volumes while applications continue to run.
The main components are:
- Requester: The backup, replication, or snapshot application that asks VSS to create a shadow copy.
- Writer: A component supplied by Windows or an application vendor that prepares application data for a consistent snapshot.
- Provider: The software or hardware component that creates and maintains the shadow copy.
During an application-consistent backup, the requester asks VSS to gather writer metadata. The participating writers prepare their applications, briefly freeze relevant write activity, allow the provider to create the snapshot and then return the application to normal operation.
A VSS error is therefore not always a writer problem. The failure can be in the requester, writer, provider, storage subsystem, application, operating system, or backup configuration.
Before making changes
Do not begin by restarting every VSS-related service or running a generic “FixVSS” batch file.
Before any state-changing action:
- Stop or suspend scheduled backup jobs through the backup product.
- Confirm that no snapshot or production-checkpoint operation is active.
- Record the failed job’s start time, end time, error code, affected volumes, and backup type.
- Confirm that you have an approved maintenance window.
- Preserve the Application and System event logs.
- Record the existing service states and startup types.
- Confirm an independent recovery method for the affected workload.
- On clustered systems, follow the application and cluster vendor’s maintenance procedure.
Do not delete existing shadows, resize shadow storage, change access-control lists, or re-register COM components until the exact failure has been identified. Microsoft warns that resizing a shadow-storage association can cause existing shadow copies to disappear.
Step 1: Capture a diagnostic baseline
Run the following commands from an elevated Windows PowerShell session before restarting services.
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$outDir = Join-Path $env:SystemDrive "VSS-Diagnostics-$stamp"
New-Item -Path $outDir -ItemType Directory -ErrorAction Stop |
Out-Null
Get-CimInstance -ClassName Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber, OSArchitecture, LastBootUpTime |
Format-List |
Out-File -FilePath (Join-Path $outDir 'OperatingSystem.txt') -Encoding utf8
Get-Service -Name VSS, SWPRV, EventSystem, COMSysApp, CryptSvc `
-ErrorAction SilentlyContinue |
Select-Object Name, DisplayName, Status, StartType |
Format-Table -AutoSize |
Out-File -FilePath (Join-Path $outDir 'Services.txt') -Encoding utf8
Get-Volume |
Select-Object DriveLetter, FileSystemLabel, FileSystem, HealthStatus,
OperationalStatus, Size, SizeRemaining |
Format-Table -AutoSize |
Out-File -FilePath (Join-Path $outDir 'Volumes.txt') -Encoding utf8
& vssadmin.exe list writers 2>&1 |
Out-File -FilePath (Join-Path $outDir 'VSS-Writers.txt') -Encoding utf8
& vssadmin.exe list providers 2>&1 |
Out-File -FilePath (Join-Path $outDir 'VSS-Providers.txt') -Encoding utf8
& vssadmin.exe list shadows 2>&1 |
Out-File -FilePath (Join-Path $outDir 'VSS-Shadows.txt') -Encoding utf8
& wevtutil.exe epl Application `
(Join-Path $outDir 'Application.evtx') /ow:true
& wevtutil.exe epl System `
(Join-Path $outDir 'System.evtx') /ow:true
Write-Host "Diagnostics saved to $outDir"
These commands are read-only apart from creating the diagnostic directory and exporting copies of the event logs.
To inspect the shadow-storage association for an affected volume, replace D: with the relevant drive letter:
vssadmin.exe list shadowstorage /for=D:
Also capture the backup product’s logs and configuration. If the backup uses a third-party or hardware VSS provider, collect that provider’s logs as well.
Step 2: Interpret the writer output correctly
Run:
vssadmin.exe list writers
The command lists the subscribed VSS writers on the server. Microsoft documents it for Windows Server 2016, 2019, 2022, and 2025.
A healthy idle writer normally looks similar to this:
Writer name: 'Example Writer'
Writer Id: {00000000-0000-0000-0000-000000000000}
Writer Instance Id: {00000000-0000-0000-0000-000000000000}
State: [1] Stable
Last error: No error
Record all of the following:
- Writer name
- Writer ID
- Writer instance ID
- State
- Last error
Stable writers
State: [1] Stable means the writer has completed the current shadow-copy events and is ready for another operation, or has not yet been asked to prepare a snapshot.
Stable writers do not prove that the previous backup was successful. A writer may return to stable after the requester or provider has failed.
Waiting writers
Waiting-for-freeze, waiting-for-thaw, waiting-for-post-snapshot, and waiting-for-backup-completion states can be normal during an active backup.
If a writer remains waiting after the backup job has completed or timed out:
- Record the state.
- Check whether another requester is still active.
- Review the requester and writer logs.
- Investigate storage latency, application response time and overlapping backup jobs.
- Do not restart services until the active operation has been accounted for.
Failed writers
A failed state identifies the stage at which the writer vetoed or failed the operation. The accompanying Last error and event-log entries are more useful than the state alone.
Do not assume that every failed writer can be fixed by restarting the VSS service. The Windows operating system includes writers for components such as Active Directory, Certificate Services, clustering, Hyper-V, IIS, DHCP, DFS Replication, system state and the registry. These writers have different owners and different recovery requirements.
Missing writers
A writer may be absent because:
- Its application or Windows role is not installed.
- Its hosting service is stopped or disabled.
- The application has not registered the writer.
- An application upgrade or repair is incomplete.
- VSS or COM infrastructure is damaged.
- The writer is intentionally unavailable in the current product configuration.
Compare the server against a known-good server with the same roles and application versions. Do not compare it against an unrelated Windows installation because the expected writer list depends on the installed workloads.
Step 3: Correlate the failure with the logs
Check both the Application and System logs. Also review:
- The backup requester’s logs
- Application-specific logs
- Hypervisor or cluster logs
- Storage, SAN or hardware-provider logs
- Recent update and installation history
Do not troubleshoot from an event ID alone. The event source, HRESULT, operation, affected object and surrounding events determine the appropriate response.
The following PowerShell example displays potentially relevant events from the previous four hours:
$since = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
StartTime = $since
} -ErrorAction SilentlyContinue |
Where-Object {
$_.ProviderName -match
'VSS|SQLWRITER|Microsoft-Windows-Backup|CAPI2'
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-List
Get-WinEvent -FilterHashtable @{
LogName = 'System'
StartTime = $since
} -ErrorAction SilentlyContinue |
Where-Object {
$_.ProviderName -match
'volsnap|Service Control Manager|disk|Ntfs|storport|stornvme'
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-List
Adjust the time window to match the failed job. Search for events immediately before, during, and after the failure.
Server Core
Standard Server Core installations do not include Event Viewer, MMC, Services MMC or Windows Explorer. Use PowerShell, wevtutil, remote Event Viewer or Windows Admin Center instead. Microsoft’s Server Core feature comparison lists eventvwr, mmc.exe, services.msc and Windows Explorer as unavailable, while PowerShell and wevtutil remain available.
Step 4: Identify the writer owner
Determine which application or Windows role owns the failed writer before restarting anything.
Use these sources in order:
- Microsoft or application-vendor documentation
- The application’s service documentation
- The backup vendor’s writer-support documentation
- The writer’s own logs
- The server’s installed-role and service configuration
Do not infer the service name solely from the writer’s display name.
For example, Microsoft SQL Server installs SQL Writer as a separate Windows service named SQLWriter. The service is shared across SQL Server instances and must be available when a VSS-based application requests an application-consistent SQL backup.
Other writers may be part of critical Windows roles and may not have a safe standalone service restart. Restarting services associated with Active Directory, clustering, Hyper-V, Certificate Services or application platforms should be handled under the relevant workload procedure.
Step 5: Use a targeted service restart only when appropriate
A service restart is appropriate only when:
- The writer owner has been positively identified.
- The application or vendor supports restarting that service.
- No backup or snapshot operation is active.
- The operational impact has been assessed.
- A maintenance window has been approved.
- The current service state and startup type have been recorded.
Do not restart VSS, SWPRV, EventSystem, COMSysApp and CryptSvc as a blanket sequence. They are not a universal set of services that should be restarted for every writer failure.
PowerShell’s Restart-Service sends a stop request followed by a start request. If the service was already stopped, the cmdlet starts it. This means a generic restart command can change the original server state.
Example: inspect a service before restarting it
The following uses SQL Writer as an example. Replace the service name only after verifying the correct writer-to-service mapping.
$serviceName = 'SQLWriter'
$service = Get-Service -Name $serviceName -ErrorAction Stop
$service |
Select-Object Name, DisplayName, Status, StartType
$service.DependentServices |
Select-Object Name, DisplayName, Status
Preview the intended command:
Restart-Service -Name $serviceName -WhatIf
After change approval, and only if the service is expected to be running:
$service = Get-Service -Name $serviceName -ErrorAction Stop
if ($service.Status -ne 'Running') {
throw "$serviceName is not running. Investigate the stopped state before changing it."
}
Restart-Service -Name $serviceName -ErrorAction Stop
Get-Service -Name $serviceName |
Select-Object Name, DisplayName, Status, StartType
If the restart fails because dependent services are present, do not add -Force automatically. Review each dependency and its workload impact.
After the restart:
vssadmin.exe list writers
Then check the application and event logs for new errors.
Step 6: Check the requester and provider
When writers are stable but the backup still fails, investigate the requester and provider.
List registered providers:
vssadmin.exe list providers
List existing shadow copies:
vssadmin.exe list shadows
For the affected volume:
vssadmin.exe list shadowstorage /for=D:
Look for:
- Multiple installed VSS providers
- A third-party provider selected unexpectedly
- Provider registration or startup failures
- Old or orphaned shadow copies
- Diff-area exhaustion
- Insufficient space on the protected or diff-area volume
- Storage latency or I/O errors
- File-system errors
- Backup jobs that overlap
- Hypervisor checkpoints or storage snapshots running concurrently
- Unsupported provider and requester combinations
VSS can use system software providers and third-party software or hardware providers. If a third-party provider is involved, use the storage or backup vendor’s supported diagnostic procedure before modifying provider configuration.
Do not apply a universal free-space percentage
A fixed rule such as “keep 15% or 20% free” is not sufficient for every workload.
Required shadow-copy capacity depends on:
- The rate of changed blocks
- The length of the snapshot operation
- The number and retention of existing shadows
- The provider implementation
- Workload I/O
- Whether the diff area is stored on another volume
Use the actual shadow-storage configuration, storage events and workload change rate to determine capacity.
Do not resize shadow storage casually. Microsoft warns that resizing the association may cause shadow copies to disappear.
Step 7: Investigate permissions precisely
An access-denied VSS event does not justify granting NETWORK SERVICE broad access to application data or Windows system directories.
VSS involves multiple identities, including:
- The backup requester’s service account
- Application writer identities
- Local System
- Virtual service accounts
- Provider service accounts
- Application-specific database identities
For example, Microsoft documents that SQL Writer runs as Local System and uses the NT SERVICE\SQLWriter SQL login. It is not a generic NETWORK SERVICE process.
When an event reports access denied:
- Record the complete event, including the HRESULT and operation.
- Identify the exact registry key, file, directory, COM object or service involved.
- Identify the account that attempted the operation.
- Compare the object’s permissions with a known-good server or official product documentation.
- Export the current ACL before changing it.
- Grant only the documented principal and minimum required rights.
- Retest the backup.
- Restore the original ACL if the change does not resolve the problem.
Do not take ownership of Windows component-store directories or recursively grant permissions as a generic VSS repair.
Step 8: Repair Windows only when corruption is indicated
DISM and System File Checker are appropriate when the evidence indicates component-store or protected-system-file corruption. They should not be the first response to every failed application writer.
Run DISM before SFC:
DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc.exe /scannow
Microsoft’s current Windows Server guidance uses DISM first and then SFC. DISM may obtain repair content from Windows Update. If the server cannot access Windows Update, provide a matching repair source and use /LimitAccess.
Example using a working Windows installation as the repair source:
DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:\\repair-server\c$\Windows /LimitAccess
The repair source must run the same operating-system version. In practice, also verify the edition, language, architecture, and servicing level before relying on it as a source.
Review:
%windir%\Logs\DISM\dism.log
%windir%\Logs\CBS\CBS.log
Do not reboot automatically merely because DISM or SFC was run. Review their results and the application’s requirements, then schedule a reboot if Windows or the affected workload requires one.
Step 9: Handle the “no writers listed” condition separately
If vssadmin.exe list writers returns no writers at all, treat this as a different failure from one application writer being failed.
Possible causes include:
- VSS or COM infrastructure failure
- Incorrect component registration
- Event System problems
- A damaged operating-system configuration
- Severe service or permission failures
Check the Application log for the exact VSS event and HRESULT.
Microsoft documents one specific supported scenario in which no writers are listed and VSS events report 0x80040154, “Class not registered.” In that case, the documented cause is an incorrect Eventcls.dll registry path, and Microsoft supplies a precise registry correction. That resolution applies to the matching symptoms and events; it is not a generic reason to re-register every VSS-related DLL.
Do not run an internet-sourced batch file that:
- Stops multiple services without checking their state
- Silently runs
regsvr32 - Ignores command exit codes
- Re-registers shared COM components
- Changes registry configuration without backup
- Prints a success message without validation
Generic VSS re-registration procedures are not transactional and may leave the server in a partially modified state. Use only a current Microsoft or application-vendor resolution that matches the exact event, HRESULT, component, and operating-system version.
Step 10: Use DiskShadow only for controlled testing
DiskShadow exposes VSS functionality and can help determine whether a snapshot fails independently of the production backup application. It can list writers, providers, and shadows and can create shadow copies through interactive or scripted commands. Local Administrator membership or equivalent is required.
However, DiskShadow performs real VSS operations. A test can:
- Freeze application I/O
- Create persistent shadow copies
- Consume diff-area storage
- Interact with installed providers and writers
- Leave test shadows behind if the script is incomplete
Use it only during a maintenance window with:
- A reviewed script
- Explicitly named test volumes
- A chosen VSS context
- Metadata and log capture
- A cleanup procedure
- Application-owner approval
Do not publish a generic DiskShadow “create” script for production use without defining the workload, provider, context, volume set and cleanup process.
Step 11: Validate the correction
Re-run:
vssadmin.exe list writers
When no backup is active, participating writers should normally show:
State: [1] Stable
Last error: No error
That is an intermediate health check, not the final test.
Complete all of the following:
- Run a new application-consistent backup using the same requester, provider, and volume set as the failed job.
- Confirm that the backup product reports success.
- Review Application, System, application, and provider logs.
- Re-run
vssadmin.exe list writersafter the job. - Confirm application health.
- Confirm that scheduled backups have been re-enabled.
- Perform a restore test.
The restore test should match the protected workload. Examples include:
- Restore a representative file to an alternate location.
- Restore a database to a non-production instance and run consistency checks.
- Perform an application-specific recovery validation.
- Validate a virtual-machine restore or isolated recovery.
- Validate system-state recovery through the organization’s disaster-recovery procedure.
A backup should not be considered reliable until its recoverability has been tested.
Troubleshooting decision table
| Symptom | Likely area | Next action |
|---|---|---|
| One application writer is failed | Application or writer service | Check application logs and vendor documentation; consider a targeted service restart |
| Writer is temporarily waiting | Active VSS operation | Confirm whether a backup or snapshot is still running |
| Many writers time out together | Requester, storage latency, overlapping jobs or core VSS issue | Review requester logs, storage events and job concurrency |
| All writers are stable but backup fails | Requester, provider, storage or backup configuration | Review provider and requester logs; run a controlled provider test |
| No writers are listed | VSS or COM infrastructure | Match the exact event and HRESULT to current Microsoft guidance |
| Access denied | Object-specific ACL or service identity | Identify the exact object and principal; do not grant broad permissions |
| VolSnap or storage errors | Diff area, disk, file system or storage provider | Inspect shadow storage, free space, disk health and provider logs |
| Failure started after an update | OS, backup agent, application or provider version | Review update history and current vendor release notes |
| SQL Writer is missing or failed | SQL Writer service or SQL configuration | Check SQLWriter, SQL logs and SQL Writer documentation |
| Server Core instructions require a GUI | Administration method mismatch | Use PowerShell, wevtutil, remote tools or Windows Admin Center |
Rollback and escalation
Before any configuration change, document the original value and define how it will be restored.
Service changes
Record:
Get-Service -Name 'ServiceName' |
Select-Object Name, DisplayName, Status, StartType
If you change a service’s startup type, restore the original value when the test is complete or if the change does not resolve the failure.
Permission changes
Export or record the original ACL. Restore it if the documented change does not resolve the exact access-denied event.
Shadow-storage changes
Record the original shadow-storage association, used space, allocated space and maximum space. Understand which existing restore points or backup snapshots may be removed before making a change.
System repair
Preserve DISM and CBS logs. If DISM cannot find a repair source or cannot repair the component store, stop repeating generic repair commands and escalate with the logs and exact error code.
Escalate when
Escalate to Microsoft, the backup vendor, application vendor or storage-provider vendor when:
- The failure involves a third-party VSS provider.
- A supported application writer repeatedly fails.
- The required correction involves COM registration or protected registry configuration.
- Multiple writers fail after a product update.
- Storage or file-system errors are present.
- A cluster or critical Windows role is involved.
- A controlled VSS test fails outside the backup product.
- The backup succeeds but the restore test fails.
- The cause cannot be reproduced safely.
Provide the diagnostic baseline, failed-job logs, VSS output, event-log exports, provider details, application versions and a timeline of recent changes.
Commands to avoid as generic fixes
Do not use the following as routine VSS troubleshooting steps:
vssadmin delete shadows /all
vssadmin resize shadowstorage ...
regsvr32 /s <large list of Windows DLLs>
net stop <multiple core services>
net start <multiple core services>
icacls <system path> /grant ... /T
Each of these can remove recovery data, change system configuration, interrupt workloads or conceal the original failure. Use them only when a current authoritative procedure matches the exact problem and includes validation and rollback instructions.
Conclusion
VSS writer troubleshooting should be a process of evidence collection and fault isolation rather than a sequence of blanket service restarts.
The reliable approach is:
- Preserve the failed job and event evidence.
- Check writer status when no snapshot is active.
- Identify whether the failure belongs to the requester, writer, provider, storage or operating system.
- Map a failed writer to its documented owner.
- Apply the least invasive supported correction.
- Avoid broad permission changes and generic component re-registration.
- Validate the result with an application-consistent backup.
- Confirm recoverability with a restore test.
This methodology reduces unnecessary outages, protects existing recovery points, and makes VSS troubleshooting reproducible across Windows Server 2016, 2019, 2022, and 2025.
Leave a Reply