What does NTSTATUS 0xC0000229 (STATUS_FAIL_CHECK) mean?

 
Previous Next
STATUS_STACK_OVERFLOW_READ STATUS_DUPLICATE_OBJECTID

STATUS_FAIL_CHECK

Treat a failed consistency check as evidence of broken state, not a user-facing validation hint

STATUS_FAIL_CHECK points to an internal invariant failure rather than ordinary caller input validation. Unlike a parameter status, it does not identify a public argument that the caller can simply change. The important evidence is the invariant being checked and the component that detected it. By the time the status reaches a higher layer, the original mismatch can already be several calls earlier.

For code you own, find the exact return site or assertion-like branch and record both sides of the failed invariant: counts, generation values, object states, list membership, or IDs. A useful log says “expected generation 41, found 39” rather than only printing the NTSTATUS. In driver development, Driver Verifier's I/O verification and other rule classes are designed to expose incorrect object and IRP handling closer to the source, often by stopping on a specific violation instead of allowing corrupted state to propagate.

Do not automatically retry a consistency failure. A retry is safe only if the owning contract explicitly declares the state transient and reconstructs the checked data. Reusing partially modified objects can make later evidence less reliable. Preserve a dump or trace around the first occurrence, audit concurrency and lifetime transitions, and compare the failing object with a newly initialized instance of the same type.

What to inspect

  • Locate the component and exact invariant check that produced the status.
  • Log expected and observed state values, including generation counters and object lifecycle state.
  • Prefer first-failure dumps and verifier instrumentation over repeated retries that mutate the evidence.

References

Looking for a different code? Search another status or error code.