Windows Backup Failed: How to Check VSS

The short answer: If your backup tool specifically reports a VSS error, open Command Prompt as an administrator, run vssadmin list writers, and identify which VSS writers report an error and what appears under Last Error. Then use the exact failure time to review the application and system logs in Event Viewer, and check the available space on both the source and target storage. Do not delete anything or restart the system blindly.

What VSS is and why backups fail

Volume Shadow Copy Service (VSS) coordinates three parties during a backup: the backup application, the writers that freeze application data in a consistent state, and the provider that creates the actual storage-level shadow copies. Microsoft explains this in its VSS architecture documentation. The practical implication is important: when a backup fails, the problem may not be with the disk itself. It may lie in any of these three layers or in the communication between them.

It is also important to remember that a shadow copy is not the same as a verified backup stored separately. Shadow copies may be temporary or retained, but their existence alone does not prove that a complete, restorable backup exists on an independent target. The intended result is a verified backup produced by your chosen tool, not merely a shadow copy that happens to exist. The article how to back up Windows 11 explains how to configure backups from scratch using File History and system images.

What vssadmin list writers tells you—and what it does not

According to the vssadmin list writers documentation, the vssadmin list writers command lists subscribed, registered VSS writers. The vssadmin command overview states that the tool is also available in Windows 10 and 11. Running the command does not create a backup or delete shadow copies—it is a diagnostic step.

Be careful to distinguish what the output proves from what it does not:

The output shows:

• The registered writers, their states, and their types
• The Last Error reported by each writer
• Their state at the time the command was run; record the time separately

The output DOES NOT show:

• The health of the provider or target storage—writers may report “Stable / No error” while the backup still fails because of the target drive or a network path
• Whether there is enough free space in the shadow copy storage area
• Whether the data in any partially completed backup is consistent

A status of “Stable” and “No error” therefore does not mean the problem has been resolved. It only means that the writers themselves were not reporting an error when the command was run. You need the following checks to draw conclusions about the provider or target storage.

A safe step-by-step procedure

1. Record the exact time when the backup failed from the backup tool’s error message—the timestamp is the key to searching the logs.
2. Open Command Prompt as an administrator on your own system or one you are authorised to access, then run vssadmin list writers. The command displays information about registered writers; it does not start a backup or delete any copies.
3. Record three details for each writer: its name, state, and Last Error. Run the command shortly after the failure rather than a day later. The state may change in the meantime, causing you to lose an important clue.
4. Open Event Viewer and go to Windows Logs → Application and Windows Logs → System. Filter the entries around the exact failure time, allowing a window of a few minutes on either side. Do not guess error codes—look for entries whose timestamps match the job failure and read their full text.
5. Check the available space on both the target storage and the source volume. Insufficient space is one of the conditions you need to rule out. The required capacity and shadow copy storage area depend on the tool and its configuration.
6. Check whether the storage medium suffered an I/O failure. If the backup is failing because of a defective medium, stop further attempts and secure the data first. If you suspect media damage, do not repair or repeatedly scan the original, as this could make the situation worse. The data takes priority over the device.

Expected result: you have recorded the writers’ states, the failure time, the relevant logs, and the available space on the volumes. This information may narrow down the cause, although it may not identify it conclusively on its own.

Safe fallback path: if the writers report an error such as a timeout but the logs do not reveal a clear cause, schedule a restart of a standard PC outside working hours—after saving all open work. A restart may alter a transient state, so preserve the diagnostic information first. On a business computer or server, coordinate the intervention with the administrator and follow the organisation’s operating procedures.

What you must not do

• Do not run vssadmin delete shadows or vssadmin resize shadowstorage. These actions modify or remove shadow copies and may make the situation worse, including for the remaining data.
• Do not blindly re-register DLL libraries associated with VSS. This is an unnecessarily invasive step without a clearly established cause.
• Do not restart services blindly. Restarting a service without knowing the specific error may alter the state you need to document. A normal restart does not, however, automatically erase existing event records.
• Do not disable security software or other protections. That is not a solution and only increases the risk.
• If you suspect a defective medium, do not repair the original or make further backup attempts on it. The data takes priority over the device.

Decision table

When the storage medium is affected: data comes first

If the backup medium itself or the I/O path leading to it proves defective, stop making further backup attempts. Repeatedly running the job on faulty media may do more harm than good. First secure the current data in another safe location, and only then address the device or medium itself. Do not attempt repairs or uncontrolled surface tests on a sensitive original stored on a drive with bad sectors or a similarly problematic medium. If the situation requires it, this work should be left to a specialist service.

Handover checklist and result verification

If you begin troubleshooting the problem yourself and then hand the system over to someone else, such as a colleague or service technician, provide the following information:

• The exact time when the job failed and the name of the backup job
• The complete output of vssadmin list writers captured shortly after the failure, including each writer’s name, state, and Last Error
• Relevant Application and System log entries, including their timestamps and event IDs
• The available space found on the source and target
• A list of the steps performed and what did or did not help

Consider the problem resolved only after all three conditions have been met:

1. A new backup job completed successfully without errors.
2. The writers reported no errors after the new job. Keep in mind that this alone does not guarantee the health of the provider and target, which is why step 3 is necessary.
3. You successfully restored a sample of files from the backup to a separate folder and verified that the files open and contain the expected data. Restoring to another folder avoids overwriting the original files and confirms that the tested sample is usable. It does not prove that every application or the entire backup can be restored.

Without the final step, even a “successful” backup is merely a claim in a log. For a critical application, add an appropriate test of its restoration and consistency rather than merely opening a few documents.

Frequently asked questions

Do I need to run Command Prompt as an administrator to diagnose VSS?

Yes, vssadmin requires Command Prompt to be run as an administrator on a system you are authorised to access. The vssadmin list writers command does not change any data; it only lists registered writers, as confirmed by the Microsoft documentation.

Does a “Stable” status for writers mean everything is working properly?

No. Writers may report Stable and No error while the backup still fails because of the provider, target storage, or insufficient free space. The writers list only shows the state of the application layer, not the rest of the chain, so continue by checking the logs and available space.

Can I delete old shadow copies when a backup keeps failing?

I do not recommend doing so at this stage. Commands such as vssadmin delete shadows change the state of shadow copies and may make the situation worse. Begin the diagnosis by listing the writers and reviewing logs for the exact time of the failure.

Is a successful new job enough to prove that the problem is resolved?

No. Consider the problem resolved only after a new job completes successfully and you restore a sample of files to a separate folder. Furthermore, a shadow copy is not the same as a verified backup stored separately.

Should I simply restart the computer instead of diagnosing the issue?

A restart may help on a standard PC, but only after saving your work and as a planned step, not as a blind fix. This approach is not suitable for business servers, where a restart requires an approved procedure and a scheduled maintenance window. A successful new job and a restore test verify the outcome of the corrective action, but not necessarily the original cause of the error.

When to hand the problem over to a technician

If the error continues after these safe checks, prepare the exact error message and timestamp, the device model, and the results of the steps described above. For standard system repairs, you can use the service order form. If unbacked-up data is at risk or the storage device reports read errors, the data takes priority: use the device and data service guide and do not continue attempting to repair the original.

Sources and review date

The technical sources were reviewed on 4 October 2026.

• Microsoft: vssadmin list writers
• Microsoft: vssadmin (command overview, also applies to Windows 10/11)
• Microsoft: VSS architecture