What does HRESULT 0xC03A0022 (ERROR_CTLOG_VHD_CHANGED_OFFLINE) mean?

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. The deciding object 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.

Keep the first result attached to its request parameters and object instance. Cleanup failures or a later drive-letter change are secondary evidence, not replacements for the original failure.

Evidence to preserve before repair

One-variable reproduction

1. Associate this result with one caller, one transaction and one target UniqueId.
2. 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.
3. Use this A/B case 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.
4. Validate both the HRESULT and the on-disk or provider state after the relevant reopen, remount or attach cycle.

ERROR_CTLOG_INCONSISTENT_TRACKING_FILE describes a nearby but different storage condition; this result indicates that the VHD/VHDX layout changed while tracking was not observing writes, invalidating the relationship between the log and image.

Mechanism-specific note

Offline compaction, expansion, merge or editing can move data without producing tracked writes. Compare image generation and geometry with the last baseline. 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. 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.
• A new enumeration reports internally consistent IDs, counts, geometry and ownership for the corrected object.
• The application still distinguishes it from ERROR_CTLOG_INCONSISTENT_TRACKING_FILE and has no unbounded retry loop.

Technical references

• Microsoft: QueryChangesVirtualDisk — defines the ctlog objects used to interpret it.
• Microsoft: Virtual Disk API — primary API or object-model reference.
• Microsoft: GetVirtualDiskInformation — use this source to verify ctlog state and parameters.
• Microsoft: COM error codes for VHD and change tracking — documents the supported management path relevant to this HRESULT.