| Previous | Next |
| ERROR_SVHDX_NO_INITIATOR | ERROR_SMB_NO_PREAUTH_INTEGRITY_HASH_OVERLAP |
ERROR_VHDSET_BACKING_STORAGE_NOT_FOUND
Why this is narrower than a generic disk error: vhdset backing storage not found
ERROR_VHDSET_BACKING_STORAGE_NOT_FOUND has unsigned value 0xC05CFF0C. In the virtdisk layer, it rejects a specific contract because a VHD Set references a backing storage file that cannot be resolved at its expected location or generation. Diagnosis of this result should follow VHD Set metadata and the backing storage file selected for the active disk through one controlled state transition.
The Virtual Disk API chooses a format provider from VIRTUAL_STORAGE_TYPE, opens an image with explicit access rights and can attach it as a disk. Provider selection, backing-chain integrity, host-file attributes, sector geometry and operating-system ownership are independent validation stages while diagnosing this result. This object model determines which identifiers, counts and ownership state are meaningful.
The standard message identifies the immediate condition, but this result also requires the producer API, object topology and attempted state transition. Capture them before an automatic refresh advances the storage generation.
Storage facts that change the diagnosis
| Storage diagnostic field | Value |
|---|---|
| Owning object | VHD Set metadata and the backing storage file selected for the active disk |
| Rejected invariant | a VHD Set references a backing storage file that cannot be resolved at its expected location or generation |
| Identity and generation | image path, VIRTUAL_STORAGE_TYPE, provider/vendor IDs, VHD/VHDX/VHD Set identifiers, host sector sizes, attach flags, ownership and online/read-only state |
| Narrow experiment | enumerate the VHD Set references, restore one missing backing file at the recorded identity, and reopen the set without rewriting its metadata |
| Closest comparison | ERROR_VIRTDISK_NOT_VIRTUAL_DISK |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant while diagnosing this result.
A/B test for this HRESULT
- Before changing state for it, freeze the failing generation and save image path, VIRTUAL_STORAGE_TYPE, provider/vendor IDs, VHD/VHDX/VHD Set identifiers, host sector sizes, attach flags, ownership and online/read-only state for it.
- Exercise this exact comparison for it: enumerate the VHD Set references, restore one missing backing file at the recorded identity, and reopen the set without rewriting its metadata.
- During the result comparison, keep image bytes, unrelated disks, provider policy and cluster topology fixed for it.
- After the test, record the next return value and the durable object state; crossing the boundary should expose a later result rather than silently retrying.
The distinction from ERROR_VIRTDISK_NOT_VIRTUAL_DISK is operational. The decisive condition is a VHD Set references a backing storage file that cannot be resolved at its expected location or generation; log the neighboring code separately so capability, identity and state are not conflated.
Mechanism-specific note
VHD Set metadata selects one or more backing files by identity, not merely by a convenient filename. Enumerate every referenced member and search cluster storage using the recorded identity. Restoring an unrelated file under the missing name can satisfy path lookup but corrupt the relationship among VHD Set members while diagnosing it.
Corrective action and regression check
Correct the provider, image format, backing-file chain, host geometry or disk ownership identified by the failing call, then reopen the image to obtain a new handle before retrying. After correcting it, reopen the pack, volume, tier, snapshot or virtual disk so no cached generation participates in the validation run while diagnosing it.
- The original request now reaches success or a documented later status with the intended layout and access mode.
- A new enumeration reports internally consistent IDs, counts, geometry and ownership for the object corrected after it.
- The passing state survives the lifecycle transition relevant to it, such as reopen, remount, owner change or detach/attach.
- The application still distinguishes it from
ERROR_VIRTDISK_NOT_VIRTUAL_DISKand has no unbounded retry loop.
Avoid broad rescans, forced failovers and metadata deletion until identities and generations are captured. Those actions can make a stale request appear to heal without fixing its caller.
Technical references
- Microsoft: Virtual Disk API — documents the supported management path relevant to it.
- Microsoft: OpenVirtualDisk — defines the virtdisk objects used to interpret it.
- Microsoft: AttachVirtualDisk — primary API or object-model reference for the boundary.
- Microsoft: GetVirtualDiskInformation — use this source to verify virtdisk state and parameters for it.
Looking for a different code? Search another status or error code.