What does HRESULT 0xC03A0024 (ERROR_CTLOG_INCONSISTENT_TRACKING_FILE) mean?

ERROR_CTLOG_INCONSISTENT_TRACKING_FILE

What this result says about the disk model: ctlog inconsistent tracking file

The practical meaning of ERROR_CTLOG_INCONSISTENT_TRACKING_FILE (0xC03A0024) is tied to resilient change-tracking baseline and sidecar metadata for the virtual disk: the tracking metadata file does not match the virtual disk identity, generation or recorded range state. The result does not, by itself, prove file-system corruption or physical-media failure.

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.

Diagnosis of this result should begin with the object model and generation current at the failure. A later successful enumeration may describe a replacement object and cannot retroactively validate the rejected request.

Capture the exact object instance

When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result.

Prove the condition in a test volume

1. serialize the failing request and the enumeration from which its identifiers came.
2. Preserve virtual-disk identifier, ChangeTrackingId, RCT state, VHDX generation, sidecar path and size, offline maintenance history and queried byte range while every handle is still valid.
3. Repeat the operation using this controlled change: create a fresh RCT baseline on a copy of the virtual disk and replay only the requested start, query, reset or stop transition.
4. Close and reacquire the relevant objects, then run once more to test lifecycle correctness after this result.

A useful diagnostic fork is ERROR_CTLOG_VHD_CHANGED_OFFLINE versus it. This code concerns the tracking metadata file does not match the virtual disk identity, generation or recorded range state; the alternate code should remain observable after the fix, proving the application did not suppress the entire subsystem.

Mechanism-specific note

The tracking file must match the virtual disk identity and generation. Preserve both files as a pair for analysis and verify timestamps, IDs and parent-chain changes. Replacing only the sidecar with one from another copy can make the metadata look readable while associating change ranges with the wrong image.

Safe recovery path

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 controlled A/B case changes only the invariant that triggers this result.
• 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 operation.
• Telemetry includes both symbolic names when it or ERROR_CTLOG_VHD_CHANGED_OFFLINE occurs again.

Technical references

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