Kernel mechanisms (IRQL, DPC, interrupts)
Low-level execution rules that explain driver bugs, lost interrupts, and why some code cannot sleep.
What you should already know
This topic is marked expert. Skim these first if any of them feel unfamiliar.
Official Microsoft docs
Closest official references related to this topic on Microsoft Learn.
Why it matters
Driver and kernel troubleshooting often comes down to IRQL, deferred procedure calls, and interrupt service routines. Misunderstanding these leads to deadlocks and corruption.
Mental model
Windows prioritizes interrupt-driven work. IRQL is a ceiling on what APIs you may call; DPCs defer work from ISR context to a safer IRQL.
How it works
- 1Hardware raises interrupts; ISRs run at high IRQL and should do minimal work.
- 2DPCs queue additional work to run later at DISPATCH_LEVEL.
- 3Most executive APIs require PASSIVE_LEVEL; violating that causes bugchecks or subtle corruption.
Key terms
- IRQL
- Interrupt Request Level; governs which kernel APIs are legal.
- DPC
- Deferred Procedure Call; runs after ISR at DISPATCH_LEVEL.
- ISR
- Interrupt Service Routine; first handler for a hardware interrupt.
A driver that calls file I/O from a DPC
File I/O requires PASSIVE_LEVEL. Calling it from a DPC (DISPATCH_LEVEL) is illegal and may trigger DRIVER_IRQL_NOT_LESS_OR_EQUAL.
Common misconception
People treat 'kernel mode' as one uniform environment. IRQL and wait rules split kernel code into very different execution contexts.
You should read next
Ranked from your current topic, related links, branch depth, and any active guided path.
intermediate
HAL & boot
Hardware abstraction and the path from firmware to the running kernel.
Related topic
intermediate
Drivers & device stacks
Function, filter, bus, class, and miniport drivers in layered request handling.
Related topic
intermediate
ETW tracing
Real-time sessions, controllers, and consumers for higher-volume tracing.
Related topic