How to Fix Exchange Server Backup Failures Caused by VSS Issues

How VSS and Exchange Work Together

When your backup software starts an Exchange backup, it does not simply copy database files. It engages a three-party handshake through the Windows Volume Shadow Copy Service framework:

• VSS Requestor — your backup software (Windows Server Backup, Veeam, Veritas NetBackup, DPM, Azure Backup, etc.)
• VSS Writer — the Exchange VSS Writer, a component built into Exchange that knows how to freeze database writes, flush transaction logs, and signal when a snapshot is safe
• VSS Provider — usually the Windows Software Shadow Copy Provider, or a hardware provider on SAN-attached storage

The sequence on every backup run:

1. The requestor instructs VSS to begin a shadow copy
2. VSS notifies all registered writers to prepare — the Freeze phase
3. The Exchange Writer signals Exchange to flush uncommitted transactions and hold new writes momentarily
4. VSS takes the shadow copy, typically completing in under one second
5. VSS signals the Exchange Writer to Thaw — Exchange resumes normal write activity immediately
6. The requestor reads database files from the stable shadow copy volume
7. On successful completion, Exchange truncates the committed transaction logs it no longer needs

This is precisely why a broken VSS writer does not just fail a single backup job. It can leave Exchange in a partially frozen state mid-snapshot, prevent log truncation that fills your log drive over days, and in severe cases corrupt the VSS infrastructure shared by every application on that server.

Common Symptoms of VSS Failure

• Backup jobs report "VSS writer failure" or "Exchange writer returned error"
• Windows Server Backup shows "The writer experienced a transient error" or "Timed out waiting for shadow copy"
• Veeam or DPM logs reference Microsoft Exchange Writer with status Failed or Waiting for completion
• Transaction log files accumulate in the log folder without being truncated — the log drive fills over time
• vssadmin list writers shows Exchange writer in Failed [7] or Retryable error [4] state
• Application Event Log contains VSS errors with Event ID 8193, 12293, or 13 from source VSS
• Circular logging was enabled as a workaround but logs still grow faster than expected

Step 1 — Diagnose the VSS Writer State

Open an elevated Command Prompt on the Exchange server and run:

This lists every registered VSS writer on the server, its current state, and the last error code. Scroll to the Exchange entries. Under normal conditions you will see:

Writer Name	Expected State
Microsoft Exchange Writer	Stable [1]
Microsoft Exchange Replica Writer	Stable [1]

If the state is anything other than Stable [1], use the table below to determine severity:

State	Meaning	Action
Failed [7]	Writer crashed or encountered a fatal error	Restart Exchange services (Step 3)
Retryable error [4]	Transient fault — often resolves on retry, but rarely does so on its own	Restart Exchange services (Step 3)
Waiting for freeze [5]	Writer is stuck mid-operation — Exchange may be hung	Restart Exchange services, then check database health (Step 6)
Waiting for thaw [6]	Snapshot took too long and writer timed out during a freeze	Restart VSS service (Step 4), then Exchange services (Step 3)
Stable [1]	Writer is healthy	No action — check backup software configuration instead (Step 9)

Also run:

The providers list should show Microsoft Software Shadow Copy provider 1.0. If you see hardware providers with errors, that is a separate path. The shadow storage output tells you whether storage space is exhausted — a common cause of failures that is addressed in Step 5.

Step 2 — Check the Application Event Log

Before changing anything, pull the error context from Event Viewer. Open Event Viewer → Windows Logs → Application and filter by these sources: VSS, ESENT, MSExchangeIS, MSExchangeRepl. Look at the timeframe of the last backup failure.

Event ID	Source	Meaning
8193	VSS	COM function call failure — VSS infrastructure problem, often COM+ registration
12293	VSS	Shadow copy creation failed — storage, permissions, or writer freeze timeout
13	VSS	Volume Shadow Copy Service error: unexpected error calling routine
2004	ESE / ESENT	Database engine error — check database health before proceeding
2115	MSExchangeIS	Information Store failed to quiesce for VSS snapshot
2142	MSExchangeRepl	Replication service could not coordinate with VSS writer

Also check the System log for disk errors, Volume Manager events, or shadow copy provider crashes. A disk error on the volume hosting Exchange databases will cause VSS failures that no amount of service restarts will fix until the underlying storage issue is resolved.

Step 3 — Restart the Exchange VSS Writer

This fixes the majority of VSS failures. The Exchange VSS Writer is tied to core Exchange services. Restarting them re-registers the writer with VSS in a clean state.

Run the following in Exchange Management Shell or an elevated PowerShell session on the Exchange server:

Wait for all services to return to Running, then verify the writer state cleared:

Both Exchange writers should now show Stable [1]. If they do, attempt your backup. If the writer still shows Failed after the service restart, proceed to Step 4.

Step 4 — Reset the VSS Service Itself

If the writer state did not clear after restarting Exchange services, the VSS infrastructure itself may be in a corrupted state. This happens after Windows cumulative updates, failed third-party backups, or VSS provider crashes.

If that does not clear it, re-register the VSS provider DLLs. Run these commands from an elevated Command Prompt:

After completing, restart Exchange services again and check the writer state:

Step 5 — Fix Shadow Copy Storage Exhaustion

If vssadmin list shadowstorage showed the storage at or near its maximum, VSS cannot stage a new shadow copy and all backup attempts will fail before the Exchange writer is even engaged.

Delete all existing shadow copies on the server:

Increase the shadow storage allocation for your Exchange database volumes:

Adjust the drive letter and size to match your environment. A practical rule: allocate 10–20% of the volume size for shadow storage. On a 250 GB database volume, 25–50 GB of shadow storage headroom is appropriate.

