IRQL_NOT_LESS_OR_EQUAL蓝屏分析

IRQL_NOT_LESS_OR_EQUAL蓝屏分析

最近有朋友遇到了一个客户电脑出现蓝屏，由于朋友最近比较忙，简单看一下没有发现问题就将dump发给我，刚好最近有点空闲时间而且自己似乎很久没有排查和分析过问题了，因此就私下分析了一下，有了今天的文章。

1. 背景

由于这个问题并非可以重现的必现问题，因此在这里只能分析一下DUMP文件，初步看一下错误码信息，如下：

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffaa098cf769e0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8042f088821, address which referenced memory
1
2
3
4
5
6
7
8
9
10
11
12

对于IRQL_NOT_LESS_OR_EQUAL这个蓝屏，是一个非常通用的问题，一般来说在DISPATCH_LEVEL以及以上的中断请求级别上面访问缺页内存或者非法内存的情况下就会导致这个问题。

从上面的摘要，我们也可以发现，此时：

1. IRQL 级别为DISPATCH_LEVEL。
2. 访问的内存为ffffaa098cf769e0。
3. 并且可以知道是读取ffffaa098cf769e0内存。

那么接下来我们就具体分析一下产生的原因。

2. 分析

首先第一件事情，我们应当看一下蓝屏发生在哪个地方，如下：

2: kd> !thread
THREAD ffffd38d08a7c080  Cid 0684.0c68  Teb: 0000000aba729000 Win32Thread: 0000000000000000 RUNNING on processor 2
Not impersonating
DeviceMap                 ffffaa098a5c8c50
Owning Process            ffffd38d0702b080       Image:         svchost.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      36169          Ticks: 50 (0:00:00:00.781)
Context Switch Count      46             IdealProcessor: 0             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address 0x00007ff944013ce0
Stack Init fffff500d6f6bdd0 Current fffff500d6f6b5a0
Base fffff500d6f6c000 Limit fffff500d6f66000 Call 0000000000000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff500`d6f6b508 fffff804`2f1d5d29 : 00000000`0000000a ffffaa09`8cf769e0 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff500`d6f6b510 fffff804`2f1d2069 : 00000000`00000000 00000000`00000003 00000000`000000a0 00000000`00000001 : nt!KiBugCheckDispatch+0x69
fffff500`d6f6b650 fffff804`2f088821 : ffffd38d`002b5d20 00000000`00000000 ffffaa09`88ddb8f0 fffff804`2f36e0a9 : nt!KiPageFault+0x469 (TrapFrame @ fffff500`d6f6b650)
fffff500`d6f6b7e0 fffff804`2f64331e : fffff804`2f373830 fffff804`00000000 00000000`00000000 ffffd38d`002b5d20 : nt!ExDeleteResourceLite+0xa1
fffff500`d6f6b830 fffff804`2f63fac0 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd38d`08a7c1c0 : nt!SepTokenDeleteMethod+0xfe
fffff500`d6f6b860 fffff804`2f04d684 : 00000000`00000000 00000000`00000000 fffff804`2f373830 ffffaa09`88ddb8f0 : nt!ObpRemoveObjectRoutine+0x80
fffff500`d6f6b8c0 fffff804`2f671660 : 00000000`00000000 ffffaa09`8a476e00 ffffaa09`8a476e00 00000000`00000000 : nt!ObfDereferenceObject+0xa4
fffff500`d6f6b900 fffff804`2f63fac0 : ffffd38d`078f63a0 00000000`00000000 ffffaa09`88ddb8f0 00000000`0017e190 : nt!AlpcpDeletePort+0x140
fffff500`d6f6b930 fffff804`2f04d684 : 00000000`00000000 00000000`00000000 fffff804`2f373830 ffffd38d`078f63d0 : nt!ObpRemoveObjectRoutine+0x80
fffff500`d6f6b990 fffff804`2f6b6100 : ffffaa09`8ef553b0 ffffaa09`8ef553b0 0000000a`ba59f988 ffffffff`ffffffff : nt!ObfDereferenceObject+0xa4
fffff500`d6f6b9d0 fffff804`2f61ce22 : 00000000`00000001 00000000`00000000 00000000`80000000 00000000`fa000000 : nt!AlpcMessageCleanupProcedure+0x30
fffff500`d6f6ba00 fffff804`2f617c4c : ffffffff`ffffffff 00000000`00000000 ffffaa09`8ef55380 00000176`ee682160 : nt!AlpcpDestroyBlob+0x32
fffff500`d6f6ba30 fffff804`2f617425 : 00000000`00000030 00000000`00000000 0000000a`ba59f968 00000000`00000000 : nt!AlpcpReceiveMessage+0x66c
fffff500`d6f6bb10 fffff804`2f1d5755 :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28