| Previous | Next |
| ERROR_VOLMGR_DIFFERENT_SECTOR_SIZE | ERROR_VOLMGR_PACK_CONFIG_OFFLINE |
ERROR_VOLMGR_BAD_BOOT_DISK
What this result says about the disk model: volmgr bad boot disk
The practical meaning of ERROR_VOLMGR_BAD_BOOT_DISK (0xC038004F) is tied to logical volume geometry and the disk extents that realize it: the disk that carries boot-critical volume metadata is reporting failures that make the planned layout change unsafe. The result does not, by itself, prove file-system corruption or physical-media failure.
Dynamic volumes are represented as packs containing disks and volumes; each volume has one or more plexes, and each plex is assembled from members and extents. Indices and counts are relative to the submitted layout generation, while configuration logs are replicated across participating dynamic disks. 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.
Capture the exact object generation
| Storage diagnostic field | Value |
|---|---|
| Owning object | logical volume geometry and the disk extents that realize it |
| Rejected invariant | the disk that carries boot-critical volume metadata is reporting failures that make the planned layout change unsafe |
| Identity and generation | pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event |
| Narrow experiment | serialize the exact VM_VOLUME_LAYOUT buffer, validate every count and Size field, and compare it with a layout produced by a known-good management API |
| Closest comparison | ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE |
Do not overwrite this result with a close, detach or rollback error. Preserve the causal order so the original storage contract remains visible.
Prove the boundary in a test volume
- Before changing state for it, freeze the failing generation and save pack and volume IDs, input structure version and sizes, transaction ID, disk-layout snapshot before the call and the first kernel storage event for it.
- Exercise this exact comparison for it: serialize the exact VM_VOLUME_LAYOUT buffer, validate every count and Size field, and compare it with a layout produced by a known-good management API for it.
- During the result comparison, keep image bytes, unrelated disks, provider policy and cluster topology fixed while diagnosing this result.
- 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.
A useful diagnostic fork is ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGE versus this result. This code concerns the disk that carries boot-critical volume metadata is reporting failures that make the planned layout change unsafe; the alternate code should remain observable after the fix, proving the application did not suppress the entire subsystem.
Mechanism-specific note
Boot-critical placement raises the safety bar because losing the disk can affect both startup and the dynamic-disk configuration. Preserve storage health, path redundancy and recent I/O errors. Move or repair boot dependencies through supported boot and storage tooling; a successful metadata write alone does not prove the system remains bootable.
Safe recovery path
Restore access to the identified disk or extent and confirm its identity and health; do not substitute a different disk merely because its size matches while diagnosing 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 it.
- Health, synchronization or job state reaches a terminal value consistent with the repaired the operation.
- Telemetry includes both symbolic names when it or
ERROR_VOLMGR_UNEXPECTED_DISK_LAYOUT_CHANGEoccurs again.
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: COM error codes for VOLMGR, VHD and SDIAG — use this source to verify volmgr state and parameters for it.
- Microsoft: Virtual Disk Service object model — documents the supported management path relevant to it.
- Microsoft: Pack object — defines the volmgr objects used to interpret it.
- Microsoft: Virtual Disk Service common return codes — primary API or object-model reference for the boundary.
Looking for a different code? Search another status or error code.