蓝屏代码 system_service_exception（0x0000003b）需通过 minidump 文件用 windbg 分析：执行 !analyze -v 查 module_name，再用 kb 定位首个非系统模块，最后用 lmvm 获取其路径、版本与签名状态以精准识别肇事驱动。
当你看到蓝屏代码 SYSTEM_SERVICE_EXCEPTION（0x0000003B）时，它本身不指向某个具体 DLL，而是表明内核在调用某个系统服务例程时遭遇了非法内存访问或无效指针解引用——真正肇事的模块往往藏在堆栈末尾的驱动或系统 DLL 中，必须通过 minidump 文件逆向定位，不能靠猜。
提取并加载蓝屏转储文件
打开 C:\Windows\Minidump，确认至少有一个 .dmp 文件存在（如 092526-12345-01.dmp），【若该文件夹为空，说明你尚未启用小内存转储】。按 Win+R 输入 sysdm.cpl → 高级 → 启动和故障恢复 → 设置 → 写入调试信息选“小内存转储”，确定后重启，再等一次蓝屏生成日志。
下载 Windows SDK 里的 WinDbg Preview（Microsoft Store 可直接安装），启动后点击 File → Start debugging → Open dump file，选中刚生成的 .dmp 文件。
用 !analyze -v 快速抓出关键嫌疑模块
WinDbg 加载完成后，在命令栏输入：!analyze -v，回车执行。
等待分析完成，重点看 “MODULE_NAME” 和 “IMAGE_NAME” 两行——它们通常会明确标出引发异常的模块名，比如 nvlddmkm.sys（NVIDIA 显卡驱动）、WdFilter.sys（Windows Defender 过滤驱动）或 vhdmp.sys（VHD 虚拟磁盘驱动）。如果显示的是 ntoskrnl.exe 或 win32kfull.sys，说明问题已深入内核或图形子系统，需继续往下查堆栈。
注意：不要只看 “Probably caused by” 行，它有时会误判；务必核对 “STACK_TEXT” 区域最顶部的非系统模块（即非 ntoskrnl、hal、win32k 开头的条目）。
用 kb 查看完整调用堆栈并锁定 DLL
在 WinDbg 命令栏输入：kb，回车。
你会看到一列地址与模块名混排的调用链。从最上面开始往下扫，跳过所有以 ntoskrnl.exe+0x、hal.dll+0x、win32kfull.sys+0x 开头的行，找到第一个出现的第三方模块或可疑系统 DLL，例如：fffff802`3a1b2c3d nvlddmkm!GpuHangRecovery+0x1a2fffff802`3a1b2c4e dxgmms2!DxgAdapter::SubmitCommandBuffer+0x87fffff802`3a1b2c5f dxgmms2!DxgDevice::Present+0x21a
这里 nvlddmkm.sys 就是核心嫌疑对象；若看到 AcroRd32.dll、ChromeRenderer.dll 等用户态 DLL 出现在内核堆栈里，说明有驱动违规将用户地址传入内核——这种 DLL 必须被关联到其加载它的驱动（如某 PDF 预览壳、浏览器沙盒驱动）。
用 lmvm 定位 DLL 的完整路径与时间戳
在 WinDbg 中输入：lmvm nvlddmkm（把 nvlddmkm 换成你上一步发现的模块名），回车。
输出中会显示该模块的完整路径（如 C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_1a2b3c4d5e6f7g8h\nvlddmkm.sys）、文件版本、时间戳和数字签名状态。特别关注 “Timestamp” 字段：如果它比当前系统日期早三年以上，大概率是旧驱动残留；如果签名显示 “Not signed”，基本可判定为非法驱动或被篡改模块。
这一步做完，你就拿到了肇事 DLL 的精确位置、版本和可信度证据，下一步就是去设备管理器卸载对应硬件驱动，或手动重命名该 .sys 文件后重启验证。
