Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL

Article
03/18/2022

The DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x000000D1. This indicates that a kernel-mode driver attempted to access pageable memory while the process IRQL that was too high.

Important

This article is for programmers. If you're a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.

DRIVER_IRQL_NOT_LESS_OR_EQUAL parameters

Parameter	Description
1	Memory referenced.
2	IRQL at time of reference.
3	0 - Read 1 - Write 2 - Execute 8 - Execute
4	Address that referenced memory. Use ln (list nearest symbols) on this address to see the name of the function.

Cause

To determine the cause requires the Windows debugger, programming experience and access to the source code for the faulting module.

Typically, when this error occurs, a driver has tried to access an address that is pageable (or that is completely invalid) while the interrupt request level (IRQL) was too high. This can be caused by:

Dereferencing a bad pointer (such as a NULL or freed pointer) while executing at or above DISPATCH_LEVEL.
Accessing pageable data at or above DISPATCH_LEVEL.
Executing pageable code at or above DISPATCH_LEVEL.

If a driver that is responsible for the error can be identified, its name is printed on the blue screen and stored in memory at the location (PUNICODE_STRING) KiBugCheckDriver. You can use dx (display debugger object model expression), a debugger command, to display this: dx KiBugCheckDriver.

This bug check is usually caused by drivers that have used improper memory addresses.

Possible causes for the page fault include the following events:

The function was marked as pageable and was running at an elevated IRQL (which includes obtaining a lock).
The function call was made to a function in another driver, and that driver was unloaded.
The function was called by using a function pointer that was an invalid pointer.

For more information on Windows IRQLs, see Windows Internals 7th Edition Part 1 by Pavel Yosifovich, Mark E. Russinovich, David A. Solomon and Alex Ionescu.

Resolution

If the problem is caused by the driver that you are developing, make sure that the function that was executing at the time of the bug check is:

Not marked as pageable
Does not call any other inline functions that could be paged out.

The !analyze debugger extension displays information about the bug check and can be helpful in determining the root cause. The following example is output from !analyze.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: fffff808add27150, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff808adc386a6, address which referenced memory

0: kd> dx KiBugCheckDriver
KiBugCheckDriver                 : 0xffffc6092de892c8 : "Wdf01000.sys" [Type: _UNICODE_STRING *]

If a trap frame is available in the dump file, use the .trap command to set your context to the provided address.

To start debugging this type of bug check, examine the stack trace by using the k, kb, kc, kd, kp, kP, kv (display stack backtrace) commands.

In the debugger, run the !irql command to display information about the IRQL of a processor on the target computer before the debugger break. For example:

0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

In the majority of cases of this type of bug check, the issue is not the IRQL level, but rather the memory that is being accessed.

Because this bug check is usually caused by drivers that have used improper memory addresses, use parameters 1, 3, and 4 to investigate further.

Use ln (list nearest symbols) with parameter 4 to see the name of the function that was called. Also examine the !analyze output to see if faulting code is identified.

Use !pool on the parameter 1 address to see whether it is paged pool. Use !address and the advanced !pte command to learn more about this area of memory.

Use the display memory commands to examine the memory referenced in command in parameter 1.

Use the u, ub, uu (unassemble) commands to look at the code in the address which referenced the memory in parameter 4.

Use the command lm t n to list modules that are loaded in the memory. Use !memusage and to examine the general state of the system memory.

Driver Verifier

Driver Verifier is a tool that runs in real time to examine the behavior of drivers. For example, Driver Verifier checks the use of memory resources, such as memory pools. If it identifies errors in the execution of driver code, it proactively creates an exception to allow that part of the driver code to be further scrutinized. Driver Verifier Manager is built into Windows and is available on all Windows PCs.

To start Driver Verifier Manager, type verifier at a command prompt. You can configure which drivers to verify. The code that verifies drivers adds overhead as it runs, so try to verify the smallest number of drivers possible. For more information, see Driver Verifier.

Remarks

If you are not equipped to use the Windows debugger to work on this problem, you can use some basic troubleshooting techniques.

Check the System Log in Event Viewer for additional error messages that might help identify the device or driver that is causing this bug check.
If a driver is identified in the bug check message, disable the driver or check with the manufacturer for driver updates.
Confirm that any new hardware that is installed is compatible with the installed version of Windows. For example, you can get information about required hardware at Windows 10 Specifications.

For additional general troubleshooting information, see Blue screen data.