VSS Writer Failed? Diagnose It Before the Next Backup

Direct answer: when a backup or quiesced snapshot of a Windows VM fails at the shadow copy stage, start inside the guest. Run vssadmin list writers from an elevated prompt and record every writer whose state is not [1] Stable or whose last error is not No error. For each one, read three things together: the phase in which it failed, its last error, and the time of the failed job. Then find the service or application that hosts it and read the Application log at that time. Decide whether that writer matters for this backup, and give the fix to the writer's owner. Do not turn off application quiescing for the whole VM as the fix.

Why it matters

A backup that cannot quiesce a Windows server either fails or, depending on the backup product's settings, keeps a less consistent copy. Microsoft states that when no writers take part in a VSS backup, a shadow copy can still be created, but the data on that volume is crash-consistent (Writers, Microsoft Learn). For a database, directory or message store, the application must then run its own recovery on restore.

How it works

Volume Shadow Copy Service (VSS) coordinates three roles (Volume Shadow Copy Service, Microsoft Learn):

• The requester asks for the shadow copy. For a VMware quiesced snapshot, VMware Tools drives VSS inside the guest and installs the VMware Snapshot Provider service for this purpose (Broadcom KB 344277). An in-guest backup agent can be the requester instead.
• Writers belong to applications and Windows features. Each prepares its data (for example completing transactions or flushing caches), then holds write I/O while the copy is made.
• The provider creates the shadow copy. Windows includes a system provider that uses copy-on-write.

Microsoft sets two limits: the application freeze may not exceed 60 seconds, and the provider's creation lasts no more than 10 seconds. Exceeding either can abort the shadow copy (Volume Shadow Copy Service).

A writer that cannot do its part vetoes the operation. Microsoft's example is a writer that could not suspend its activity while the copy was created, which gives a high probability that the copy is not valid (Writer Errors and Vetoes, Microsoft Learn).

Broadcom states that Windows quiesced snapshot failures are caused inside the guest's VSS service, writers and providers, which VMware snapshots rely on but do not control (KB 344277). So start in the guest; step 6 still checks the host.

How to prove it (read-only)

Steps 2 to 6 only read state. Run the guest commands from an elevated prompt.

1. Establish that the problem is quiescing, using existing history. In the backup job history and vSphere task history, recent non-quiesced successes alongside quiesced failures point at quiescing. Broadcom's isolation step, a manual non-quiesced snapshot (KB 344277), creates and removes a snapshot, so it is a change: request it through your change process with the VM owner's approval if history does not answer the question.

2. Read writer state and last error.

vssadmin list writers

The command lists subscribed writers (vssadmin list writers, Microsoft Learn). A healthy entry shows State: [1] Stable and Last error: No error. Broadcom shows an unhealthy example as State: [10] Failed with Last error: Timed out, and names "Retryable error" as another non-stable outcome (Broadcom KB 428895).

The states map to the VSS_WRITER_STATE values (VSS_WRITER_STATE, Microsoft Learn). Read them in two groups:

• Waiting states (WAITING_FOR_FREEZE, WAITING_FOR_THAW, WAITING_FOR_POST_SNAPSHOT, WAITING_FOR_BACKUP_COMPLETE) mean the writer is part-way through an operation. They are not failures on their own.
• Failed states name the phase in which the writer vetoed: identify, prepare backup, prepare snapshot, freeze, thaw or post snapshot. FAILED_AT_BACKUP_COMPLETE is different: Microsoft says the shadow copy had already been created when the writer failed.

The phase tells you when the writer vetoed, not why. A writer in FAILED_AT_FREEZE vetoed during the freeze; that is not, by itself, a timeout. The reason is in the last error. Microsoft separates the error classes (Writer Errors and Vetoes):

• Retryable: retrying without reconfiguration might work.
• Timeout or out of resources: these might suggest reducing system load before retrying.
• Non-retryable or not responding: an error severe enough to preclude backing up that writer's data with VSS.

So a freeze-phase failure with Timed out is a reported timing failure (load is one candidate to investigate, not something the state and error alone establish), a freeze-phase failure with a non-retryable error is a writer fault, and a writer in a waiting state is busy rather than failed.

Status read outside a backup can reflect an earlier failure or a writer still busy (Determining Writer Status, Microsoft Learn), so record when you ran the command and compare it with the job time.

3. Check providers.

vssadmin list providers

Broadcom's checks expect the Microsoft Software Shadow Copy provider to be present and say a third-party provider can interfere with quiescing (KB 344277). An unexpected provider is a lead for that product's owner, not proof of cause.

4. Read the event logs at the failure time. VSS requester, writer, provider and service errors go to the Application log; VSS drivers and lower-level components write to the System log (VSS Error Logging, Microsoft Learn). Broadcom lists Application log event IDs 11, 12292, 12032 and 12298 with quiescing failures, some describing a COM server that cannot be started (KB 344277). Filter both logs to minutes either side of the failed job and note each error code.

