您的位置：首页 > 其它

[翻译]内核池基础知识（池损坏）

2019-07-23 16:45 127 查看

作者：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中再次释放。现在我们知道哪个驱动程序导致了问题，如果这是我们的驱动程序，我们就知道要调查的代码区域。 原文链接：

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航