要定位Windows蓝屏根本原因，必须解析Dump日志文件；需先确认Dump功能已启用并找到文件路径，再用事件查看器获取错误码，接着用BlueScreenView快速识别问题驱动，最后用WinDbg Preview深度分析调用栈和故障模块。
要定位Windows蓝屏死机的根本原因，必须解析系统自动生成的Dump日志文件（.dmp），这些文件记录了崩溃瞬间的内存状态、异常代码、调用栈和故障模块，直接关系到能否准确识别问题驱动或系统组件。没有它，所有排查都是凭空猜测。
确认Dump功能已启用并找到文件位置
系统默认可能完全禁用Dump生成，若没这一步，后续所有分析都无从谈起。
按 Win + R 输入 sysdm.cpl → 切换到“高级”选项卡 → 点击“启动和故障恢复”右侧的“设置” → 检查“写入调试信息”是否为【小内存转储(256 KB)】（最常用且平衡）或“完全内存转储”（需大磁盘空间）；同时务必勾选“将事件写入系统日志”。
记下“转储文件”路径：小型转储默认是 C:\Windows\Minidump\，完整转储则是 C:\Windows\MEMORY.DMP。
打开文件资源管理器，直接在地址栏粘贴该路径并回车。若提示“拒绝访问”，右键文件夹→“属性”→“安全”→编辑当前用户权限，赋予“读取”和“列出文件夹内容”即可——【不要点‘完全控制’，有安全风险】。
用事件查看器快速锁定蓝屏时间与错误码
事件查看器不分析内存，但它能告诉你蓝屏发生的确切时间、BugCheckCode（如0x0000007E）和初步模块线索，是分析前的必要坐标锚点。
Win + R 输入 eventvwr.msc → 左侧展开“Windows 日志”→点击“系统”→右侧点“筛选当前日志”→在“事件ID”框中输入 1001 → 点“确定”。
在结果中找“来源”列为 BugCheck 的条目，双击打开 → 切换到“详细信息”选项卡 → 查看“事件数据”末尾几行：BugcheckCode（十六进制）、BugcheckString（如IRQL_NOT_LESS_OR_EQUAL）、Faulting Module Name（如dxgmms2.sys）——这三个字段必须抄下来，后面WinDbg分析时要交叉验证。
用BlueScreenView快速标红问题驱动
这是最快出结论的方法，适合不想配符号、不熟悉命令行的用户，尤其擅长从多个.dmp中揪出反复作祟的驱动。
方法一：去 NirSoft 官网下载 BlueScreenView 绿色版，解压后右键 BlueScreenView.exe → 以管理员身份运行。
软件启动即自动扫描 C:\Windows\Minidump\ 下全部 .dmp 文件，主界面列表中“Caused By Driver”列非空的行就是重点怀疑对象，颜色越红越可疑；点击该行，下方面板会显示对应崩溃的 BugCheckCode 和堆栈片段。
方法二：若你只关心最近一次蓝屏，可先在 Minidump 目录里按“修改日期”排序，找出最新那个 MiniXXXXXX-XX.dmp，拖进 BlueScreenView 窗口直接加载——这比全扫快得多，也更聚焦。
用WinDbg Preview执行深度自动分析
这是唯一能还原调用栈、定位具体函数甚至源码行号的手段，前提是符号路径配置正确。没它，你永远不知道崩溃发生在驱动的哪一行代码里。
第一步：从 Microsoft Store 免费安装 WinDbg Preview，首次启动后，点击顶部菜单 File → Settings → Debugging settings → 在“Default symbol path”框中粘贴：
srv*https://msdl.microsoft.com/download/symbols
第二步：点击 File → Start debugging → Open dump file（或 Ctrl+D），选择你要分析的 .dmp 文件。
第三步：等底部状态栏显示 “Loading symbols” 并最终变为 “Ready” 后，在命令窗口输入：
!analyze -v → 回车。
输出结果中重点关注三处：
① FAILURE_BUCKET_ID 行（含驱动签名和错误类型，如 “0x1A_nt!MiDeleteVirtualAddresses”）；
② STACK_TEXT 区域顶部几行（显示最上层调用函数及模块名）；
③ MODULE_NAME 和 IMAGE_NAME（确认是第三方驱动还是系统模块）。
如果看到 “*** ERROR: Module load completed but symbols not loaded for XXX.sys”，说明符号没下全，此时在命令窗口补一句：
.reload /f → 回车，再重跑 !analyze -v。
