| Previous | Next |
| ERROR_VOLSNAP_BOOTFILE_NOT_VALID | ERROR_TIERING_NOT_SUPPORTED_ON_VOLUME |
ERROR_VOLSNAP_ACTIVATION_TIMEOUT
What this result says about the disk model: volsnap activation timeout
The practical meaning of ERROR_VOLSNAP_ACTIVATION_TIMEOUT (0x80820002) is tied to persistent Volsnap activation metadata used while the volume comes online: persistent snapshot activation did not complete inside the volume-online deadline, leaving the snapshot set unavailable for that mount cycle while diagnosing this result. The result does not, by itself, prove file-system corruption or physical-media failure.
Persistent shadow copies must survive volume dismount and later activation. Volsnap therefore needs durable activation metadata and enough time to enumerate and bring the stored snapshot state online before the mount sequence proceeds for it. This object model determines which identifiers, counts and ownership state are meaningful.
Diagnosis of this result should begin with the object model and generation current at the failure while diagnosing it. A later successful enumeration may describe a replacement object and cannot retroactively validate the rejected request.
Capture the exact object generation
| Storage diagnostic field | Value |
|---|---|
| Identity and generation | volume GUID, persistent snapshot IDs, boot-support file path and size, volume-online timestamps, Volsnap/VSS events and storage latency during activation |
| Narrow experiment | create a controlled persistent snapshot on a test volume, reboot or cycle the volume online, and compare activation with a right-sized support file and low I/O load |
| Closest comparison | ERROR_VOLSNAP_BOOTFILE_NOT_VALID |
| Owning object | persistent Volsnap activation metadata used while the volume comes online |
| Rejected invariant | persistent snapshot activation did not complete inside the volume-online deadline, leaving the snapshot set unavailable for that mount cycle |
When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result.
Prove the boundary in a test volume
- Associate this result with one caller, one transaction and one target UniqueId.
- Save the pre-call and post-call inventories, including volume GUID, persistent snapshot IDs, boot-support file path and size, volume-online timestamps, Volsnap/VSS events and storage latency during activation for it.
- Use this A/B case for it without touching unrelated storage: create a controlled persistent snapshot on a test volume, reboot or cycle the volume online, and compare activation with a right-sized support file and low I/O load for it.
- Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle for it.
The distinction from ERROR_VOLSNAP_BOOTFILE_NOT_VALID is operational. The decisive condition is persistent snapshot activation did not complete inside the volume-online deadline, leaving the snapshot set unavailable for that mount cycle; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
Measure the activation interval from volume arrival through enumeration of persistent snapshots. Correlate storage latency and snapshot count with the timeout. A longer timeout may hide slow or unhealthy storage; first determine whether one snapshot or metadata file causes disproportionate delay.
Safe recovery path
Preserve Volsnap and VSS evidence, correct the support-file capacity or activation bottleneck, and verify persistent snapshots across a complete volume-online cycle for it. Keep the correction scoped to the owning object and avoid rewriting adjacent metadata merely to make the call return success.
- The controlled A/B case changes only the invariant responsible for it.
- No unrelated disk, cluster owner, tier policy or virtual-disk backing file is altered to hide this result.
- Health, synchronization or job state reaches a terminal value consistent with the repaired the operation.
- Telemetry includes both symbolic names when it or
ERROR_VOLSNAP_BOOTFILE_NOT_VALIDoccurs again.
Before responding to it with destructive cleanup, prove which object owns the failure while diagnosing it. Changing every disk or provider at once prevents a meaningful regression test while diagnosing it.
Technical references
- Microsoft: Volume Shadow Copy Service — use this source to verify volsnap state and parameters for it.
- Microsoft Open Specifications: VSS snapshot attributes — documents the supported management path relevant to it.
- Microsoft: VSS backup components — defines the volsnap objects used to interpret it.
- Microsoft: COM error codes for VOLSNAP — primary API or object-model reference for the boundary.
Looking for a different code? Search another status or error code.