机器蓝屏重启之后，能用的线索只有三样：屏幕上那行stop code、C:\Windows\Minidump里的dmp文件、事件查看器里的1001号事件。三样里只要留住一样，就能查到是哪个驱动出的问题。怕的是重启后什么都不留，默认的转储设置确实有可能一个文件都不写。
先把转储打开，再谈分析。
转储文件生成在哪两个目录
%SystemRoot%\MEMORY.DMP放的是内核转储或完整转储，只有一份，下次蓝屏会把它覆盖掉。%SystemRoot%\Minidump目录里放的是小内存转储，每次崩溃单独一个文件，名字带日期，会一直攒着。要查一周前那次崩溃，只能靠这个目录。
之前遇到过一台机器连着崩了十几天，Minidump里躺着十几个dmp，把文件名按日期排一遍，崩溃是从哪天开始的就清楚了。
转储没写出来先改这里
sysdm.cpl打开系统属性，高级选项卡，启动和故障恢复那一栏点设置，写入调试信息下拉框默认可能是"无"。选"自动内存转储"最省事，它和内核转储的信息量一样，但页面文件大小交给系统自己管。要留全部物理内存就选"完全内存转储"，代价是页面文件得开到跟内存差不多大，而且必须放在系统盘。
下拉框里"小内存转储(256 KB)"这个叫法跟微软注册表文档写的64 KB对不上，实测生成的dmp文件多在300KB上下，够用了。
注册表对应位置是HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl，改完必须重启才生效：
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 7 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v DumpFile /t REG_EXPAND_SZ /d "%SystemRoot%\MEMORY.DMP" /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v MinidumpDir /t REG_EXPAND_SZ /d "%SystemRoot%\Minidump" /f
CrashDumpEnabled取值是0不写、1完全内存转储、2内核内存转储、3小内存转储、7自动内存转储。DumpFile默认%SystemRoot%\Memory.dmp，MinidumpDir默认%SystemRoot%\Minidump，Overwrite设1表示允许覆盖旧文件。顺手把"自动重新启动"的勾去掉，屏幕上的stop code就能看得完整些，不用靠别人转述。
事件查看器里的BugCheckCode
eventvwr.msc打开事件查看器，Windows日志→系统，筛选事件ID 41与1001。41是Kernel-Power记的意外关机，1001是BugCheck，源是Windows Error Reporting。双击1001那条，详细信息切到XML视图，里面能找到BugCheckCode、四个BugCheckParameter，还有一串FailureBucketId。
屏幕没拍到、dmp也没生成的时候，这里大概率还有记录。
命令行批量翻也行：
wevtutil qe System "/q:*[System[(EventID=1001 or EventID=41)]]" /f:text /c:20 /rd:true
Windows 10.0.19045、10.0.22631、10.0.26100、10.0.26200，这几个build上读出来的字段名字是一样的，查法不用换。
常见stop code各自指向什么
0x0000000A IRQL_NOT_LESS_OR_EQUAL，驱动在高IRQL上碰了不该碰的分页内存。第一个参数小于0x1000，基本就是空指针解引用。
0x000000D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL，症状同上，只是这次能明确落在驱动头上。
0x0000001A MEMORY_MANAGEMENT，内存管理出错，先怀疑内存条本身。
0x0000003B SYSTEM_SERVICE_EXCEPTION，系统调用里抛了异常，显卡驱动和杀毒软件的过滤驱动都很常见。
0x00000050 PAGE_FAULT_IN_NONPAGED_AREA，访问了不存在的非分页内存地址。
0x0000007B INACCESSIBLE_BOOT_DEVICE，开机就蓝，多半是BIOS里把磁盘控制器从IDE改成了AHCI或RAID，或者存储驱动没打进镜像。微软对这个码点名要查的第一项就是这类UEFI改动。
0x0000007F UNEXPECTED_KERNEL_MODE_TRAP，陷阱号0x00000008是双重错误，微软点名的成因是内核栈溢出，举的例子是两个文件系统过滤驱动挂在同一条栈上。装了备份agent又叠一层安全agent的机器，见得比较多。
0x0000009F DRIVER_POWER_STATE_FAILURE，休眠或唤醒时驱动不肯放手。
0x000000EF CRITICAL_PROCESS_DIED，csrss.exe、wininit.exe、smss.exe这类关键进程没了。这个码只说症状，具体是哪个进程要开dmp看。
0x00000116 VIDEO_TDR_FAILURE，显卡驱动超时，默认2秒，一分钟内超过5次就直接bug check。
0x00000124 WHEA_UNCORRECTABLE_ERROR，硬件报的不可纠正错误，CPU、PCIe链路都算。看到这个别在驱动上耗时间，去查硬件。
0x00000133 DPC_WATCHDOG_VIOLATION，某个DPC例程跑太久。
0x00000139 KERNEL_SECURITY_CHECK_FAILURE，内核检测到结构被破坏，第三方安全软件是高频来源。
用WinDbg读dmp
Microsoft Store里装WinDbg Preview，File→Open dump file，选Minidump目录里最新的那个dmp。进调试器先配符号路径：
.sympath srv*https://msdl.microsoft.com/download/symbols .reload !analyze -v
!analyze -v的输出里看三处：Probably caused by后面跟的sys文件名、MODULE_NAME与IMAGE_NAME、下面的STACK_TEXT。拿到sys文件名再去搜它是哪个厂商的什么产品，这一步比读栈快得多。
符号拉不下来就先打开符号加载日志（sym noisy）看它到底去哪儿下的，本机出口挂着代理的时候经常卡在这一步。
lmvm跟模块名可以看这个驱动的编译时间与版本；blackboxntfs、blackboxbsd这类黑盒命令在Windows 8之后的内核转储里能拿到崩溃前那几条记录，小内存转储里不一定有。
不想配符号的两条快捷路
BlueScreenView（NirSoft）双击就出结果，把崩溃时的驱动栈铺开，肇事驱动用红色标出来，看Caused By Driver那一栏。WhoCrashed（Resplendence）更进一步，直接给一句人话结论。两个工具都要本机有能读dmp的调试引擎，装好WinDbg基本就都满足了。
实测下来十次里有七八次这两个工具给的结论跟analyze输出一致，剩下那几次基本是符号不全造成的误判。
一批机器都是同一个stop code时，别一台一台看，把所有dmp丢给同一个工具跑一遍，找它们都指向的那个sys。一个补丁窗口之后批量冒出来的同码蓝屏，通常不是每台机器各有各的原因。
驱动嫌疑最大，怎么逼它现形
微软在驱动文档里给出的说法是大约四分之三的stop code由驱动引起。继续往下挖就用verifier：
verifier /standard /all
打开之后系统会故意让有问题的驱动触发蓝屏，所以只在测试机上开，查完记得verifier /reset关掉。开着它日常用机器会明显变慢。
驱动之外该查的地方
sfc /scannow修复系统文件，报"发现损坏但无法修复"就接着跑DISM /Online /Cleanup-Image /RestoreHealth，然后再回来跑一遍sfc。存储用chkdsk /scan看一眼，配合CrystalDiskInfo读SMART，有重映射扇区计数在涨就先备份再换盘。怀疑内存就mdsched.exe跑Windows内存诊断，或者MemTest86跑满四遍，XMP和EXPO这类超频配置先关掉再测。
改完别急着收工，过一周再筛一次1001，没有新记录才算真的好了。数据截至2026年10月。