| Previous | Next |
| ERROR_CTLOG_TRACKING_NOT_INITIALIZED | ERROR_CTLOG_VHD_CHANGED_OFFLINE |
ERROR_CTLOG_LOGFILE_SIZE_EXCEEDED_MAXSIZE
Interpret the state transition: ctlog logfile size exceeded maxsize
ERROR_CTLOG_LOGFILE_SIZE_EXCEEDED_MAXSIZE has unsigned value 0xC03A0021. In the ctlog layer, it rejects a specific contract because the sidecar change-tracking log grew beyond its supported maximum before a new baseline was established. Diagnosis of this result should follow resilient change-tracking baseline and sidecar metadata for the virtual disk through one controlled state transition.
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 for it. A later successful enumeration may describe a replacement object and cannot retroactively validate the rejected request for it.
Record geometry, identity and ownership
| Storage diagnostic field | Value |
|---|---|
| Rejected invariant | the sidecar change-tracking log grew beyond its supported maximum before a new baseline was established |
| Identity and generation | virtual-disk identifier, ChangeTrackingId, RCT state, VHDX generation, sidecar path and size, offline maintenance history and queried byte range |
| Narrow experiment | measure the sidecar growth under controlled writes, seal a new baseline before the limit, and compare with a run that intentionally crosses the limit |
| Closest comparison | ERROR_CTLOG_INVALID_TRACKING_STATE |
| Owning object | resilient change-tracking baseline and sidecar metadata for the virtual disk |
Keep this HRESULT as the primary result if rollback or cleanup reports another code; those later values describe recovery, not the first rejected invariant.
Separate validation from capability
- Create a nonproduction case for it that preserves the same geometry and ownership model.
- Collect virtual-disk identifier, ChangeTrackingId, RCT state, VHDX generation, sidecar path and size, offline maintenance history and queried byte range before invoking the first mutating API.
- Change one condition only: measure the sidecar growth under controlled writes, seal a new baseline before the limit, and compare with a run that intentionally crosses the limit.
- Re-enumerate after the transition and confirm this result is not reproduced by a stale handle from the old generation for it.
Use ERROR_CTLOG_INVALID_TRACKING_STATE as the nearest comparison. This result is specific to the sidecar change-tracking log grew beyond its supported maximum before a new baseline was established; the neighboring result belongs to another validation or lifecycle branch while diagnosing it. Keeping both names prevents a generic storage label from hiding the actual owner.
Mechanism-specific note
RCT sidecar growth reflects accumulated changes and baseline lifetime. Record write workload, log size and the last successfully sealed tracking ID. Establishing checkpoints more frequently may control growth, but deleting the sidecar without resetting the backup baseline produces an unverifiable delta chain.
Verification after correction
Create a new trustworthy change-tracking baseline after validating the VHDX and tracking metadata; never merge ranges from an invalidated generation into backup state for 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_CTLOG_INVALID_TRACKING_STATEoccurs again.
Avoid broad rescans, forced failovers and metadata deletion until identities and generations are captured for it. Those actions can make a stale request appear to heal without fixing its caller.
Technical references
- Microsoft: QueryChangesVirtualDisk — documents the supported management path relevant to it.
- Microsoft: Virtual Disk API — defines the ctlog objects used to interpret it.
- Microsoft: GetVirtualDiskInformation — primary API or object-model reference for the boundary.
- Microsoft: COM error codes for VHD and change tracking — use this source to verify ctlog state and parameters for it.
Looking for a different code? Search another status or error code.