5. Check the supporting services. Broadcom KB 344277 lists expected service states for idle and during-backup periods, including COM+ Event System (Automatic, started), COM+ System Application (Manual, started), Volume Shadow Copy (Manual) and VMware Snapshot Provider (Manual, started during a backup), and lists the Virtual Disk service with Manual start-up. A second Broadcom article asks for the Virtual Disk service to be set to Automatic (KB 385812). Because they differ, record what you see and raise it with support rather than changing the start-up type.

6. On the host side, the VM's vmware.log records the quiesce attempt. Broadcom shows a timeout case with the message Timed out while quiescing the virtual machine and the guest error 0x80004004 (E_ABORT) (KB 428895). Read it through normal host access; do not edit it on the datastore.

Candidate causes and what each looks like

Finding the hosting service. Microsoft documents that the registry writer, COM+ class registration database writer, shadow copy optimisation writer and Automated System Recovery writer are hosted in the VSS service itself, and that the System Writer runs inside Cryptographic Services. Application writers run in the application's process (In-Box VSS Writers). This tells you which service a restart would touch, and who must approve it.

Decision guidance

1. Record before changing anything. Save the writer and provider output with the time each was run, the event log extract and the job's error text.
2. List every failed writer, not just the first. For each, note phase, last error and hosting service.
3. Decide which failures matter for this backup. Microsoft notes that a requester may continue when a veto comes from a writer whose data is not the purpose of the backup (Writer Errors and Vetoes). Confirm in your product's documentation whether it does.
4. Timeout or out-of-resources errors: investigate load at the job time; Microsoft suggests reducing it before retrying. Moving the schedule is the low-risk option. Restarting the hosting service interrupts it, so it needs the owner's approval and a window.
5. Non-retryable, not-responding or persistent failures: escalate to the application vendor or Microsoft support with the evidence from step 1. Broadcom's resolution for writers that keep timing out is to engage Microsoft support for the failing writer (KB 428895).
6. VMware Tools reinstall or provider removal: both appear in Broadcom's troubleshooting (KB 344277). Both change the guest and may need a reboot: plan them with a current backup, the product owner's agreement and the vendor procedure, not from this article.

What not to do

• Do not turn off application quiescing as the fix. Broadcom documents setting disk.EnableUUID to FALSE as a workaround that reverts to file-system consistency (KB 428895). It changes what every later backup of the VM captures. If it is used to isolate a fault, it needs a change record, a named owner and a date to reverse it.
• Do not uninstall providers or re-register writers on production without the owner's agreement, a backup and a window.
• Do not delete shadow copies to "clean up" before recording what exists. vssadmin delete shadows removes copies that may be someone's restore points (vssadmin, Microsoft Learn).

Limitations

• Covers diagnosis inside Windows guests, not backup product configuration, Linux quiescing or SQL Server backup design.
• The event IDs are Broadcom's for this symptom; applications log their own writer events.
• Broadcom's service tables cover differing environments and disagree on one service; check the current article for your versions.
• A successful backup proves the backup path for that run. It does not prove that the application can be restored from it.
• No step here has been lab tested for this article.

Acceptance checklist

• [ ] Job time, error text, writer and provider output (with run times) and log entries with error codes saved
• [ ] Every failed writer listed with its phase, last error and hosting service
• [ ] Writers relevant to this backup identified, and the reason recorded
• [ ] Owner for each fix agreed; any restart, reinstall or provider change scheduled as a change
• [ ] No quiescing change made, or a change record exists with a reversal date
• [ ] Next scheduled backup succeeded with application quiescing, and the relevant writers read [1] Stable and No error afterwards
• [ ] Several later scheduled runs checked for recurrence, at the same busy times
• [ ] Application restore check from a quiesced backup planned or completed separately

Sources

Displayed dates as shown on each page when accessed on 30 October 2026; Broadcom pages showed no date in the retrieved copy.

• Microsoft Learn, Volume Shadow Copy Service (VSS) (2025-07-07)
• Microsoft Learn, vssadmin list writers (2024-11-01) and vssadmin (2026-09-08)
• Microsoft Learn, VSS_WRITER_STATE enumeration (2022-01-31)
• Microsoft Learn, Writers, Writer Errors and Vetoes, VSS Error Logging, In-Box VSS Writers (each 2021-01-07); Determining Writer Status (2021-03-08)
• Broadcom Knowledge, Troubleshooting Volume Shadow Copy (VSS) quiesce related issues (344277)
• Broadcom Knowledge, Quiescing issues in Windows VMs: what to collect for troubleshooting (385812)
• Broadcom Knowledge, Quiesced snapshot on Windows VM errors out with "Failed to quiesce the virtual machine" (428895)

Related articles

• Consistent backups of Linux VMs: filesystem freeze and VMware Tools freeze/thaw scripts
• VMware Tools "not running" or "out of date": what stops working and how to diagnose it

Learning notes

1. A failed writer is a symptom inside one application, not proof that VSS is broken.
2. The state names the phase; the last error names the reason. Read them together.
3. Waiting states are not failures, and status read outside a backup can show old failures.
4. Turning off application quiescing changes every later backup and is a workaround, not a fix.
5. A green scheduled run proves that run; recurrence checks and a restore test prove more.