Also verify free disk space on both the database and log volumes:

VSS requires available free space to stage shadow copies. If the database or log volume is over 90% full, VSS will fail before the writer handshake even begins. Free space first, resize shadow storage second.

Step 6 — Verify Exchange Database and Log Health

If VSS writer errors persist, confirm Exchange databases are mounted and healthy. An unmounted or corrupt database causes the VSS Writer to report failure when backup software attempts to include it.

All databases should show Mounted : True. If any show False, investigate the mount failure before continuing. Check the Application Event Log for ESENT errors and run the Exchange Database Troubleshooter if needed.

Check transaction log folder health:

Navigate to each log folder and verify:

• Log files are present — a series of E0x*.log files for each database
• No log file is 0 bytes
• Reserve log files Res1.jrs and Res2.jrs are present (their absence indicates the database has exhausted log space)
• The checkpoint file E0x.chk is present and is not from an unexpected date

Missing reserve logs or 0-byte log files indicate database-level corruption that must be resolved before backups will succeed, regardless of VSS state.

Step 7 — Repair COM+ Infrastructure

Persistent VSS failures — particularly Event ID 8193 with a COM error code — can trace back to corrupted COM+ application registrations. This is common after in-place Windows Server upgrades or .NET Framework updates that partially updated COM registration.

Run the Component Services repair and reset the COM+ catalog:

Restart the COM+ System Application and Distributed Transaction Coordinator:

Then restart Exchange services and verify the VSS writer state once more. COM+ corruption is less common than a crashed Exchange service, but it produces the most persistent VSS failures — ones that return after every service restart until the COM+ layer is repaired.

Step 8 — Run a Test Backup

Once VSS shows all writers in Stable [1] state, validate end-to-end before relying on the next scheduled job. Trigger a manual backup from your backup software against a single database first.

If you are using Windows Server Backup:

Watch the Application Event Log in real time during the test:

A clean backup produces VSS events confirming the snapshot was taken and released without error, followed by Exchange log truncation events. After the job completes, check the transaction log folder — its size should decrease as Exchange truncates logs that are no longer needed for recovery.

Step 9 — Backup Software VSS Integration

If VSS is stable but your specific backup product still fails, the issue may be in how the backup software registers as a VSS Requestor. Each product has its own Exchange integration requirements.

Veeam Backup & Replication

Ensure the backup job has Guest processing enabled with Application-aware processing turned on. Veeam injects its own VSS requestor component into the guest VM and requires valid credentials with Exchange admin rights. If the job is configured with an incorrect account, VSS coordination will fail silently at the guest level even if the host-level snapshot succeeds.

Windows Server Backup

Windows Server Backup does not natively support Exchange-aware VSS on Exchange 2016 and 2019. It will take a VSS snapshot of the database files, but the resulting backup is not Exchange-consistent and cannot be used for mailbox-level restores. For Exchange 2016/2019, use a dedicated Exchange-aware backup product or Azure Backup with the MABS agent.

Microsoft Azure Backup / MABS

Requires the MABS (Microsoft Azure Backup Server) protection agent installed on the Exchange server and a protection group configured with Exchange as the workload type. Verify the agent service is running and communicating with the MABS server. Check the MABS console for agent health warnings before investigating VSS directly.

Veritas NetBackup / DPM

Both require their protection agent installed and healthy on the Exchange server. If the agent service is stopped or the agent is in an error state in the management console, VSS coordination will fail at the requestor level rather than the writer level. Always check agent health in the management console first.

Prevention

Monitor log truncation after every backup. After each successful job, transaction logs should be pruned. Set an alert if the log drive grows by more than a few gigabytes between backup windows — that is the earliest signal that VSS coordination silently broke.

Check VSS writer state weekly. Schedule a task to run vssadmin list writers > C:\Logs\vss_writers.txt and email it to your team. Compare against a known-good baseline snapshot taken when everything is healthy. Writer state changes are easy to miss in a busy environment.

Size shadow storage correctly at provisioning time. After any disk resize or volume addition to an Exchange server, re-run vssadmin list shadowstorage and adjust limits. The default VSS storage allocation is often inadequate for Exchange-sized database volumes.

Test backups after every patch cycle. Windows cumulative updates and Exchange CUs both touch VSS infrastructure. After any update cycle, run a manual backup test before assuming your scheduled jobs are intact. A broken VSS writer after a patch is one of the most common support calls in Exchange environments.

Never enable circular logging as a workaround. Circular logging masks the root cause, eliminates point-in-time recovery, and is not reversible without seeding a fresh full backup after re-enabling it. Fix the VSS problem directly.

Quick Reference — VSS Recovery Sequence

When Exchange backups fail due to VSS, work through these steps in order and test after each:

1. 1vssadmin list writers — identify writer state and error code
2. 2Check Application Event Log for VSS/ESENT errors at the time of failure
3. 3Restart MSExchangeIS, MSExchangeRepl, MSExchangeTransport — confirm writer returns to Stable [1]
4. 4If still failed: net stop vss && net stop swprv && net start swprv && net start vss
5. 5Re-register VSS providers using the regsvr32 sequence above
6. 6Check shadow storage — delete existing shadows and resize allocation if exhausted
7. 7Verify databases mounted and log folder health intact
8. 8If Event ID 8193 with COM error: run comrepl and reset COM+ System Application
9. 9Run a manual backup test and watch the Application Event Log for VSS events

In the large majority of cases, steps 1–3 resolve the problem in under five minutes. Steps 4 through 8 cover the edge cases that a service restart alone will not reach.