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 operationbit 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

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

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

IRQL 级别为DISPATCH_LEVEL。
访问的内存为ffffaa098cf769e0。
并且可以知道是读取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 : ffffd38d`08a7c080 fffff500`d6f6bcc0 fffff500`d6f6bbe8 00000000`00000000 : nt!NtAlpcSendWaitReceivePort+0x105
fffff500`d6f6bbd0 00007ff9`4407dfd4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ fffff500`d6f6bc40)
0000000a`ba59f918 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff9`4407dfd4

看到这个堆栈，就比较尴尬了，因为我们初步只能得出如下信息：

进程是svchost.exe，非常通用的进程，这个进程似乎对于我们用途不大。
整个调用堆栈蓝屏在了系统调用堆栈，没有任何第三方驱动，无法进行甩锅。
ExDeleteResourceLite 删除资源锁，这个似乎没有一点用途。
还有一个比困难的地方，是x64环境，分析要稍微复杂一点。

那么，这个问题到这里是否就无解了呢？

其实我们还能进行部分分析的，我们可以分析至少几个点：

ExDeleteResourceLite是在操作哪个资源？
操作资源崩溃的原因？
这个进程在进行什么操作？

如果得出这些问题，那么也许问题七七八八也能猜出一些，我们先来看一下第一个问题，这个调用堆栈在干嘛？

其实，很明显可以发现，这个操作是在删除Port，然后附带删除其相关Token，以及Resource；通过分析我们可以得到删除的Port信息如下(分析过程没啥技术含量，我们就直接放上结果）：

2: kd> dt nt!_ALPC_PORT ffffd38d078f63d0+0x000 PortListEntry    : _LIST_ENTRY [ 0xffffd38d`06d44790 - 0xffffd38d`07072530 ]+0x010 CommunicationInfo : (null) +0x018 OwnerProcess     : 0xffffd38d`06d8d081 _EPROCESS+0x020 CompletionPort   : (null) +0x028 CompletionKey    : (null) +0x030 CompletionPacketLookaside : (null) +0x038 PortContext      : 0x00000000`000003f8 Void+0x040 StaticSecurity   : _SECURITY_CLIENT_CONTEXT+0x088 IncomingQueueLock : _EX_PUSH_LOCK+0x090 MainQueue        : _LIST_ENTRY [ 0xffffd38d`078f6460 - 0xffffd38d`078f6460 ]+0x0a0 LargeMessageQueue : _LIST_ENTRY [ 0xffffd38d`078f6470 - 0xffffd38d`078f6470 ]+0x0b0 PendingQueueLock : _EX_PUSH_LOCK+0x0b8 PendingQueue     : _LIST_ENTRY [ 0xffffd38d`078f6488 - 0xffffd38d`078f6488 ]+0x0c8 DirectQueueLock  : _EX_PUSH_LOCK+0x0d0 DirectQueue      : _LIST_ENTRY [ 0xffffd38d`078f64a0 - 0xffffd38d`078f64a0 ]+0x0e0 WaitQueueLock    : _EX_PUSH_LOCK+0x0e8 WaitQueue        : _LIST_ENTRY [ 0xffffd38d`078f64b8 - 0xffffd38d`078f64b8 ]+0x0f8 Semaphore        : 0xffffd38d`00250300 _KSEMAPHORE+0x0f8 DummyEvent       : 0xffffd38d`00250300 _KEVENT+0x100 PortAttributes   : _ALPC_PORT_ATTRIBUTES+0x148 ResourceListLock : _EX_PUSH_LOCK+0x150 ResourceListHead : _LIST_ENTRY [ 0xffffd38d`078f6520 - 0xffffd38d`078f6520 ]+0x160 PortObjectLock   : _EX_PUSH_LOCK+0x168 CompletionList   : (null) +0x170 CallbackObject   : (null) +0x178 CallbackContext  : (null) +0x180 CanceledQueue    : _LIST_ENTRY [ 0xffffd38d`078f6550 - 0xffffd38d`078f6550 ]+0x190 SequenceNo       : 0n20+0x194 ReferenceNo      : 0n0+0x198 ReferenceNoWait  : (null) +0x1a0 u1               : <anonymous-tag>+0x1a8 TargetQueuePort  : 0xffffd38d`06ea5a20 _ALPC_PORT+0x1b0 TargetSequencePort : 0xffffd38d`06d44790 _ALPC_PORT+0x1b8 CachedMessage    : (null) +0x1c0 MainQueueLength  : 0+0x1c4 LargeMessageQueueLength : 0+0x1c8 PendingQueueLength : 0+0x1cc DirectQueueLength : 0+0x1d0 CanceledQueueLength : 0+0x1d4 WaitQueueLength  : 0

继续分析，我们可以得到SepTokenDeleteMethod释放的是+0x040 StaticSecurity : _SECURITY_CLIENT_CONTEXT这个里面的Token资源，如下：

2: kd> dx -id 0,0,ffffd38d0702b080 -r1 (*((ntkrnlmp!_SECURITY_CLIENT_CONTEXT *)0xffffd38d078f6410))
(*((ntkrnlmp!_SECURITY_CLIENT_CONTEXT *)0xffffd38d078f6410))                 [Type: _SECURITY_CLIENT_CONTEXT][+0x000] SecurityQos      [Type: _SECURITY_QUALITY_OF_SERVICE][+0x010] ClientToken      : 0xffffaa0988ddb8f0 [Type: void *][+0x018] DirectlyAccessClientToken : 0x0 [Type: unsigned char][+0x019] DirectAccessEffectiveOnly : 0x0 [Type: unsigned char][+0x01a] ServerIsRemote   : 0x0 [Type: unsigned char][+0x01c] ClientTokenControl [Type: _TOKEN_CONTROL]

至于这个Token，我们可以看一下具体的信息，如下：

2: kd> dt nt!_TOKEN 0xffffaa0988ddb8f0+0x000 TokenSource      : _TOKEN_SOURCE+0x010 TokenId          : _LUID+0x018 AuthenticationId : _LUID+0x020 ParentTokenId    : _LUID+0x028 ExpirationTime   : _LARGE_INTEGER 0x06207526`b64ceb90+0x030 TokenLock        : 0xffffd38d`08f1cd90 _ERESOURCE+0x038 ModifiedId       : _LUID+0x040 Privileges       : _SEP_TOKEN_PRIVILEGES+0x058 AuditPolicy      : _SEP_AUDIT_POLICY+0x078 SessionId        : 0+0x07c UserAndGroupCount : 0xc+0x080 RestrictedSidCount : 0+0x084 VariableLength   : 0x19c+0x088 DynamicCharged   : 0x1000+0x08c DynamicAvailable : 0+0x090 DefaultOwnerIndex : 0+0x098 UserAndGroups    : 0xffffaa09`88ddbd80 _SID_AND_ATTRIBUTES+0x0a0 RestrictedSids   : (null) +0x0a8 PrimaryGroup     : 0xffffaa09`8e1ee390 Void+0x0b0 DynamicPart      : 0xffffaa09`8e1ee390  -> 0x101+0x0b8 DefaultDacl      : 0xffffaa09`8e1ee39c _ACL+0x0c0 TokenType        : 2 ( TokenImpersonation )+0x0c4 ImpersonationLevel : 2 ( SecurityImpersonation )+0x0c8 TokenFlags       : 0x2800+0x0cc TokenInUse       : 0 ''+0x0d0 IntegrityLevelIndex : 1+0x0d4 MandatoryPolicy  : 3+0x0d8 LogonSession     : 0xffffaa09`84805c70 _SEP_LOGON_SESSION_REFERENCES+0x0e0 OriginatingLogonSession : _LUID+0x0e8 SidHash          : _SID_AND_ATTRIBUTES_HASH+0x1f8 RestrictedSidHash : _SID_AND_ATTRIBUTES_HASH+0x308 pSecurityAttributes : 0xffffaa09`8efea8d0 _AUTHZBASEP_SECURITY_ATTRIBUTES_INFORMATION+0x310 Package          : (null) +0x318 Capabilities     : (null) +0x320 CapabilityCount  : 0+0x328 CapabilitiesHash : _SID_AND_ATTRIBUTES_HASH+0x438 LowboxNumberEntry : (null) +0x440 LowboxHandlesEntry : (null) +0x448 pClaimAttributes : (null) +0x450 TrustLevelSid    : (null) +0x458 TrustLinkedToken : (null) +0x460 IntegrityLevelSidValue : (null) +0x468 TokenSidValues   : (null) +0x470 IndexEntry       : 0xffffaa09`8a675350 _SEP_LUID_TO_INDEX_MAP_ENTRY+0x478 DiagnosticInfo   : (null) +0x480 BnoIsolationHandlesEntry : (null) +0x488 SessionObject    : (null) +0x490 VariablePart     : 0xffffaa09`88ddbe40

并且通过汇编代码

fffff804`2f643310 488b4b30        mov     rcx,qword ptr [rbx+30h]
fffff804`2f643314 4885c9          test    rcx,rcx
fffff804`2f643317 7410            je      nt!SepTokenDeleteMethod+0x109 (fffff804`2f643329)
fffff804`2f643319 e86254a4ff      call    nt!ExDeleteResourceLite (fffff804`2f088780)

可以得知，删除的是+0x030 TokenLock : 0xffffd38d08f1cd90 _ERESOURCE这个资源锁，我们看一下这个资源锁：

2: kd> dx -id 0,0,ffffd38d0702b080 -r1 ((ntkrnlmp!_ERESOURCE *)0xffffd38d08f1cd90)
((ntkrnlmp!_ERESOURCE *)0xffffd38d08f1cd90)                 : 0xffffd38d08f1cd90 [Type: _ERESOURCE *][+0x000] SystemResourcesList [Type: _LIST_ENTRY][+0x010] OwnerTable       : 0x0 [Type: _OWNER_ENTRY *][+0x018] ActiveCount      : 0 [Type: short][+0x01a] Flag             : 0x0 [Type: unsigned short][+0x01a] ReservedLowFlags : 0x0 [Type: unsigned char][+0x01b] WaiterPriority   : 0x0 [Type: unsigned char][+0x020] SharedWaiters    : 0x0 [Type: void *][+0x028] ExclusiveWaiters : 0x0 [Type: void *][+0x030] OwnerEntry       [Type: _OWNER_ENTRY][+0x040] ActiveEntries    : 0x0 [Type: unsigned long][+0x044] ContentionCount  : 0x0 [Type: unsigned long][+0x048] NumberOfSharedWaiters : 0x0 [Type: unsigned long][+0x04c] NumberOfExclusiveWaiters : 0x0 [Type: unsigned long][+0x050] Reserved2        : 0x0 [Type: void *][+0x058] Address          : 0x0 [Type: void *][+0x058] CreatorBackTraceIndex : 0x0 [Type: unsigned __int64][+0x060] SpinLock         : 0x0 [Type: unsigned __int64]

熟悉Windows驱动的朋友，应该对于_ERESOURCE这个结构非常熟悉了，ExDeleteResourceLite一个重要操作就是摘除SystemResourcesList链表，我们这里看一下崩溃的代码：

fffff804`2f088814 0f859ed41800    jne     nt!ExDeleteResourceLite+0x18d538 (fffff804`2f215cb8)
fffff804`2f08881a 488b13          mov     rdx,qword ptr [rbx]
fffff804`2f08881d 488b4308        mov     rax,qword ptr [rbx+8]
fffff804`2f088821 48395a08        cmp     qword ptr [rdx+8],rbx
fffff804`2f088825 0f853fd61800    jne     nt!ExDeleteResourceLite+0x18d6ea (fffff804`2f215e6a)

刚好是在移除这个链表，其实我们如果细心的话，看应发现SystemResourcesList就是我们最初分析的内存，这链表如下：

2: kd> dx -r1 (*((ntkrnlmp!_LIST_ENTRY *)0xffffd38d08f1cd90))
(*((ntkrnlmp!_LIST_ENTRY *)0xffffd38d08f1cd90))                 [Type: _LIST_ENTRY][+0x000] Flink            : 0xffffaa098cf769d8 [Type: _LIST_ENTRY *][+0x008] Blink            : 0xffffd38d089a6790 [Type: _LIST_ENTRY *]2: kd> dq 0xffffaa098cf769d8
Page 200165cf9 too large to be in the dump file.
ffffaa09`8cf769d8  ????????`???????? ????????`????????
ffffaa09`8cf769e8  ????????`???????? ????????`????????
ffffaa09`8cf769f8  ????????`???????? ????????`????????
ffffaa09`8cf76a08  ????????`???????? ????????`????????
ffffaa09`8cf76a18  ????????`???????? ????????`????????
ffffaa09`8cf76a28  ????????`???????? ????????`????????
ffffaa09`8cf76a38  ????????`???????? ????????`????????
ffffaa09`8cf76a48  ????????`???????? ????????`????????
2: kd> dq 0xffffd38d089a6790
ffffd38d`089a6790  ffffd38d`08f1cd90 ffffd38d`08f1a010
ffffd38d`089a67a0  00000000`00000000 00000000`00000000
ffffd38d`089a67b0  00000000`00000000 00000000`00000000
ffffd38d`089a67c0  00000000`00000000 00000000`00000000
ffffd38d`089a67d0  00000000`00000000 00000000`00000000
ffffd38d`089a67e0  00000000`00000000 00000000`00000000
ffffd38d`089a67f0  00000000`00000000 00000000`00000000
ffffd38d`089a6800  6c546553`02080000 00000000`000000002: kd> !pool 0xffffaa098cf769d8
Pool page ffffaa098cf769d8 region is Paged pool
Page 200165cf9 too large to be in the dump file.
Page 200165cf9 too large to be in the dump file.
ffffaa098cf76000 is not a valid large pool allocation, checking large session pool...
ffffaa098cf76000 is not valid pool. Checking for freed (or corrupt) pool
Address ffffaa098cf76000 could not be read. It may be a freed, invalid or paged out page

对于这个链表的Flink我们看应看到是非法的内存，也就是说很有可能是下一个_ERESOURCE的内存被释放了，但是没有ExDeleteResourceLite，导致我们这里调用ExDeleteResourceLite出现访问崩溃。

产生这个问题的原因大致可能有如下：

驱动中使用了_ERESOURCE，但是在驱动卸载的时候并没有调用ExDeleteResourceLite。
驱动使用了_ERESOURCE，在Pool分配的内存，但是删除Pool的时候并没有调用ExDeleteResourceLite释放锁。
当然还有可能就是第三方驱动使用_ERESOURCE是分页内存，不过这个概率比较小。

那么问题到这里是否还能有进一步的思路呢？个人觉得还要继续分析真实的原因应该是比较困难了，但是并不是不可能的，因为排查问题有时候跟运气也有一点点关系的，说不定什么时候眼睛一瞥刚好就发现了问题呢！

当然我们还可以从如下点发现一些蛛丝马迹：

当前进程运行状态。
驱动加载和卸载情况。
Pool内存池的状态。
Windows的系统日志

但是本人觉得我已经没有必要再分析下去了，因为再往下个人觉得以及不再是技术上面的问题了，问题到此为止。

3. 总结

通过上面分析我们可以发现，在写代码的时候，往往失之毫厘，差之千里；往往自己一个不小心，导致其他地方出现问题，倒是有点像城门失火殃及池鱼的味道；因此我们也会发现，在程序最开始处出现错误通常就是最好的结果，否则运行轨迹根本就无法追寻了。

当然避免这些问题的方法就是写代码的时候细致一点，多测试一点，如果上述问题真是最后猜测的原因，其实是很容易测试发现的。