| Previous | Next |
| STATUS_NO_PAGEFILE | STATUS_WRONG_PASSWORD_CORE |
STATUS_INVALID_LEVEL
Check the routine's IRQL requirement and the path that raised the caller
STATUS_INVALID_LEVEL can identify an execution-level contract failure in kernel code. The key evidence is the IRQL at the call site and the documented maximum or exact IRQL for the routine. It is not enough to know that the same call succeeds on another path: a callback, DPC, completion routine, or held spin lock can change the level at which identical code executes.
USBD_CreateHandle is a concrete example: Microsoft documents STATUS_INVALID_LEVEL when the caller is not running at PASSIVE_LEVEL. Many Windows DDIs publish an IRQL requirement in their requirements section because operations that allocate pageable resources, wait, or touch pageable code cannot safely run at elevated IRQL. The specific restriction must come from the called routine, not from a general guess based on its name.
Log KeGetCurrentIrql() at the failing boundary in diagnostic builds, then trace backward to the first operation that raised IRQL or entered a high-level callback. Moving the call to a worker merely to suppress the status can introduce lifetime races; preserve the referenced objects and request state until deferred execution completes. Also audit locks: calling a PASSIVE-level DDI while holding a spin lock is a design problem, not a retry condition.
What to inspect
- Compare the observed IRQL with the exact DDI requirements section.
- Trace DPC, interrupt, completion, and spin-lock paths that can raise execution level before the call.
- When deferring work, explicitly preserve object references and cancellation/lifetime state.
References
- Microsoft: USBD_CreateHandle
- Microsoft: Managing hardware priorities
- Microsoft: Introduction to DPC objects and Windows DPCs
- Microsoft: Spin locks
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.