IRQL_NOT_LESS_OR_EQUAL (a)蓝屏事件分析

蓝屏显示为下图：

编辑切换为居中

IRQL_NOT_LESS_OR_EQUAL (a)

通常这个蓝屏会涉及到很大的范围，不排除硬件，按照我的经验（超过十万份的DUMP分析）来看的话，硬件方面是居多的，或许是因为，很多蓝屏都直接会选择重装系统的套路，所以问题被遗弃了。我已经用WINDBG分析出数据来了，下面是代码分析数据：

************* Path validation summary **************

Response Time (ms) Location

Deferred srv*

Symbol search path is: srv*

Executable search path is:

Windows 10 Kernel Version 19041 MP (8 procs) Free x64（这里一行说明是4核8线程处理器，系统是WIN10 ）

System Uptime: 0 days 0:00:04.073（距离上一次蓝屏时间，从这个时间看到基本上就是进系统就蓝屏了）

2: kd> !analyze -v

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: ffff9d086f702022, 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: fffff80709612d8a, address which referenced memory

READ_ADDRESS: fffff8070a0fb390: Unable to get MiVisibleState （出现大量的数据获取异常）

Unable to get NonPagedPoolStart

Unable to get NonPagedPoolEnd

Unable to get PagedPoolStart

Unable to get PagedPoolEnd

unable to get nt!MmSpecialPagesInUse

ffff9d086f702022

Resetting default scope （重置）

STACK_TEXT:

fffffa89`2f03e098 fffff807`09810129 : 00000000`0000000a ffff9d08`6f702022 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx

fffffa89`2f03e0a0 fffff807`0980bce3 : 00000001`fb8f9000 ffff9d88`6f262a20 fffffa89`2f03e499 fffff807`0b431f20 : nt!KiBugCheckDispatch+0x69

fffffa89`2f03e1e0 fffff807`09612d8a : fffffa89`2f03e38c fffff807`0c1980dd 00000017`00100000 fffff807`00000002 : nt!KiPageFault+0x463

fffffa89`2f03e370 fffff807`09612351 : ffff9d88`6a202340 ffff9d88`6a2064c0 ffff9d88`6a206680 00000000`00000040 : nt!RtlpHpLfhSlotAllocate+0xba

fffffa89`2f03e4c0 fffff807`09db7074 : 00000000`00000000 fffffa89`2f03e7c8 ffff8f0d`69576d73 00000000`00000000 : nt!ExAllocateHeapPool+0x2b1

fffffa89`2f03e600 fffff807`0c194d14 : 00000000`00000060 00000000`00000000 fffff807`0c1c26d0 fffffa89`00000000 : nt!ExAllocatePoolWithTag+0x64

fffffa89`2f03e650 fffff807`0c194aea : fffff807`0c1c26d0 00000000`00000000 00000000`00000000 ffff9d88`6f8f1d40 : rdyboost!SMKM_STORE_MGR<SMD_TRAITS>::SmPageWrite+0xe4

fffffa89`2f03e6d0 fffff807`0c196125 : 00000000`00535242 fffffa89`2f03e880 00000000`00000000 00000000`00000060 : rdyboost!SmdStoreWrite+0x66

fffffa89`2f03e750 fffff807`0c191fa4 : ffff9d88`6f38b950 00000000`001fb8de 00000000`0000000a fffff807`0c1c26d0 : rdyboost!SmdAddIoToStores+0x175

fffffa89`2f03e7c0 fffff807`0c199106 : ffff9d88`6f38b950 fffff807`00000000 00000000`001fb8de ffff9d88`00000004 : rdyboost!SmdProcessReadWriteCompletion+0x234

fffffa89`2f03e870 fffff807`0c191e77 : fffffa89`2f03e9f0 fffffa89`2f03e9f8 fffffa89`2f03ea99 ffff9d88`6f233a00 : rdyboost!SmdRBReadWriteCompletion+0x1d6

fffffa89`2f03e930 fffff807`0c191d2e : ffff9d88`6f38b950 fffff807`00000000 fffffa89`2f040000 fffffa89`00000000 : rdyboost!SmdProcessReadWriteCompletion+0x107

fffffa89`2f03e9e0 fffff807`09692735 : ffff9d88`6f233b6b ffff9d88`6f233bb3 ffff9d88`6f233b23 ffff9d88`6b9c47d0 : rdyboost!SmdReadWriteCompletion+0x4e

