1. VSS: Bad state

The error is reported during backup VSS backup

2. VSS: Bad state.(PrepareForBackup)

The error is reported in the DS-Client event log during VSS-Aware backup for Exchange Server.

As a result a second error is reported and backup stops:

"Activity stopped because failed to start snapshot creation"

Corresponding error in Windows Event Viewer during the Exchange VSS backup is:

"Volume Shadow Copy Service error: Unexpected error calling routine Cannot find anymore diff area candidates for volume \\..., Catastrophic failure"

Another error can be seen on Windows Event viewer for:

"VSS: Event id 12293 Volume Shadow Copy Service error: Error calling a routine on Shadow Copy Provider {b5946137-7b9f-4924-af8051abd60b20d5}"


1. One of the VSS Writers is not in a stable / no error state.

2. This is a generic error signaling that a VSS writer is in a failed state, more details are logged in the operating system event viewer / application log on the backup source computer.


1. Ensure no conflicts with other backup solutions using VSS. On the backup target computer identify the problematic VSS writer by running the command: vssadmin list writers

Then take appropriate action to bring the VSS writer to a stable / no error state.

2. In addition to the action from #1, ensure to have sufficient storage space for VSS snapshots, it is Microsoft requirements.

Shadow Copies volume (Volume > Properties > Shadow Copies) is being used by Windows for taking snapshots, it is disabled by default. Ensure the shadow storage settings is set to 10% of the size of total volume (Shadow Copies > Volume > Settings > Use Limit) e.g. for a 500GB volume, set the Shadow storage setting to 50GB.

Monitor the shadow storage size volume while the backup is progress by running the command:

vssadmin list shadowstorage

The command above provides the size being used at a certain point. After the backup completes, the snapshots are removed and the corresponding shadow storage disk space released.

Note: If the VSS-Aware for Exchange protects passive databases from an Exchage Server 2010 member of a Database Availability Group, the issue is the one described in the Microsoft KB: