| Previous | Next |
| ERROR_CTLOG_INVALID_TRACKING_STATE | ERROR_VHD_RESIZE_WOULD_TRUNCATE_DATA |
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 while diagnosing this result. 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 for it. The tracking identifier, virtual-disk generation and sidecar metadata must remain consistent across every query and backup checkpoint. This object model determines which identifiers, counts and ownership state are meaningful.
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 while diagnosing it.
Capture the exact object generation
| Storage diagnostic field | Value |
|---|---|
| Closest comparison | ERROR_CTLOG_VHD_CHANGED_OFFLINE |
| Owning object | resilient change-tracking baseline and sidecar metadata for the virtual disk |
| Rejected invariant | the tracking metadata file does not match the virtual disk identity, generation or recorded range state |
| Identity and generation | virtual-disk identifier, ChangeTrackingId, RCT state, VHDX generation, sidecar path and size, offline maintenance history and queried byte range |
| Narrow experiment | create a fresh RCT baseline on a copy of the virtual disk and replay only the requested start, query, reset or stop transition |
When it is followed by a secondary cleanup failure, store both codes with timestamps and retain this one as the initiating result.
Prove the boundary in a test volume
- serialize the failing request and the enumeration from which its identifiers came while diagnosing this result.
- 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 for it.
- 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.
- 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 while diagnosing it.
Mechanism-specific note
The tracking file must match the virtual disk identity and generation while diagnosing it. 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 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_CTLOG_VHD_CHANGED_OFFLINEoccurs again.
Do not use it as a reason to edit dynamic-disk sectors, VHDX metadata, RCT sidecars or snapshot support files directly. Unsupported edits can turn a recoverable state mismatch into persistent corruption.
Technical references
- Microsoft: QueryChangesVirtualDisk — use this source to verify ctlog state and parameters for it.
- Microsoft: Virtual Disk API — documents the supported management path relevant to it.
- 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 for the boundary.
Looking for a different code? Search another status or error code.