[翻译]内核池基础知识（池损坏）
说明函模板
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 rvice routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caud the bugcheck
Arg2: fffff8009267244a, Address of the instruction which caud the bugcheck
限制英语
Arg3: fffff88004763560, Address of the context record for the exception that caud 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 e
if the entire page is actually part of a large
fffffa8001a1b810 is not a valid large pool allocation, checking large
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 diagno the problem.
***
*** U !poolval fffffa8001a1b000 for more details.
Pool page [ fffffa8001a1b000 ] is __inVALID.
Analyzing
[ fffffa8001a1b000 --> fffffa8001a1b010 (size = 0x10 bytes)]: Corrupt region
Scanning for single
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`0000000000000000`00000000
fffffa80`01a1b850 00000000`0000000000000000`00000000
fffffa80`01a1b860 00000000`0000000000000000`00000000
fffffa80`01a1b870 00000000`0000000000000000`00000000
fffffa80`01a1b880 00000000`0000000000000000`00000000
此时，我们可以确定系统因池损坏⽽崩溃。
因为损坏发⽣在之前，并且转储是系统当前状态的快照，所以没有具体证据表明内存是如何被破坏的。在损坏之前⽴即分配池块的驱动程序可能是写⼊错误位置并导致此损坏的驱动程序。此池块标有“None”标记，我们可以在内存中搜索此标记以确定哪些驱动程序使⽤它。
kd> !for_each_module s -a @#Ba @#End "None"
fffff800`92411bc2 4e 6f 6e 65 e9 450426-0090909090909090 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
⽂件列出了由Windows提供的内核模式组件和驱动程序，相关⽂件或组件（如果已知）以及组件名称⽤于池分配的池标记。随Windows调试⼯具（在triage⽂件夹中）和Windows WDK（在\ tools \ other \ platform \ poolmon中）⼀起安装。 显⽰以下标记：
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, (rerved)
我们可以调试此崩溃并确定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`000000000x000007fc`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 ()
特殊池是跟踪缓冲区溢出池损坏的有效机制。它还可以⽤于捕获其他类型的池损坏，我们将在以后的⽂章中讨论。
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, (rerved)
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 addre
ss.
Arg4: 0000000000000002, (rerved)
查看调⽤堆栈，我们可以看到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)
