捉虫笔记（七）-再探谁把系统卡住
1、内核调试
在实体物理机上，内核调试的第一个门槛就是如何建立调试链接。
这里我选择的建立网络连接进行内核调试。
至于如何建立网络连接后续文章再和大家分享。
2、如何分析
在上一篇文章中，我们通过种种蛛丝马迹发现最后就是我们的程序导致了驱动崩溃。 但是我始终觉得还是缺少致命一击，缺少一个绝对的证据证明就是我们的程序导致驱动崩溃。
我们接着分析，如图所示就表示已经连接上了。
接下来就是按照原来的操作再来一边。
调试器立马收到了异常，并报告出来。这幸福来得有点突然了。
使用
!analyze -v分析结果
SYMBOL_NAME: nvlddmkm+bd3432
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: bd3432
FAILURE_BUCKET_ID: 0x0_nvlddmkm!unknown_function
OS_VERSION: 10.0.22621.1
BUILDLAB_STR: ni_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {caac5c5f-0db0-04d5-7bea-7d62e0e44e6c}
Followup: MachineOwner
这个分析结果和之前的分析是一致的。
接着执行上面的提示的命令：.cxr; .ecxr ; kb
我们接着看当前是哪个进程。 执行命令? @$proc，打印当前进程ID
Evaluate expression: -30170063146880 = ffffe48f3e0d1040
在执行命令!process ffffe48f3e0d1040 0
PROCESS ffffe48f7c1a7080
SessionId: 1 Cid: b474 Peb: 67789b8000 ParentCid: afe0
DirBase: d5d05c002 ObjectTable: ffffab0e9c52a600 HandleCount: 2745.
Image: software.exe
果然software.exe这个熟悉的名字。
接着我们执行下!thread命令：
因为我们的进程再走退出流程了，所以这里只看一个线程信息.
THREAD ffffe48f9e1b8080 Cid b474.ad54 Teb: 00000067789b9000 Win32Thread: ffffe48f8f0a9110 RUNNING on processor 0
IRP List:
ffffe48f43895bc0: (0006,0118) Flags: 00060000 Mdl: 00000000
Not impersonating
DeviceMap ffffab0e97f399b0
Owning Process ffffe48f7c1a7080 Image: software.exe
Attached Process N/A Image: N/A
Wait Start TickCount 6407289 Ticks: 0
Context Switch Count 249128 IdealProcessor: 15
UserTime 00:01:00.531
KernelTime 00:00:40.031
*** WARNING: Unable to verify checksum for software.exe
Win32 Start Address software!WinMainCRTStartup (0x00007ff648fb12d8)
Stack Init ffff838f6d657b70 Current ffff838f6d6573a0
Base ffff838f6d658000 Limit ffff838f6d651000 Call 0000000000000000
Priority 10 BasePriority 10 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
fffff804`1670f860 fffff804`4261fb0a nvlddmkm+0xbd3432
fffff804`1670f930 fffff804`42620f34 nvlddmkm+0xbffb0a
fffff804`1670fab0 fffff804`4262154e nvlddmkm+0xc00f34
fffff804`1670fb70 fffff804`41aebf4b nvlddmkm+0xc0154e
fffff804`1670fbd0 fffff804`41d6b1a8 nvlddmkm+0xcbf4b
...
3、总结
利用内核调试，不出一个小时就精准定位了是谁导致了系统卡顿。 但其实这个配置调试环境着实费一番功夫。
