| Previous | Next |
| DRIVER_PORTION_MUST_BE_NONPAGED | DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL |
SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD
Improper driver unload caught at raised IRQL for SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD
SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD is bug check code 0x000000D4. This bug check is a verifier-style finding: a driver unloaded without cancelling pending operations. The key issue is lifetime management of callbacks, timers, DPCs, work items, IRPs, or device objects that can still be touched after unload.
How to read it in a dump
- The name already identifies driver unload as the likely contract violation.
- Find pending operations that outlive DriverUnload, device removal, or failure cleanup.
- IRQL matters because some checks run while normal blocking cleanup is no longer possible.
What to check
- Audit DriverUnload, EvtDeviceReleaseHardware, cancel paths, timers, DPCs, work items, and queued IRPs.
- Run Driver Verifier on the suspect driver in a test system.
- Check for use-after-unload or callbacks not deregistered before unload.
References
Dump evidence
Preserve the complete dump, the four bug-check parameters, the exact Windows build, loaded-module list, and the event timeline immediately before the stop. AllStat summarizes the condition as “The driver unloaded without cancelling pending operations.”; that sentence identifies the failure class, while the parameters and stack determine which object, driver, processor, or subsystem instance was involved.
Analysis order
- Run WinDbg
!analyze -v, then inspect the documented meaning of each parameter instead of relying only on the probably-caused-by line. - find the earliest abnormal event: driver update, firmware change, device reset, storage error, verifier report, resource exhaustion, or application hang connected with system / scan / at / raised / irql.
- keep third-party filter, security, storage, graphics, and virtualization drivers in the module inventory; removing evidence before dump analysis can obscure the responsible path.
Do not repeatedly reboot a machine affected by this result before collecting the dump and event logs. Recovery actions should follow the component identified by the stack and parameters, not merely the symbolic stop-code name.
Looking for a different code? Search another status or error code.