Troubleshooting 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL

The Debugging Tools for Windows are required to analyze crash dump files. If you do not have the Debugging Tools for Windows installed or dump files are not being generated on system crash, see this post for installation/configuration instructions:
http://mikemstech.blogspot.com/2011/11/windows-crash-dump-analysis.html

The blue screen of death (BSOD) caused by the bug code 0xD1 (209 in decimal), DRIVER_IRQL_NOT_LESS_OR_EQUAL, is an error that is very similar to 0xA IRQL_NOT_LESS_OR_EQUAL (see this article for a discussion of how the system uses IRQLs). The main difference between DRIVER_IRQL_NOT_LESS_OR_EQUAL and IRQL_NOT_LESS_OR_EQUAL is that DRIVER_IRQL_NOT_LESS_OR_EQUAL always occurs with a kernel mode driver and IRQL_NOT_LESS_OR_EQUAL can occur with kernel mode drivers and system components (such as the kernel). Debugging follows the same principles as IRQL_NOT_LESS_OR_EQUAL where the output of !analyze -v often shows the driver that caused the error to occur.

Below is an example of debugging this error. Load the crash dump into WinDbg following this procedure and execute !analyze -v.

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

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: 0000000000000032, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800149880a, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002f03100
 0000000000000032 

CURRENT_IRQL:  2

FAULTING_IP: 
ndis!NdisMFreeNetBufferSGList+a
fffff880`0149880a 41f6403204      test    byte ptr [r8+32h],4

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  utorrent.exe

TRAP_FRAME:  fffff8800bbe1fe0 -- (.trap 0xfffff8800bbe1fe0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000000000cc rbx=0000000000000000 rcx=fffffa8005b66390
rdx=fffffa8005d880f0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8800149880a rsp=fffff8800bbe2170 rbp=0000000000000000
 r8=0000000000000000  r9=00000000000000cc r10=fffffa8005c9f580
r11=0000000000000001 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
ndis!NdisMFreeNetBufferSGList+0xa:
fffff880`0149880a 41f6403204      test    byte ptr [r8+32h],4 ds:ca80:00000000`00000032=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002cd01e9 to fffff80002cd0c40

STACK_TEXT:  
fffff880`0bbe1e98 fffff800`02cd01e9 : 00000000`0000000a 00000000`00000032 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0bbe1ea0 fffff800`02ccee60 : fffff880`0bbe2060 00000000`00000000 fffffa80`035ed6e0 fffffa80`05cb6bd0 : nt!KiBugCheckDispatch+0x69
fffff880`0bbe1fe0 fffff880`0149880a : fffffa80`05c9f580 fffffa80`0747f240 fffffa80`05d88120 00000000`0000001e : nt!KiPageFault+0x260
fffff880`0bbe2170 fffff880`0fdda71a : fffffa80`05cb6bd0 fffff800`02c0d593 fffffa80`05cb6bd0 fffffa80`05c9f500 : ndis!NdisMFreeNetBufferSGList+0xa
fffff880`0bbe21b0 fffffa80`05cb6bd0 : fffff800`02c0d593 fffffa80`05cb6bd0 fffffa80`05c9f500 00000000`00000a80 : L1C62x64+0x571a
fffff880`0bbe21b8 fffff800`02c0d593 : fffffa80`05cb6bd0 fffffa80`05c9f500 00000000`00000a80 00000000`00000000 : 0xfffffa80`05cb6bd0
fffff880`0bbe21c0 fffff800`02c104fb : fffffa80`05d88120 fffffa80`05c9f580 fffffa80`0794ca38 fffff880`0fddd6b1 : hal!HalpDmaMapScatterTransfer+0xa3
fffff880`0bbe2210 fffff800`02c10472 : fffffa80`03a468a0 fffffa80`05d880f0 fffffa80`0794ca9e 00000000`00000000 : hal!HalpMapTransfer+0x7b
fffff880`0bbe22a0 fffff800`02c0f9ce : fffffa80`05d88120 fffff800`02c0d01e 00000000`00000000 fffffa80`05cb6bd0 : hal!IoMapTransfer+0x8e
fffff880`0bbe22e0 fffff800`02c1013d : fffffa80`0588b050 fffffa80`05c9f580 fffffa80`05c9f501 00000000`00000000 : hal!HalpAllocateAdapterCallback+0x146
fffff880`0bbe2380 fffff800`02c0f71f : fffffa80`05d880c0 00000000`0000006e fffffa80`05c9f580 fffffa80`03739f60 : hal!HalAllocateAdapterChannel+0x101
fffff880`0bbe23c0 fffff880`014987c1 : fffffa80`03739e80 fffffa80`03739e80 00000000`000000a0 00000000`00000000 : hal!HalBuildScatterGatherList+0x2f3
fffff880`0bbe2430 fffff880`0fdda534 : fffffa80`0588b1a0 00000000`00000000 fffffa80`05ce85e0 fffffa80`03739e80 : ndis!NdisMAllocateNetBufferSGList+0x181
fffff880`0bbe24d0 fffffa80`0588b1a0 : 00000000`00000000 fffffa80`05ce85e0 fffffa80`03739e80 fffffa80`05d880c0 : L1C62x64+0x5534
fffff880`0bbe24d8 00000000`00000000 : fffffa80`05ce85e0 fffffa80`03739e80 fffffa80`05d880c0 fffffa80`000001c0 : 0xfffffa80`0588b1a0


STACK_COMMAND:  kb

FOLLOWUP_IP: 
L1C62x64+571a
fffff880`0fdda71a ??              ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  L1C62x64+571a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: L1C62x64

IMAGE_NAME:  L1C62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  49d2f6fd

FAILURE_BUCKET_ID:  X64_0xD1_L1C62x64+571a

BUCKET_ID:  X64_0xD1_L1C62x64+571a

Followup: MachineOwner
---------
 

The driver that is blamed is L1C62x64.sys. This particular driver is for an Atheros Gigabit NIC. The timestamp of the driver obtained using lmvm L1C62x64 shows that this driver is from 2009. This should be updated to a more recent version, with any luck this will solve the blue screen issue. Note that since I don't have this driver installed on the system that I am using to perform the debugging, limited information is returned from lmvm, but since we are mainly interested in the time stamp of the driver, this is still returned successfully.

0: kd> lmvm L1C62x64
start             end                 module name
fffff880`0fdd5000 fffff880`0fde7000   L1C62x64 T (no symbols)           
    Loaded symbol image file: L1C62x64.sys
    Image path: \SystemRoot\system32\DRIVERS\L1C62x64.sys
    Image name: L1C62x64.sys
    Timestamp:        Tue Mar 31 23:09:17 2009 (49D2F6FD)
    CheckSum:         0001660A
    ImageSize:        00012000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
  

The driver returned by your analysis will most likely be different, but the troubleshooting methodology will likely remain the same. Use the !analyze -v debugger command to identify the driver and use the lmvm <driver_name> command to identify the time stamp of the driver. Note that if the system kernel (ntoskrnl.exe, ntkrnlpa.exe, ntkrnlmp.exe, and ntkrnlpamp.exe) is identified, then the driver verifier may be necessary to troubleshoot further.

Have an idea for something that you'd like to see explored? Leave a comment or send an e-mail to razorbackx_at_gmail<dot>com

References

0xd1 on MSDN