排查工具与记录模板

这次修电脑积累下来的实用工具，不只是几个软件，更是一种记录顺序：先保存现场，再提出假设；每项工具只回答它能回答的问题；修改前后保留可比较的结果。

工具分别能说明什么

工具或记录	适合回答的问题	这次特别需要保留的边界
可靠性历史记录、事件查看器	何时异常、是否有停止码或服务故障	一条事件不自动等于根因；旧报告重复报送也不等于新增一次崩溃
WinDbg/CDB 与对应转储	检测到了哪类异常，当时调用链和参数是什么	栈上模块可能是受害者；没有新转储就保留缺口
服务状态与依赖配置	哪个服务先失败，下游为何无法启动	运行状态和依赖以本机当时配置为准
Procmon 短捕获	哪个进程、身份、对象及操作出现拒绝访问	单个拒绝事件需要与故障时间和启动结果关联
DISM、SFC 与复查日志	Windows 组件存储、受保护文件是否得到修复	通过不代替内存、主板、供电或睡眠稳定性验证
MemTest86	Windows 之外是否也出现数据不一致	不直接定位某根 DIMM；记录测试项、轮数、核心模式和是否完成
OCCT、HWiNFO	给定负载下的错误、终止原因和传感器变化	区分完整通过、提前停止和实际报错；传感器名称必须保留

例如，Kernel-Power 41 记录的是前一次没有正常关机，可能出现在蓝屏、卡死后断电等场景，不能直接翻译成“电源坏了”。微软建议结合停止码、其他事件和实际现象继续调查。微软：事件 41 的排查说明

先做轻量取证

遇到新故障时，先记准确时间、正在进行的操作、刚做过的改动，以及是冷启动、睡眠恢复还是持续负载中发生。停止码照片应保留完整代码；如果有转储，核对它的时间是否对应这一次。

网络服务问题可先查看当前状态。下面的 PowerShell 示例只读取状态，不修改服务：

Get-Service -Name BFE,Dhcp,Dnscache,WinHttpAutoProxySvc,Wcmsvc,WlanSvc,MpsSvc,IKEEXT |
  Select-Object Name,Status,StartType

检查结果应在本地保存，不直接把完整事件、命令行或转储上传到公开网站。Procmon 本身能记录用户、命令行等上下文，取证文件应按私密资料对待。微软：Process Monitor 的记录能力

转储配置也要核实实际产物。微软说明自动内存转储与分页文件管理有关；“已经开启”不代表每次崩溃都一定留下文件。本次就出现过新故障缺少可用转储的情况，应记录为证据缺口。微软：自动内存转储

一轮只验证一个问题

先备份重要资料，副本应与待排查设备的风险分开；复制后可校验文件，另一块内置盘也不能替代所有外部备份。之后列出这一轮要回答的问题，例如“原生 Wi-Fi 的服务依赖是否恢复”，而不是笼统地问“电脑好了没有”。

修改驱动、服务、电源设置或权限前，写清旧值、修改理由、预期现象和回退办法。一次改很多项，可能暂时改善使用体验，却很难知道哪项起作用。临时降低负载或避开睡眠也应标为缓解措施，不能悄悄变成修复结论。

系统文件修复按微软当前流程先运行 DISM，再运行 SFC，并保存原生输出和复查结果。不要把日志行数、不同路径数、重复报送数与硬件错误次数相加，它们不是同一个统计单位。微软：DISM 与 SFC 修复流程

可直接复制的记录模板

也可以下载 Markdown 记录模板，保存在自己的本地笔记里填写。

日期与时区：
本轮要回答的问题：

故障现象：
发生场景：冷启动 / 睡眠恢复 / 普通使用 / 指定负载
最近一次改动及时间：

证据来源：本人观察 / 事件 / 转储 / 工具日志 / 他人转述
故障时间与证据时间是否匹配：
已确认事实：
当前假设及支持理由：
相反证据与尚缺资料：

本轮操作：
原状态、备份与回退方式：
验证条件：版本、参数、负载、时长、装配状态、起始温度
验证结果：完成无错 / 检测到错误 / 提前停止 / 无法判断
停止原因及传感器全名：

阶段结论及适用范围：
仍未解决的问题：
下一步只验证什么：

需要交给售后时，再附一页简明时间线，突出可重复场景、实际数据错误、尝试过的操作及结果。原始资料单独保存，公开文章只留脱敏摘要。

公开前的整理

本组手记没有发布原始转储、注册表导出或诊断日志，也去掉了用户名、设备序列号、绝对个人路径、网络地址及个人文件信息。保留停止码和服务名，是为了说明判断依据；保留“未知”，是为了让后续的新证据还能修正结论。

这比写成一篇“几个步骤彻底修好”的教程更符合本次实际情况。整组记录的阶段结论见排查总览。