| Previous | Next |
| ERROR_CTLOG_LOGFILE_SIZE_EXCEEDED_MAXSIZE | ERROR_CTLOG_INVALID_TRACKING_STATE |
ERROR_CTLOG_VHD_CHANGED_OFFLINE
Locate the rejected storage invariant: ctlog vhd changed offline
ERROR_CTLOG_VHD_CHANGED_OFFLINE (0xC03A0022) is emitted by the ctlog path when the VHD/VHDX layout changed while tracking was not observing writes, invalidating the relationship between the log and image while diagnosing this result. The deciding object for it is resilient change-tracking baseline and sidecar metadata for the virtual disk, so the first investigation belongs there rather than in a generic “disk failure” bucket.
Resilient change tracking answers which virtual-disk byte ranges changed after a named baseline. The tracking identifier, virtual-disk generation and sidecar metadata must remain consistent across every query and backup checkpoint for it. This object model determines which identifiers, counts and ownership state are meaningful for it.
Keep the first result attached to its request parameters and object generation for it. Cleanup failures or a later drive-letter change are secondary evidence, not replacements for the original boundary.
Evidence to preserve before repair
| Storage diagnostic field | Value |
|---|---|
| Identity and generation | virtual-disk identifier, ChangeTrackingId, RCT state, VHDX generation, sidecar path and size, offline maintenance history and queried byte range |
| Narrow experiment | establish a new tracking baseline, make one online write and one offline resize or compact operation, then compare the two change queries |
| Closest comparison | ERROR_CTLOG_INCONSISTENT_TRACKING_FILE |
| Owning object | resilient change-tracking baseline and sidecar metadata for the virtual disk |
| Rejected invariant | the VHD/VHDX layout changed while tracking was not observing writes, invalidating the relationship between the log and image |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant.
One-variable reproduction
- Associate this result with one caller, one transaction and one target UniqueId for it.
- Save the pre-call and post-call inventories, including virtual-disk identifier, ChangeTrackingId, RCT state, VHDX generation, sidecar path and size, offline maintenance history and queried byte range.
- Use this A/B case for it without touching unrelated storage: establish a new tracking baseline, make one online write and one offline resize or compact operation, then compare the two change queries.
- Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle for it.
Compare traces for ERROR_CTLOG_INCONSISTENT_TRACKING_FILE and this result. The latter page covers a nearby storage boundary, whereas it rejects the VHD/VHDX layout changed while tracking was not observing writes, invalidating the relationship between the log and image. A correct caller should be able to reproduce each case independently.
Mechanism-specific note
Offline compaction, expansion, merge or editing can move data without producing tracked writes while diagnosing this result. Compare image generation and geometry with the last baseline while diagnosing it. After such maintenance, require a new full baseline rather than trying to splice old and new change ranges together.
Repair without rewriting unrelated metadata
Create a new trustworthy change-tracking baseline after validating the VHDX and tracking metadata; never merge ranges from an invalidated generation into backup state while diagnosing it. Keep the correction scoped to the owning object and avoid rewriting adjacent metadata merely to make the call return success.
- The original request now reaches success or a documented later status with the intended layout and access mode while diagnosing it.
- 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_CTLOG_INCONSISTENT_TRACKING_FILEand has no unbounded retry loop.
A reboot, blanket disk conversion or deletion of storage metadata is not a justified first response to it; it changes multiple invariants and can erase the evidence needed to identify the defect.
Technical references
- Microsoft: QueryChangesVirtualDisk — defines the ctlog objects used to interpret it.
- Microsoft: Virtual Disk API — primary API or object-model reference for the boundary.
- Microsoft: GetVirtualDiskInformation — use this source to verify ctlog state and parameters for it.
- Microsoft: COM error codes for VHD and change tracking — documents the supported management path relevant to it.
Looking for a different code? Search another status or error code.