作者：huity
出处：https://www.cnblogs.com/huity35/p/11232751.html
版权：本文版权归作者所有。文章在博客园、看雪、个人博客同时发布。
转载：欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任。
Part1 Buffer Overflows
池是内核模式内存，用作驱动程序的存储空间。
池的组织方式与在从演讲或书中记笔记时使用记事本的方式类似。 有些笔记可能是1行，其他笔记可能是多行。 许多不同的注释都在同一页面上。内存也被组织成页，通常一页内存为4KB。 Windows内存管理器将这个4KB的页面分成更小的块。 一个块可能小到8个字节或可能更大。 这些块中的每一个与其他块并排存在。
！pool命令可用于查看存储在页面中的池块。
kd> !pool fffffa8003f42000 Pool page fffffa8003f42000 region is Nonpaged pool *fffffa8003f42000 size: 410 previous size: 0 (Free) *Irp Pooltag Irp : Io, IRP packets fffffa8003f42410 size: 40 previous size: 410 (Allocated) MmSe fffffa8003f42450 size: 150 previous size: 40 (Allocated) File fffffa8003f425a0 size: 80 previous size: 150 (Allocated) Even fffffa8003f42620 size: c0 previous size: 80 (Allocated) EtwR fffffa8003f426e0 size: d0 previous size: c0 (Allocated) CcBc fffffa8003f427b0 size: d0 previous size: d0 (Allocated) CcBc fffffa8003f42880 size: 20 previous size: d0 (Free) Free fffffa8003f428a0 size: d0 previous size: 20 (Allocated) Wait fffffa8003f42970 size: 80 previous size: d0 (Allocated) CM44 fffffa8003f429f0 size: 80 previous size: 80 (Allocated) Even fffffa8003f42a70 size: 80 previous size: 80 (Allocated) Even fffffa8003f42af0 size: d0 previous size: 80 (Allocated) Wait fffffa8003f42bc0 size: 80 previous size: d0 (Allocated) CM44 fffffa8003f42c40 size: d0 previous size: 80 (Allocated) Wait fffffa8003f42d10 size: 230 previous size: d0 (Allocated) ALPC fffffa8003f42f40 size: c0 previous size: 230 (Allocated) EtwR
由于许多池分配存储在同一页面中，因此每个驱动程序仅使用已分配的空间至关重要。如果DriverA使用的空间比分配的空间多，则会写入下一个驱动程序的空间（DriverB）并损坏DriverB的数据。将这种覆盖到下一个驱动程序的空间的情况称为缓冲区溢出。接着，内存管理器或DriverB将尝试使用此损坏的内存，并将遇到意外的信息。这种意外信息通常会导致蓝屏（BSOD）。
通常，池损坏显示为终止码 0x19 BAD_POOL_HEADER或终止码 0xC2 BAD_POOL_CALLER。 这些终止码可以轻松确定崩溃中涉及池损坏。 但是，访问意外内存的结果可能会有很大差异，因此池损坏会导致许多不同类型的错误检查。
与任何蓝屏转储分析一样，最好的起点是！analyze -v。 此命令将显示终止码和参数，并对崩溃进行一些基本解释。
kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* SYSTEM_SERVICE_EXCEPTION (3b) An exception happened while executing a system service routine. Arguments: Arg1: 00000000c0000005, Exception code that caused the bugcheck Arg2: fffff8009267244a, Address of the instruction which caused the bugcheck Arg3: fffff88004763560, Address of the context record for the exception that caused the bugcheck Arg4: 0000000000000000, zero.
在上述例子中，错误检查是一个终止码 0x3B SYSTEM_SERVICE_EXCEPTION。 此终止码的第一个参数是c0000005，它是访问冲突的状态代码。 访问冲突是尝试访问无效内存（此错误与权限无关）。 可以在WDK头ntstatus.h中查找状态代码。
！analyze -v命令还提供了一个有用的捷径来进入失败的上下文。
CONTEXT: fffff88004763560 -- (.cxr 0xfffff88004763560;r)
运行此命令会向我们显示崩溃时的寄存器值。
kd> .cxr 0xfffff88004763560 rax=4f4f4f4f4f4f4f4f rbx=fffff80092690460 rcx=fffff800926fbc60 rdx=0000000000000000 rsi=0000000000001000 rdi=0000000000000000 rip=fffff8009267244a rsp=fffff88004763f60 rbp=fffff8009268fb40 r8=fffffa8001a1b820 r9=0000000000000001 r10=fffff800926fbc60 r11=0000000000000011 r12=0000000000000000 r13=fffff8009268fb48 r14=0000000000000012 r15=000000006374504d iopl=0 nv up ei pl nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206 nt!ExAllocatePoolWithTag+0x442: fffff800`9267244a 4c8b4808 mov r9,qword ptr [rax+8] ds:002b:4f4f4f4f`4f4f4f57=????????????????
从上面的输出我们可以看到崩溃发生在ExAllocatePoolWithTag中，这很好地表明崩溃是由于池损坏造成的。 通常情况下，看着dump的工程师会在此时停止并得出结论认为崩溃是由池损坏引起的，但我们可以更进一步。
执行失败的指令是解引用rax + 8。 rax寄存器包含4f4f4f4f4f4f4f4f，它不具有x64系统上指针所需的规范形式。 这说明因为rax中的数据应该是一个指针，但很明显他不是，导致系统崩溃了。
要确定rax不包含预期数据的原因，我们必须在失败之前检查指令。
kd> ub . nt!KzAcquireQueuedSpinLock [inlined in nt!ExAllocatePoolWithTag+0x421]: fffff800`92672429 488d542440 lea rdx,[rsp+40h] fffff800`9267242e 49875500 xchg rdx,qword ptr [r13] fffff800`92672432 4885d2 test rdx,rdx fffff800`92672435 0f85c3030000 jne nt!ExAllocatePoolWithTag+0x7ec (fffff800`926727fe) fffff800`9267243b 48391b cmp qword ptr [rbx],rbx fffff800`9267243e 0f8464060000 je nt!ExAllocatePoolWithTag+0xa94 (fffff800`92672aa8) fffff800`92672444 4c8b03 mov r8,qword ptr [rbx] fffff800`92672447 498b00 mov rax,qword ptr [r8]
汇编代码中显示rax来自r8所指向数据。查找前面寄存器的值，看到r8值为fffffa8001a1b820，查看内存，可以看到与rax中数据一致，由此可以断定，是此处内存出现问题。
kd> dq fffffa8001a1b820 l1
fffffa80`01a1b820 4f4f4f4f`4f4f4f4f
要确定此意外数据是否是由池损坏引起的，我们可以使用！pool命令。
kd> !pool fffffa8001a1b820 Pool page fffffa8001a1b820 region is Nonpaged pool fffffa8001a1b000 size: 810 previous size: 0 (Allocated) None
fffffa8001a1b810看起来不像是一个有效的小池分配，检查整个页面是否实际上是大页面分配的一部分......
kd> !pool fffffa8001a1b820 Pool page fffffa8001a1b820 region is Nonpaged pool fffffa8001a1b000 size: 810 previous size: 0 (Allocated) None fffffa8001a1b810 doesn't look like a valid small pool allocation, checking to see if the entire page is actually part of a large page allocation... fffffa8001a1b810 is not a valid large pool allocation, checking large session pool... fffffa8001a1b810 is freed (or corrupt) pool Bad previous allocation size @fffffa8001a1b810, last size was 81 *** *** An error (or corruption) in the pool was detected; *** Attempting to diagnose the problem. *** *** Use !poolval fffffa8001a1b000 for more details. Pool page [ fffffa8001a1b000 ] is __inVALID. Analyzing linked list... [ fffffa8001a1b000 --> fffffa8001a1b010 (size = 0x10 bytes)]: Corrupt region Scanning for single bit errors... None found
上面的输出看起来不像我们之前使用的！pool命令。 此输出显示池标头的损坏，这会阻止命令走分配链。
上面的输出显示在大小为810的fffffa8001a1b000上有一处分配。如果我们查看这个内存，我们应该看到一个池头。 但是，我们看到的是4f4f4f4f`4f4f4f4f的样子。
kd> dq fffffa8001a1b000 + 810 fffffa80`01a1b810 4f4f4f4f`4f4f4f4f 4f4f4f4f`4f4f4f4f fffffa80`01a1b820 4f4f4f4f`4f4f4f4f 4f4f4f4f`4f4f4f4f fffffa80`01a1b830 4f4f4f4f`4f4f4f4f 00574f4c`46524556 fffffa80`01a1b840 00000000`00000000 00000000`00000000 fffffa80`01a1b850 00000000`00000000 00000000`00000000 fffffa80`01a1b860 00000000`00000000 00000000`00000000 fffffa80`01a1b870 00000000`00000000 00000000`00000000 fffffa80`01a1b880 00000000`00000000 00000000`00000000
此时，我们可以确定系统因池损坏而崩溃。
因为损坏发生在之前，并且转储是系统当前状态的快照，所以没有具体证据表明内存是如何被破坏的。 在损坏之前立即分配池块的驱动程序可能是写入错误位置并导致此损坏的驱动程序。 此池块标有“None”标记，我们可以在内存中搜索此标记以确定哪些驱动程序使用它。
kd> !for_each_module s -a @#Base @#End "None" fffff800`92411bc2 4e 6f 6e 65 e9 45 04 26-00 90 90 90 90 90 90 90 None.E.&........ kd> u fffff800`92411bc2-1 nt!ExAllocatePool+0x1: fffff800`92411bc1 b84e6f6e65 mov eax,656E6F4Eh fffff800`92411bc6 e945042600 jmp nt!ExAllocatePoolWithTag (fffff800`92672010) fffff800`92411bcb 90 nop
文件Pooltag.txt列出了由Windows提供的内核模式组件和驱动程序，相关文件或组件（如果已知）以及组件名称用于池分配的池标记。 Pooltag.txt随Windows调试工具（在triage文件夹中）和Windows WDK（在\ tools \ other \ platform \ poolmon中）一起安装。 Pooltag.txt显示以下标记：
None - <unknown> - call to ExAllocatePool
不幸的是，我们发现当驱动程序调用ExAllocatePool（未指定标记）时会使用此标记。 这不允许我们确定在损坏之前分配块的驱动程序。 即使我们可以将标记绑定回驱动程序，也可能不足以断定使用此标记的驱动程序是破坏内存的驱动程序。
下一步应该是启用特殊池并希望在行为中捕获损坏者。
Part2 Special Pool for Buffer Overruns
在本节中，我们将讨论特殊池如何帮助识别向缓冲区写入太多数据的驱动程序。
池通常被组织为允许多个驱动程序将数据存储在同一内存页中，如图1所示。
图1 未损坏池
通过允许多个驱动程序共享同一页面，池可以有效地使用可用的内核内存空间。 但是，这种共享要求每个驱动程序都要小心使用池，使用池的任何错误都可能破坏其他驱动程序池并导致崩溃。
图二 损坏池
如图2所示池，如果DriverA分配100个字节但写入120个字节，它将覆盖由DriverB存储的池头和数据。 在第1部分中，我们演示了这种类型的缓冲区溢出，但我们无法识别哪些代码导致损坏池。
为了捕获损坏池的驱动程序，我们可以使用特殊池。 特殊池更改池的组织方式，使得每个驱动程序的分配位于单独的内存页中。 这有助于防止驱动程序意外写入另一个驱动程序的内存。 特殊池也在页末尾进行驱动程序的分配，通过将下一个虚拟页面标记为无效将其设置为保护页面。写入超过分配的结尾，会导致保护页面进行立即错误检查。
特殊池还用重复模式填充页面的未使用部分，称为“slop bytes”。 如果在模式中发现任何错误，在释放页面时将检查这些slop字节，生成错误检查以指示内存已损坏。 这种类型的损坏不是缓冲区溢出，它可能是下溢或其他形式的损坏。
图3 特殊池
由于特殊池将每个池分配存储在其自己的4KB页面中，因此会导致内存使用量增加。启用特殊池时，内存管理器将配置可在系统上分配特殊池的限制，当达到此限制时，将使用常规池。对于比64位系统具有更少内核空间的32位系统，这种限制尤其明显。
解释了特殊池的工作原理，现在来用它。
有两种方法可以启用特殊池。驱动验证程序允许在特定驱动程序上启用特殊池。 KB188831中描述的PoolTag注册表值允许为特定池标记启用特殊池。从Windows Vista和Windows Server 2008开始，驱动验证程序捕获特殊池分配的其他信息，因此这通常是推荐的方法。
要使用驱动程序验证程序启用特殊池，请使用以下命令行，或从验证程序GUI中选择该选项。使用/ driver标志指定要验证的驱动程序，这是列出您怀疑是问题原因的驱动程序的位置。您可能需要验证已编写并希望测试的驱动程序或最近在系统上更新的驱动程序。在下面的命令行中，我只验证myfault.sys。需要重新启动才能启用特殊池。
verifier /flags 1 /driver myfault.sys
启用验证程序并重新启动系统后，重复导致崩溃的活动。 对于某些问题，活动可能只是等待一段时间。 对于我们的演示，我们运行NotMyFault（有关详细信息，请参阅第1部分）。
特殊池中缓冲区溢出导致的崩溃将是一个终止码0xD6，DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION。
kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) N bytes of memory was allocated and more than N bytes are being referenced. This cannot be protected by try-except. When possible, the guilty driver's name (Unicode string) is printed on the bugcheck screen and saved in KiBugCheckDriver. Arguments: Arg1: fffff9800b5ff000, memory referenced Arg2: 0000000000000001, value 0 = read operation, 1 = write operation Arg3: fffff88004f834eb, if non-zero, the address which referenced memory. Arg4: 0000000000000000, (reserved)
我们可以调试此崩溃并确定notmyfault.sys写入池缓冲区之外。
调用堆栈显示myfault.sys访问了无效内存，这会生成页面错误。
kd> k Child-SP RetAddr Call Site fffff880`04822658 fffff803`721333f1 nt!KeBugCheckEx fffff880`04822660 fffff803`720acacb nt! ?? ::FNODOBFM::`string'+0x33c2b fffff880`04822700 fffff803`7206feee nt!MmAccessFault+0x55b fffff880`04822840 fffff880`04f834eb nt!KiPageFault+0x16e fffff880`048229d0 fffff880`04f83727 myfault+0x14eb fffff880`04822b20 fffff803`72658a4a myfault+0x1727 fffff880`04822b80 fffff803`724476c7 nt!IovCallDriver+0xba fffff880`04822bd0 fffff803`7245c8a6 nt!IopXxxControlFile+0x7e5 fffff880`04822d60 fffff803`72071453 nt!NtDeviceIoControlFile+0x56 fffff880`04822dd0 000007fc`4fe22c5a nt!KiSystemServiceCopyEnd+0x13 00000000`004debb8 00000000`00000000 0x000007fc`4fe22c5a
！pool命令显示myfault.sys引用的地址是特殊池。
kd> !pool fffff9800b5ff000 Pool page fffff9800b5ff000 region is Special pool fffff9800b5ff000: Unable to get contents of special pool block
页表条目显示该地址无效。 这是特殊池用于捕获溢出的防护页面。
kd> !pte fffff9800b5ff000 VA fffff9800b5ff000 PXE at FFFFF6FB7DBEDF98 PPE at FFFFF6FB7DBF3000 PDE at FFFFF6FB7E6002D0 PTE at FFFFF6FCC005AFF8 contains 0000000001B8F863 contains 000000000138E863 contains 000000001A6A1863 contains 0000000000000000 pfn 1b8f ---DA--KWEV pfn 138e ---DA--KWEV pfn 1a6a1 ---DA--KWEV not valid
此内存之前的分配是一个800字节的非分页池标记为“Wrap”。 “Wrap”是验证程序在没有标记的情况下分配池时使用的标记，它相当于我们在第1部分中看到的“None”标记。
kd> !pool fffff9800b5ff000-1000 Pool page fffff9800b5fe000 region is Special pool *fffff9800b5fe000 size: 800 data: fffff9800b5fe800 (NonPaged) *Wrap Owning component : Unknown (update pooltag.txt)
特殊池是跟踪缓冲区溢出池损坏的有效机制。 它还可以用于捕获其他类型的池损坏，我们将在以后的文章中讨论。
Part3 Special Pool for Double Frees
在本系列的第1部分和第2部分中，我们讨论了池损坏以及如何使用特殊池来确定此类损坏的原因。 在这一部分中，我们将使用特殊池来捕获一个双重释放池内存。
双重释放池将导致系统显示蓝屏，但是由此导致的崩溃可能会有所不同。 在最明显的情况下，两次释放池分配的驱动程序将导致系统立即崩溃，终止码为C2 BAD_POOL_CALLER，第一个参数将为7，表示“尝试释放已释放的池”。 如果您遇到此类崩溃，则应在故障排除步骤列表中启用特殊池。
BAD_POOL_CALLER (c2) The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc. Arguments: Arg1: 0000000000000007, Attempt to free pool which was already freed Arg2: 00000000000011c1, (reserved) Arg3: 0000000004810007, Memory contents of the pool block Arg4: fffffa8001b10800, Address of the block of pool being deallocated
一个不太明显的崩溃是池已被重新申请。正如第二部分所示，池的结构使得多个驱动程序共享一个页面。当DriverA调用ExFreePool释放其池块时，该块可供其他驱动程序使用。 如果内存管理器将此内存提供给DriverF，然后DriverA再次释放它，则当池分配不再包含预期数据时，DriverF中可能会发生崩溃。 对于没有特殊池的DriverF的开发者来说，这样的问题可能是困难的。
特殊池将每个驱动程序的分配放在一个单独的内存页中（如第2部分所述）。 当驱动程序释放特殊池中的池块时，将释放整个页面，并且对任意页面的任何访问都将导致立即错误检查。 此外，特殊池将此页面放在要再次使用的页面列表的尾部。 这增加了页面在第二次释放时仍然可用的可能性，降低了上面显示的DriverA / DriverF场景的可能性。
为了验证这种失败，我们将再次使用Sysinternals工具NotMyFault。 选择“Double free”选项，然后单击“Crash”。 很可能你会得到上面提到的停止C2错误检查。 启用特殊池并重新启动以获得更多信息错误。
verifier /flags 1 /driver myfault.sys
选择启用特殊池的“双重免费”选项会导致以下崩溃。 错误检查代码PAGE_FAULT_IN_NONPAGED_AREA表示某些驱动程序试图访问无效的内存。 此无效内存是已释放的特殊池页面。
PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: fffff9800a7fe7f0, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff80060263888, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000002, (reserved)
查看调用堆栈，我们可以看到myfault.sys正在释放池，ExFreePoolSanityChecks发生了导致崩溃的页面错误。
kd> kn # Child-SP RetAddr Call Site 00 fffff880`0419fe28 fffff800`5fd7e28a nt!DbgBreakPointWithStatus 01 fffff880`0419fe30 fffff800`5fd7d8de nt!KiBugCheckDebugBreak+0x12 02 fffff880`0419fe90 fffff800`5fc5b544 nt!KeBugCheck2+0x79f 03 fffff880`041a05b0 fffff800`5fd1c5bc nt!KeBugCheckEx+0x104 04 fffff880`041a05f0 fffff800`5fc95acb nt! ?? ::FNODOBFM::`string'+0x33e2a 05 fffff880`041a0690 fffff800`5fc58eee nt!MmAccessFault+0x55b 06 fffff880`041a07d0 fffff800`60263888 nt!KiPageFault+0x16e 07 fffff880`041a0960 fffff800`6024258c nt!ExFreePoolSanityChecks+0xe8 08 fffff880`041a09a0 fffff880`04c9b5d9 nt!VerifierExFreePoolWithTag+0x3c 09 fffff880`041a09d0 fffff880`04c9b727 myfault!MyfaultDeviceControl+0x2fd 0a fffff880`041a0b20 fffff800`60241a4a myfault!MyfaultDispatch+0xb7 0b fffff880`041a0b80 fffff800`600306c7 nt!IovCallDriver+0xba 0c fffff880`041a0bd0 fffff800`600458a6 nt!IopXxxControlFile+0x7e5 0d fffff880`041a0d60 fffff800`5fc5a453 nt!NtDeviceIoControlFile+0x56 0e fffff880`041a0dd0 000007fd`ea212c5a nt!KiSystemServiceCopyEnd+0x13
使用错误检查代码中的地址，我们可以看到内存实际上是无效的：
kd> dd fffff9800a7fe7f0 fffff980`0a7fe7f0 ???????? ???????? ???????? ???????? fffff980`0a7fe800 ???????? ???????? ???????? ???????? fffff980`0a7fe810 ???????? ???????? ???????? ???????? fffff980`0a7fe820 ???????? ???????? ???????? ???????? fffff980`0a7fe830 ???????? ???????? ???????? ???????? fffff980`0a7fe840 ???????? ???????? ???????? ???????? fffff980`0a7fe850 ???????? ???????? ???????? ???????? fffff980`0a7fe860 ???????? ???????? ???????? ???????? kd> !pte fffff9800a7fe7f0 VA fffff9800a7fe7f0 PXE at FFFFF6FB7DBEDF98 PPE at FFFFF6FB7DBF3000 PDE at FFFFF6FB7E600298 PTE at FFFFF6FCC0053FF0 contains 0000000002A91863 contains 0000000002A10863 contains 0000000000000000 pfn 2a91 ---DA--KWEV pfn 2a10 ---DA--KWEV not valid
到目前为止，我们有足够的证据证明myfault.sys释放了无效的内存，但是我们怎么知道这个内存被释放了两次呢？ 如果有双重释放，我们需要确定对ExFreePool的第一次或第二次调用是否不正确。 为此我们需要确定哪些代码首先释放了内存。
Driver Verifier特殊池跟踪最后的0x10000调用以分配和释放池。 您可以使用！verifier 80命令转储此数据库。 要限制数据输出，您还可以将此命令传递给您怀疑被双重释放的内存地址。
不要假设错误检查代码中的地址是被释放的地址，请从调用VerifierExFreePoolWithTag的函数中获取地址。
在上面的调用堆栈中，VerifierExFreePoolWithTag下面的调用是第9帧（从0开始计数，或者使用kn）。
kd> .frame /r 9 09 fffff880`041a09d0 fffff880`04c9b727 myfault+0x15d9 rax=0000000000000000 rbx=fffff9800a7fe800 rcx=fffff9800a7fe800 rdx=fffffa8001a37fa0 rsi=fffffa80035975e0 rdi=fffffa8003597610 rip=fffff88004c9b5d9 rsp=fffff880041a09d0 rbp=fffffa80034568d0 r8=fffff9800a7fe801 r9=fffff9800a7fe7f0 r10=fffff9800a7fe800 r11=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=fffff800600306c7 r15=fffffa8004381b80 iopl=0 nv up ei ng nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000286 myfault+0x15d9: fffff880`04c9b5d9 eb7a jmp myfault+0x1655 (fffff880`04c9b655)
在x64系统上，第一个参数在rcx中传递。 下面的程序集显示rcx源自rbx。
kd> ub fffff880`04c9b5d9 myfault+0x15ba: fffff880`04c9b5ba ff15a80a0000 call qword ptr [myfault+0x2068 (fffff880`04c9c068)] fffff880`04c9b5c0 33d2 xor edx,edx fffff880`04c9b5c2 488bc8 mov rcx,rax fffff880`04c9b5c5 488bd8 mov rbx,rax fffff880`04c9b5c8 ff154a0a0000 call qword ptr [myfault+0x2018 (fffff880`04c9c018)] fffff880`04c9b5ce 33d2 xor edx,edx fffff880`04c9b5d0 488bcb mov rcx,rbx fffff880`04c9b5d3 ff153f0a0000 call qword ptr [myfault+0x2018 (fffff880`04c9c018)]
运行！verifier 80：rbx中的地址
kd> !verifier 80 fffff9800a7fe800
最近内核池分配和自由操作的日志：
日志中最多有0x10000个条目。
解析0x0000000000010000个日志条目，搜索地址0xfffff9800a7fe800。
====================================================================== Pool block fffff9800a7fe800, Size 0000000000000800, Thread fffffa80046ce4c0 fffff80060251a32 nt!VfFreePoolNotification+0x4a fffff8005fe736c9 nt!ExFreePool+0x595 fffff80060242597 nt!VerifierExFreePoolWithTag+0x47 fffff88004c9b5ce myfault!MyfaultDeviceControl+0x2f2 fffff88004c9b727 myfault!MyfaultDispatch+0xb7 fffff80060241a4a nt!IovCallDriver+0xba fffff800600306c7 nt!IopXxxControlFile+0x7e5 fffff800600458a6 nt!NtDeviceIoControlFile+0x56 fffff8005fc5a453 nt!KiSystemServiceCopyEnd+0x13 ====================================================================== Pool block fffff9800a7fe800, Size 0000000000000800, Thread fffffa80046ce4c0 fffff80060242a5d nt!VeAllocatePoolWithTagPriority+0x2d1 fffff8006024b20e nt!XdvExAllocatePoolInternal+0x12 fffff80060242f69 nt!VerifierExAllocatePool+0x61 fffff88004c9b5c0 myfault!MyfaultDeviceControl+0x2e4 fffff88004c9b727 myfault!MyfaultDispatch+0xb7 fffff80060241a4a nt!IovCallDriver+0xba fffff800600306c7 nt!IopXxxControlFile+0x7e5 fffff800600458a6 nt!NtDeviceIoControlFile+0x56 fffff8005fc5a453 nt!KiSystemServiceCopyEnd+0x13
上面的输出显示由myfault.sys分配的池块，然后由myfault.sys释放。 如果我们将这些信息与调用堆栈结合起来导致我们的错误检查，我们可以得出结论，池在MyfaultDeviceControl中在偏移量0x2f2处被释放一次，然后在偏移量为0x2fd的MyfaultDeviceControl中再次释放。
现在我们知道哪个驱动程序导致了问题，如果这是我们的驱动程序，我们就知道要调查的代码区域。
原文链接：