Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix Event ID 8193

Event ID 8193 and 0x800423F2: a VSS writer fails and the whole backup is abandoned

10 min read Updated October 4, 2026 Windows Server: RDS, Hyper-V & Clustering

Fix it now

One writer failed and VSS abandoned the whole snapshot set with it, because a set that is consistent for some applications and not others is not worth having. Find the writer that is not stable and restart the service behind it.

Run this in an elevated Command Prompt and read every writer’s state

vssadmin list writers
  1. Note every writer whose state is not [1] Stable, and every one carrying a last error. Microsoft’s rule is simple: for each of those, restart that writer’s service.
  2. Restart the owning service, then run vssadmin list writers again and confirm the writer came back stable.
  3. Re-run the backup immediately, while the writer is freshly reset.
  4. If the same writer fails again straight away, read that application’s own log. VSS is reporting the application’s problem, not creating it.
  5. If several unrelated writers are failing at once, reboot the server in a window and start again from a clean writer set.

Restarting these services is not free. Restarting the Information Store takes mailboxes offline, restarting IIS Admin interrupts every site, and restarting a directory service takes a domain controller out of service for the duration.

If a full job completes with every writer stable afterwards, you can stop here. The next section explains what a writer does during a snapshot and why one failure ends the job.

Why it happens

A VSS writer is code an application registers so its data can be backed up consistently while it is running. When a requestor asks for a snapshot, VSS calls every registered writer in turn: prepare for backup, then freeze, at which point the application must get what is on disk into a consistent state and stop writing. VSS takes the snapshot and calls thaw, and normal operation resumes.

The timing is published and it is tighter than most people expect. The application freeze is not allowed to take longer than 60 seconds, and the shadow copy creation period itself lasts no more than 10 seconds, during which all write I/O to the file system remains frozen. Shadow copy creation is aborted if the writers stay frozen longer than 60 seconds or the provider takes longer than 10 seconds to commit.

Because the set is produced as one consistent whole, one writer’s failure ends it. Microsoft states the consequence plainly in its own worked example: when a snapshot is created, every VSS writer associated with the volume is called, and if any of them encounters an error, the entire backup job fails. And once a writer has failed it usually stays failed, which is why the job fails identically at the same stage every night until somebody intervenes.

The writer is stuck from an earlier failed attempt

You have this one if A writer shows a last error from hours ago and every subsequent attempt fails the same way.

  1. Restart the service that owns the writer.
  2. Confirm with vssadmin list writers that it returns to [1] Stable with no error.
  3. Re-run the backup immediately.
  4. If a service restart does not clear it, reboot in a window; some writers only re-register at startup.

The application behind the writer is genuinely unhealthy

You have this one if The same writer fails within seconds of every attempt, and the application’s own log has errors at the same timestamps.

  1. Read the application’s log before touching anything. Microsoft’s own example of this failure is the SQL Server VSS writer failing because a database could not be opened, with SQLWRITER and SQLVDI errors naming the instance and the database.
  2. For SQL Server, identify the instance and database from those errors, then confirm every database is online rather than recovering or suspect.
  3. Test by stopping the implicated instance and running the backup; if it then completes, you have your culprit.
  4. Fix the application and re-test. Repairing VSS will not repair the application.

The provider cannot be created at all

You have this one if Event 12292 in the Application log, often with VSS event 11 and Service Control Manager event 7023 saying the Microsoft Software Shadow Copy Provider service terminated.

  1. Open HKLM\SYSTEM\CurrentControlSet\services\swprv\Parameters.
  2. Confirm the ServiceDll value exists and reads %Systemroot%\System32\swprv.dll as an expandable string value.
  3. Create the Parameters key or the value if either is missing, then re-run the backup.
  4. This is a provider fault rather than a writer fault, so no amount of service restarting on the application side will help.

Two products are asking for snapshots at once

You have this one if Failures only on certain nights, with a different writer implicated each time.

  1. Identify every product on the server that takes snapshots, including host-level backup if this is a virtual machine.
  2. Stagger their schedules so only one requestor is active at a time, with a real gap between them.
  3. Where a guest is protected by both the host and an in-guest agent, decide which one you actually need.
  4. Re-run both jobs on the new schedule and confirm neither fails.

Full reference

What the events actually say

Event or code Published text
8193 Volume Shadow Copy Service error: unexpected error calling a named routine, with hr and its text. The event body also prints the operation and the writer class, name and instance
12292 Volume Shadow Copy Service error: error creating the shadow copy provider COM class with the named CLSID, during “Obtain a callable interface for this provider”
0x800423F4 Reported by Windows Server Backup as “The volume shadow copy operation failed with error 0x800423F4”, in Microsoft’s example caused by the SQL Server VSS writer
0x800423F2 Named by Microsoft where a backup checkpoint could not be created for a virtual machine
8194 Seen alongside these. No message text is published for the ID

