修电脑手记：排查总览
这组手记记录一台 Windows 笔记本从网络服务失效，到反复蓝屏、睡眠恢复异常，再到内存与温度检查的过程。能确认的是网络功能和系统文件修复取得过明确结果；截至这批记录最后的 2026 年 10 月 14 日，整机稳定性的根因仍未闭环。
文章于 2026 年 10 月 17 日整理。下面的“已恢复”“通过”均对应当时的检查范围，不代表此后一直没有复发。公开版保留方法、时间线和结论，原始日志、转储、设备标识与个人文件不公开。
从哪里开始读
Section titled “从哪里开始读”- 蓝屏与内存检查：停止码说明了什么，MemTest86 报错和 OCCT 短测应该怎样分别解释。
- Windows 网络服务恢复：从错误 5、1068 查到权限问题，以及为什么恢复 Wi-Fi 不等于修好整台电脑。
- 工具与记录模板：如何留存证据、控制变量，并把记录整理成可复核的结论。
这次排查的时间线
Section titled “这次排查的时间线”| 时间 | 当时观察或操作 | 可以得出的阶段结论 |
|---|---|---|
| 2026 年 9 月 | 已有多次异常重启；9 月 25 日记录到 0xA，历史停止码并不单一 | 故障早于 10 月这轮修复，不能全部归到最近一次更新 |
| 10 月 11 日前半段 | 原生 Wi-Fi 不可用，临时靠 USB 共享网络；多个网络服务启动失败 | 先保留备用联网能力，检查服务依赖与实际拒绝访问的位置 |
| 10 月 11 日 | 分阶段修复有证据支持的注册表权限，验证网络与防火墙服务 | Wi-Fi、地址获取、DNS、网络访问及防火墙在当时恢复 |
| 10 月 11 日后续 | 组件修复期间出现新的服务宿主异常，后来进行了系统重置与软件恢复 | 时间接近不足以证明哪项操作造成异常；网络恢复没有解决后续睡眠蓝屏 |
| 10 月 12 日 | DISM 修复成功，SFC 修复成功，随后组件库与系统文件复查通过 | 组件存储和受保护文件这一层得到修复，硬件与运行时稳定性尚未排除 |
| 10 月 13 日 | 两份新转储确认 0x4E/6 与 0x7E；登录阶段还出现卡死 | 系统文件修复通过与蓝屏复发可以同时成立，仍需继续查内存路径、平台与驱动 |
| 10 月 14 日 | 复核旧 MemTest86 的 3 次数据不一致；OCCT 有保护中断，也有完整短测零错误 | 已有真实异常证据，短测通过不能据此宣布故障消失 |
哪些已经确认，哪些还没有
Section titled “哪些已经确认，哪些还没有”已确认的事实：网络与防火墙目标服务曾恢复运行；DISM、SFC 的原生结果及后续复查支持系统文件修复成功；10 月 13 日有可用新转储；旧 MemTest86 记录包含实际数据不一致，而非只有界面卡住。
优先排查的方向：内存条、插槽、内存控制器、主板/固件与温度条件组成的稳定性问题。驱动写坏内存、DMA 或电源状态切换等方向仍然保留。这里的排序来自几类证据的组合，不是某个停止码直接给出的部件判决。
尚未确认的事情：哪一根内存或哪个部件有问题；权限最初由谁改变；散热条件是否是主因；某次更新或某个驱动是否是统一根因；睡眠与冷启动是否已经长期稳定。记录中没有足够证据把这些问题写成确定答案。
这次最值得保留的方法
Section titled “这次最值得保留的方法”先备份，再取证；每轮修改留好回退记录；把“检测到异常”和“怀疑某部件”分开写。系统文件、服务权限、驱动、电源状态和物理硬件是不同层面，一个层面的成功不能代替其他层面的验证。
例如，微软说明 DISM/SFC 用于修复 Windows 映像和系统文件；它们的通过不能作为内存硬件检查的替代品。微软：使用系统文件检查器
后续最有价值的证据是：在默认配置和明确测试条件下，用已知良好的内存及不同插槽交叉验证，同时观察冷启动、正常使用和睡眠恢复；若继续崩溃，保存对应时间的新转储。短时间“看起来好了”值得记录，但仍需用持续观察补齐结论。