Win10蓝屏后怎么用命令行查看错误代码？完整排查流程
电脑突然蓝屏重启，蓝令行流程回到桌面后只看到一句“你的屏后排查设备遇到问题，需要重启”，用命具体原因却一闪而过。查看错误很多人第一反应是代码重装系统，其实 Windows 10 已经把这次崩溃的完整关键信息记录在日志和转储文件里，用几条命令行就能把错误代码、蓝令行流程出错驱动、屏后排查崩溃时间翻出来。用命本文按“先确认有没有记录、查看错误再读出代码、代码最后定位原因”的完整顺序，给你一套可以直接照做的蓝令行流程流程。
需要先明确一点：命令行只是屏后排查“读取工具”，它不会修复问题，用命也不会给出百分之百的结论。蓝屏代码指向的是崩溃瞬间的调用现场，最终判断还要结合你最近装了什么驱动、更新了什么补丁、加过什么硬件。下面涉及的系统路径和命令，若你的系统版本或界面存在差异，以本机实际显示和微软官方说明为准。
第一步：先用管理员命令行确认崩溃记录是否存在
蓝屏能否查到代码，前提是系统保留了转储文件。右键点击“开始”按钮，选择“Windows PowerShell（管理员）”或“命令提示符（管理员）”，在用户账户控制弹窗中点“是”。先执行下面这条命令，查看转储相关配置：
wmic recoveros get DebugInfoType,AutoReboot
返回值中 DebugInfoType 常见含义是：0 表示不写入任何转储，1 表示完整转储，2 表示内核转储，3 表示小内存转储（小型转储，通常 256KB 左右），7 表示自动内存转储。如果是 0，说明系统根本没保存崩溃信息，你需要先到“此电脑 → 属性 → 高级系统设置 → 启动和故障恢复 → 设置”里，把“写入调试信息”改为“自动内存转储”或“小内存转储”，下次蓝屏才有据可查。改完记得重启一次让设置生效。
接着确认文件是否真的生成了。默认位置是 C:\Windows\Minidump（小型转储）和 C:\Windows\MEMORY.DMP（完整或内核转储）。执行：
dir C:\Windows\Minidump
如果提示“找不到文件”，而 MEMORY.DMP 也不存在，那多半是转储被关闭、磁盘空间不足，或者蓝屏发生在系统还没加载完驱动的极早期阶段。这种情况命令行查不到代码，只能改用事件查看器或开启驱动程序验证程序来复现。
第二步：用命令行读出错误代码和出错模块
拿到 dump 文件后，最直接的工具是微软官方的调试器 WinDbg（现在通常通过 Microsoft Store 安装“WinDbg”）。安装后在管理员命令行里进入调试器目录，或直接使用其命令行版本 kd。典型分析命令是：
kd -z C:\Windows\Minidump\091524-12345-01.dmp
加载完成后输入 !analyze -v 并回车。输出内容较多，重点看这几行：BugCheck 后面的十六进制值就是蓝屏错误代码，例如 0x0000007E、0x000000D1、0x0000003B；紧随其后的 BugCheck 字符串会给出中文或英文名称，比如 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED、DRIVER_IRQL_NOT_LESS_OR_EQUAL；再往下 MODULE_NAME、IMAGE_NAME、FAULTING_MODULE 往往就是可疑的驱动文件名，如 xxx.sys。这个 .sys 名字，就是后续排查的主要线索。
如果不想装调试器，可以用 PowerShell 读取系统日志里的 BugCheck 事件，虽然信息不如 dump 详细，但胜在快：
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=1001} -MaxEvents 10 | Format-List TimeCreated,Message
Id 为 1001 的事件由 BugCheck 写入，Message 里通常包含错误代码和部分参数。若查不到，可把 Id 换成 41（Kernel-Power），它记录的是“系统未正常关机就重启”，但 41 本身不代表蓝屏原因，只能说明发生了异常断电式重启，需要和 1001 配合看。
第三步：把错误代码翻译成可执行的排查动作
代码本身不是结论，关键是它常对应的方向。0x000000D1、0x0000000A 多与驱动访问了错误内存地址有关，优先怀疑网卡、显卡、无线网卡、杀毒软件的网络过滤驱动；0x0000007E、0x0000003B 常出现在系统文件或驱动抛出未处理异常时，可先跑 sfc /scannow 和 DISM /Online /Cleanup-Image /RestoreHealth 检查系统映像；0x00000050 常指向内存或驱动，建议先用 Windows 内存诊断工具（命令行输入 mdsched 后回车，选择重启后检查）排除内存条问题；0x000000EF 多见于关键系统进程异常，常与系统更新失败或磁盘错误有关，可再执行 chkdsk C: /f（需重启后执行）。
针对 dump 里出现的具体 .sys 文件，处理顺序建议是：先在“设备管理器”里找到对应设备，回滚或更新驱动；若是第三方安全软件、虚拟网卡、外设驱动，先临时卸载观察；如果是 ntoskrnl.exe、ntfs.sys 这类系统核心模块，通常不代表它们本身坏了，而是被其他驱动带崩，别急着重装系统。最近安装的更新也可以用 wmic qfe list brief 列出来，对照崩溃首次出现的时间点判断。
失败分支：查不到代码时怎么办
如果 Minidump 目录为空、MEMORY.DMP 也没有，可以按这个顺序补：一是回到“启动和故障恢复”确认转储类型不是“无”，并确认系统盘剩余空间大于转储文件所需大小；二是关闭“自动重启”，让蓝屏画面停留在屏幕上，手动拍照记录代码，路径是“高级系统设置 → 启动和故障恢复 → 取消勾选自动重新启动”；三是若蓝屏过于随机，可在管理员命令行执行 verifier 打开驱动程序验证程序，只勾选“除微软自带驱动外”的第三方驱动，复现后关闭，因为验证程序本身会明显拖慢系统，排查完必须关掉，否则可能引入新的不稳定。
另外要提醒：网上流传的“蓝屏代码对照表”很多是互相抄的，代码只能缩小范围，不能直接锁定某个软件。涉及系统更新失败、激活、硬盘健康等敏感问题，建议以微软官方支持页面、设备厂商官网的驱动说明和系统自带诊断结果为准，不要轻信第三方“一键修复”工具，它们常常会顺带装上不需要的软件。
小结一下可执行的顺序：先用 wmic recoveros 确认转储是否开启，再看 Minidump 和 MEMORY.DMP 是否存在，然后用 kd 加 !analyze -v 读出 BugCheck 代码和可疑模块，最后按代码方向处理驱动、内存、磁盘或系统文件；如果日志为空，就关掉自动重启并拍照留证，必要时用驱动程序验证程序复现。整个流程不改动系统核心文件，风险可控，做完再决定是继续排查还是寻求官方支持。