## 一：背景 ### 1. 講故事 在這麼多的案例分析中，往往會發現一些案例是卡死線上程的內核態棧上，但拿過來的dump都是用戶態模式下，所以無法看到內核態棧，這就比較麻煩，需要讓朋友通過其他方式生成一個藍屏的dump，這裡我們簡單彙總下。 ## 二：如何生成內核態dump ### 1. 案例代碼 ...
一：背景
1. 講故事
在這麼多的案例分析中，往往會發現一些案例是卡死線上程的內核態棧上，但拿過來的dump都是用戶態模式下，所以無法看到內核態棧，這就比較麻煩，需要讓朋友通過其他方式生成一個藍屏的dump，這裡我們簡單彙總下。
二：如何生成內核態dump
1. 案例代碼
為了方便演示，來一段簡單的測試代碼，目的就是觀察 Console.ReadLine 方法的內核態棧。
internal class Program
{
static void Main(string[] args)
{
Console.WriteLine("hello world!");
Console.ReadLine();
}
}
通過 任務管理器 或者 Process Explorer 預設抓取的dump都是 ntdll 之上的空間，可以用 k 來看一下。
0:000> k 3
# Child-SP RetAddr Call Site
00 000000d6`7c9fe328 00007ffe`61405593 ntdll!NtReadFile+0x14
01 000000d6`7c9fe330 00007ffd`50724782 KERNELBASE!ReadFile+0x73
02 000000d6`7c9fe3b0 00007ffe`215bc742 0x00007ffd`50724782
問題來了，如果我要看下 ntdll!NtReadFile 函數對應在內核態中的 nt!NtReadFile 方法怎麼辦呢？只能抓內核態dump，抓內核態dump的方式有很多，這裡聊一下其中的兩種方式。
2. 使用 notmyfault 抓取
說到 藍屏 我相信有很多朋友都知道，簡而言之就是內核態代碼出bug導致系統崩潰，也有朋友知道通過增加一些配置可以在藍屏的時候自動生成 dump 文件，這種 dump 文件就屬於內核態，配置如下：
但這裡有一個問題，操作系統不可能無緣無故的藍屏，那怎麼辦呢？微軟想了一個辦法，人為的造藍屏，所以提供了一個叫 notmyfault.exe 的工具， MSDN網址：https://learn.microsoft.com/en-us/sysinternals/downloads/notmyfault
有了這些前置基礎，接下來就可以操練一下，雙擊 notmyfault.exe 工具，崩潰原因選擇預設的 High IRQL fault，最後點擊 Crash 按鈕，稍等片刻電腦就會藍屏。截圖如下：
我這裡用的是一臺物理的 迷你主機 測試，再次遠程連接後，在 C:\Windows 下會生成一個 MEMORY.dmp 文件，截圖如下：
拿到 dump 之後就可以用 windbg 中的 !process 之類的命令分析了，非常爽。
1: kd> !process 0 2 ConsoleApp1.exe
PROCESS ffffdb05c1641080
SessionId: 1 Cid: 1bc8 Peb: fd877dd000 ParentCid: 15ec
DirBase: 1b9ef3000 ObjectTable: ffffa105fc3d5280 HandleCount: 161.
Image: ConsoleApp1.exe
THREAD ffffdb05bf3c7080 Cid 1bc8.0924 Teb: 000000fd877de000 Win32Thread: ffffdb05c00d0ad0 WAIT: (Executive) KernelMode Alertable
ffffdb05c1902ef8 NotificationEvent
THREAD ffffdb05c0fc6080 Cid 1bc8.07c8 Teb: 000000fd877e4000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
ffffdb05be642ae0 NotificationEvent
THREAD ffffdb05be694080 Cid 1bc8.17dc Teb: 000000fd877e6000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
ffffdb05be645860 SynchronizationEvent
ffffdb05be646e60 SynchronizationEvent
ffffdb05be645d60 SynchronizationEvent
THREAD ffffdb05be7e2080 Cid 1bc8.1020 Teb: 000000fd877e8000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
ffffdb05b68b53a0 NotificationEvent
ffffdb05be651de0 SynchronizationEvent
1: kd> .thread ffffdb05bf3c7080
Implicit thread is now ffffdb05`bf3c7080
1: kd> k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 fffff50f`606ed570 fffff800`52c1c9c0 nt!KiSwapContext+0x76
01 fffff50f`606ed6b0 fffff800`52c1beef nt!KiSwapThread+0x500
02 fffff50f`606ed760 fffff800`52c1b793 nt!KiCommitThreadWait+0x14f
03 fffff50f`606ed800 fffff800`52df04c4 nt!KeWaitForSingleObject+0x233
04 fffff50f`606ed8f0 fffff800`53010cdb nt!IopWaitForSynchronousIoEvent+0x50
05 fffff50f`606ed930 fffff800`52fcc9e8 nt!IopSynchronousServiceTail+0x50b
06 fffff50f`606ed9d0 fffff800`52ff9ae8 nt!IopReadFile+0x7cc
07 fffff50f`606edac0 fffff800`52e0f3f5 nt!NtReadFile+0x8a8
08 fffff50f`606edbd0 00007ffa`2fb4d124 nt!KiSystemServiceCopyEnd+0x25
09 000000fd`8797e108 00000000`00000000 0x00007ffa`2fb4d124
從卦中看，主線程的內核態棧中的 nt!NtReadFile 函數果然給找到了。
2. 使用 procdump
如果僅僅是看線程的內核態棧，我發現有一個非常簡單的方式，就是在 procudump 中多加一個 mk 參數即可，截圖如下：
接下來使用 Terminal 執行 procdump，輸出如下：
PS C:\Users\Administrator\Desktop> procdump -ma -mk ConsoleApp -o D:\testdump
ProcDump v11.0 - Sysinternals process dump utility
Copyright (C) 2009-2022 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com
[16:24:49] Dump 1 initiated: D:\testdump\ConsoleApp1.exe_230605_162449.dmp
[16:24:50] Dump 1 writing: Estimated dump file size is 57 MB.
[16:24:50] Dump 1 complete: 57 MB written in 0.1 seconds
[16:24:50] Dump 1 kernel: D:\testdump\ConsoleApp1.exe_230605_162449.Kernel.dmp
[16:24:50] Dump count reached.
從卦中看，當前生成了兩個 dmp 文件，一個是用戶態dump，一個是內核態dump，也能看到後者還不到 1M，和剛纔用 notmyfault 生成的 500M dump 所存儲的信息量相差甚遠，但對我目前的場景來說已經夠用了。
接下來打開 ConsoleApp1.exe_230605_162449.Kernel.dmp 文件，使用 !process 找到 ConsoleApp1.exe 的進程。
..................................................
For analysis of this file, run !analyze -v
nt!DbgkpLkmdSnapThreadInContext+0x95:
fffff804`5e688b51 488364242800 and qword ptr [rsp+28h],0 ss:0018:ffffe10d`62386fd8=ffffe10d5b8fa810
0: kd> !process 0 2 ConsoleApp1.exe
Unable to read _LIST_ENTRY @ fffff8045ea1e080
0: kd> .reload /user
Loading User Symbols
0: kd> !process 0 2 ConsoleApp1.exe
Unable to read _LIST_ENTRY @ fffff8045ea1e080
從卦中看居然報錯了，那怎麼辦呢？辦法肯定是有辦法的，可以到用戶態dump中尋找進程ID即可。
0:000> ~
. 0 Id: 3adc.5920 Suspend: 0 Teb: 000000d6`7cb98000 Unfrozen
1 Id: 3adc.2240 Suspend: 0 Teb: 000000d6`7cba0000 Unfrozen
2 Id: 3adc.514 Suspend: 0 Teb: 000000d6`7cba2000 Unfrozen
3 Id: 3adc.3c68 Suspend: 0 Teb: 000000d6`7cba4000 Unfrozen ".NET Finalizer"
拿到 3adc 進程號後再找下麵的主線程，觀察它的線程棧信息，輸出如下：
0: kd> .process 3adc
Implicit process is now 00000000`00003adc
0: kd> !process
PROCESS ffffcf8d5d5b0080
SessionId: none Cid: 3adc Peb: d67cb97000 ParentCid: 4c80
DirBase: 367d95000 ObjectTable: ffff8e81710bbb40 HandleCount: <Data Not Accessible>
Image: ConsoleApp1.ex
VadRoot ffffcf8d5b20fcb0 Vads 90 Clone 0 Private 1529. Modified 941. Locked 2.
DeviceMap ffff8e8172645110
Token ffff8e815e216060
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
fffff78000000000: Unable to get shared data
ElapsedTime 00:00:00.000
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 153768
QuotaPoolUsage[NonPagedPool] 12648
Working Set Sizes (now,min,max) (14126, 50, 345) (56504KB, 200KB, 1380KB)
PeakWorkingSetSize 14033
VirtualSize 2101882 Mb
PeakVirtualSize 2101888 Mb
PageFaultCount 15757
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 1628
Job ffffcf8d53a102c0
THREAD ffffcf8d5ae14080 Cid 3adc.5920 Teb: 000000d67cb98000 Win32Thread: ffffcf8d54c3a3b0 RUNNING on processor 0
THREAD ffffcf8d4f63e080 Cid 3adc.2240 Teb: 000000d67cba0000 Win32Thread: 0000000000000000 INVALID
THREAD ffffcf8d69a32080 Cid 3adc.0514 Teb: 000000d67cba2000 Win32Thread: 0000000000000000 INVALID
THREAD ffffcf8d55003580 Cid 3adc.3c68 Teb: 000000d67cba4000 Win32Thread: 0000000000000000 INVALID
0: kd> .thread ffffcf8d5ae14080
Implicit thread is now ffffcf8d`5ae14080
0: kd> k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 ffffe10d`62386fb0 fffff804`5e688a7b nt!DbgkpLkmdSnapThreadInContext+0x95
01 ffffe10d`623874f0 fffff804`5e01dcd0 nt!DbgkpLkmdSnapThreadApc+0x3b
02 ffffe10d`62387520 fffff804`5e01bb67 nt!KiDeliverApc+0x1b0
03 ffffe10d`623875d0 fffff804`5e01ad6f nt!KiSwapThread+0x827
04 ffffe10d`62387680 fffff804`5e01a613 nt!KiCommitThreadWait+0x14f
05 ffffe10d`62387720 fffff804`5e439c68 nt!KeWaitForSingleObject+0x233
06 ffffe10d`62387810 fffff804`5e411fe9 nt!IopSynchronousServiceTail+0x238
07 ffffe10d`623878b0 fffff804`5e20d9f5 nt!NtReadFile+0x599
08 ffffe10d`62387990 00007ffe`6390d184 nt!KiSystemServiceCopyEnd+0x25
09 000000d6`7c9fe328 00000000`00000000 0x00007ffe`6390d184
怎麼樣，上面的 nt!NtReadFile+0x599 函數就是。
三：總結
有時候真的需要去抓內核態dump，總有一些千奇百怪的問題，太難了，這裡總結一下給後來人少踩坑吧。