Event 8193 is worth reading rather than pattern-matching. It is a generic “a VSS call failed” event, and Microsoft’s own worked example of it is not a timeout at all: it is an access denied on a registry key while the System Writer initialises under Network Service, after the DHCP role rewrote the permissions on that key. The hr and the routine name in the body are the diagnosis; the event ID by itself is not.

Writers and the services behind them

The rule Microsoft publishes is the one to work from: for every writer whose state is not [1] Stable, restart that writer’s service. Two pairings appear in Microsoft’s own troubleshooting content and are worth knowing because they are the two that catch people out:

Writer Service
System Writer Cryptographic Services. It initialises the writer under Network Service, which is why a permissions change on the VSS Diag key surfaces as an 8193 against the System Writer
SqlServerWriter SQL Server VSS Writer, with the failing instance named in the accompanying SQLWRITER and SQLVDI errors

For any other writer, identify the owning service from the writer name rather than from a table you found somewhere: writer names track the product, product names change, and a stale mapping sends you to restart the wrong service on a production server.

The timing that governs all of this

Stage Published limit
Application freeze Not allowed to take longer than 60 seconds
Shadow copy creation, with file system writes held No more than 10 seconds
Either exceeded Shadow copy creation is aborted

Those two numbers explain most of the behaviour on this page. A writer that cannot reach a consistent state inside its window ends the set; a provider that cannot commit inside its window does the same. Neither is a value you tune – what you change is how much work the application has to do at that moment, and how busy the volume is while it does it.

Restarting a service to clear a writer is a production action, not a diagnostic one. The Information Store, IIS Admin and directory services all take real workloads offline when they restart. Where a reboot is possible it resets every writer at once and is often the faster and more honest option; where it is not, work through the writers one at a time in a window.

When every writer is stable and the backup still fails

  • Check the provider layer: a 12292 or a swprv service failure is not a writer problem and no amount of restarting application services will move it.
  • Check whether a second backup product or a host-level snapshot is running in the same window.
  • Check the source volumes for a dirty flag; VSS will not snapshot a volume flagged as needing repair.
  • Read the numeric code in the Backup log’s own failure event rather than the generic message in the console.

Every code this article covers

Code What it points at Source
Event ID 8193 Volume Shadow Copy Service error: unexpected error calling a named routine, with the hr and its text, plus the operation and writer named in the event body Microsoft Learn
Event ID 8194 Logged by VSS alongside writer failures. Microsoft publishes no message text for this ID; read the 8193 in the same window instead not published by the vendor
0x800423F2 Named by Microsoft where a VSS-based backup checkpoint could not be created; the failure is in the shadow copy operation rather than in the backup target Microsoft Learn
0x800423F4 Reported when the volume shadow copy operation failed because a writer failed; Microsoft’s worked example is the SQL Server VSS writer, with event 521 alongside it Microsoft Learn
Event ID 12292 Volume Shadow Copy Service error creating the shadow copy provider COM class with the named CLSID; the documented cause is a missing or wrong ServiceDll value for swprv Microsoft Learn

Confirm the fix worked

  1. vssadmin list writers reports every writer in [1] Stable with no last error.
  2. A full backup completes with no writer error in the Application log.
  3. vssadmin list writers after the job shows the writers still stable.
  4. The following night’s scheduled run also completes, since writer faults often only appear under the real schedule.
  5. If a provider fault was the cause, the swprv ServiceDll value survives a reboot.

Questions people ask about this

Why does one failed writer stop the entire backup?

Because VSS produces one consistent snapshot set, not a collection of independent ones. If one application could not be brought to a consistent state, the set is not trustworthy, and the service fails rather than hand you a backup with a quiet inconsistency in it.

Is there a cost to fixing this?

No. Every step uses tools included with Windows Server, and no licence changes writer behaviour. Where a vendor’s agent is implicated, the fix is an update to that agent rather than a new product.

Can I exclude a failing writer from the backup?

Some backup products let you, and it is occasionally right for a writer belonging to something you do not need to restore. Do it deliberately and write it down, because it silently changes what your backup can recover.

Should I reboot rather than restart services one at a time?

A reboot resets every writer at once and is often faster than working through them. On a server that can be restarted it is a legitimate first move; on one that cannot, work through the writers that are not stable.

The 8193 mentions a registry key, not a timeout. Is that the same problem?

It is the same event doing a different job. 8193 reports any unexpected failure in a VSS call, and Microsoft’s documented example is an access denied on the VSS Diag key after the DHCP role changed its permissions – which is harmless and can be left alone. Read the routine name and hr in the event before assuming a writer timed out.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix 0x81000019 and 0x8100002F: backup cannot read the shadow copy it just made License Error Event ID 12002 and 12032: WSUS web services stop answering and clients stall Free Fix Event ID 12042 and 13042: WSUS self-update and authentication services fail License Error Event ID 4096 and 0x800705B4: integration services time out during VM tasks
← Back to Knowledge Base