fffffa89`2f03ea20 fffff807`09692577 : ffff9d88`6f2338a0 ffff9d88`6f233a01 ffff9d88`6f2338a0 ffff9d88`6f37e080 : nt!IopfCompleteRequest+0x1a5

fffffa89`2f03eb00 fffff807`0c2966e3 : 00000000`00000000 fffffa89`2f03ec19 ffff9d88`6f3ecbb0 ffff9d88`6f3ecbb0 : nt!IofCompleteRequest+0x17

fffffa89`2f03eb30 fffff807`09692735 : 00000000`00000000 00000000`00000000 00000000`00000002 00000000`00000000 : CLASSPNP!TransferPktComplete+0x5e3

fffffa89`2f03ed40 fffff807`09692577 : ffff9d88`6f6c4ab0 ffff9d88`6b997101 ffff9d88`6f118000 fffff807`0967f681 : nt!IopfCompleteRequest+0x1a5

fffffa89`2f03ee20 fffff807`0b609091 : ffff9d88`6f37db90 ffff9d88`6f117340 00000000`00000000 ffff9d88`6b9c84a0 : nt!IofCompleteRequest+0x17

fffffa89`2f03ee50 fffff807`0b6089f5 : ffff9d88`6f117020 ffff9d88`6b9ca1a0 fffffa89`2f03f020 ffff9d88`6f37dc00 : storport!RaidCompleteRequestEx+0x91

fffffa89`2f03ef20 fffff807`0b61c4dc : fffffa89`2f03f120 00000000`00000000 fffff780`00000320 ffff9d88`6f117020 : storport!RaidUnitCompleteRequest+0x1005 （关键点，发生存储I/O处重置，问题已经很明显了，硬盘接口反复发生重置，直接强制蓝屏）

fffffa89`2f03f0c0 fffff807`0968b57e : fffffa89`2f03f430 ffff9d88`6ac60000 fffffa89`2f030400 ffff8080`00000002 : storport!RaidpAdapterRedirectDpcRoutine+0x8c

fffffa89`2f03f160 fffff807`0968a864 : 00000000`00000000 00000000`00000000 00000000`00140001 00000000`00000000 : nt!KiExecuteAllDpcs+0x30e

fffffa89`2f03f2d0 fffff807`098009be : ffffffff`00000000 ffff8080`04c92180 ffff8080`04c9d240 ffff9d88`6f412600 : nt!KiRetireDpcList+0x1f4

fffffa89`2f03f560 00000000`00000000 : fffffa89`2f040000 fffffa89`2f039000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x9e

SYMBOL_NAME: rdyboost!SMKM_STORE_MGR<SMD_TRAITS>::SmPageWrite+e4（定位提示存储管理出现异常）

FAILURE_BUCKET_ID: AV_rdyboost!SMKM_STORE_MGR_SMD_TRAITS_::SmPageWrite

FAILURE_ID_HASH: {bf0e310e-4d6d-76db-d0d5-3ab110b3b5a1}

Followup: MachineOwner

---------

2: kd> lmvm rdyboost

Browse full module list

start end module name

fffff807`0c190000 fffff807`0c1e0000 rdyboost # (pdb symbols) C:\ProgramData\Dbg\sym\rdyboost.pdb\445F3F578F4899E72BEF9BC3E13EB2C01\rdyboost.pdb

Loaded symbol image file: rdyboost.sys

Mapped memory image file: C:\ProgramData\Dbg\sym\rdyboost.sys\76CA327050000\rdyboost.sys

Image path: \SystemRoot\System32\drivers\rdyboost.sys（定位最后发生崩溃的驱动）

Image name: rdyboost.sys

Browse all global symbols functions data

Image was built with /Brepro flag.

整个过程就已经分析完成，看完整片分析，主要看我的注释，有经验的DUMP分析师立马就能发现问题所在了，原因就是因为硬盘处反复接口性崩溃，导致最后驱动崩溃蓝屏，出现因为硬件故障导致的经典蓝屏代码IRQL_NOT_LESS_OR_EQUAL (a)的浮现，解决起来也不难，直接更换主硬盘即可。

申明，这只是针对这份蓝屏代码的分析，并不是所有的通用，没有分析数据的时候，不要胡乱操作。