一次「系统优化」导致 Windows 无法启动的排查与修复记录

记录一次由 AI 助手执行的 Windows「清理优化」把系统弄得无法启动、并从 Arch 侧离线定位根因并修复的全过程。

TL;DR

• 现象：优化脚本执行后，Windows 重启即「Legion logo → 黑屏 → 自动重启」循环；安全模式同样失败，且没有蓝屏（是卡死，不是崩溃）。
• 根因：清理脚本删除了 Winsock 命名空间目录里的一条 NSP 条目，却没有同步把目录计数减 1。注册表变成「计数 = 9、实际条目 = 8」，开机初始化 Winsock 时读到不存在的第 8 条 → 启动卡死。
• 修复：把 Num_Catalog_Entries / Num_Catalog_Entries64 改回 8，并把剩余条目重编号补齐（9 → 8），离线写回注册表后即可正常启动。
• 教训：修改「成对 / 成组」的底层数据（计数、索引、过滤器列表）必须维护其不变量；延迟到下次开机生效的改动，必须重启验证后再宣布完成。

1. 环境

双系统在这里非常关键：Arch 相当于一个「自带的正规救援系统」，让我们能离线挂载 NTFS、解析注册表与日志、直接修复。

2. 背景：AI 做了什么

在 Windows 上，用 opencode + deepseek-flash 做了一次「系统垃圾与启动项清理」，共生成并执行了 10 个阶段的 PowerShell 脚本（系统优化脚本1~10.ps1），日志在桌面 优化日志*.txt。摘要：

关键点：脚本 7~10 在 06:11–06:15 运行，之后系统正常关机，这些改动要到「下一次开机」才第一次生效。

3. 现象与时间线

诊断要点：「卡死」而非「崩溃」——没有生成 MEMORY.DMP/minidump，System.evtx 没有新事件，bootstatuspolicy=DisplayAllFailures 也没抓到蓝屏，说明系统在写事件日志之前就已经挂住。

4. 排查过程

从 Arch 侧离线进行：

1. 挂载 Windows 盘（只读），确认盘符与结构。
2. 读 opencode 记录：会话数据库（~/.local/share/opencode/opencode.db）、10 个脚本、桌面日志，还原出「到底改了什么」。
3. 解析注册表 hive（SYSTEM / SOFTWARE）、事件日志（System.evtx）、Kernel-Boot、MeasuredBoot、SrtTrail.txt、CBS.log、ntbtlog.txt、NTFS USN 日志（还原那次开机的文件增删）。
4. 逐项排除：
   • 启动关键驱动（Start=0/1）文件一个不缺；
   • 核心文件（dxgkrnl / win32k / cdd / monitor / ntoskrnl）与 WinSxS 原件哈希一致；
   • SSD SMART 正常（可用备用 100%、已用 6%、数据完整性错误 0）；
   • Startup Repair 跑两次，「根本原因数 = 0」；
   • sfc / dism /restorehealth 无法修复（DISM 报 0x800f081f 缺源）。
5. 关键反转：读 sfc.log 发现 SFC 实际只报了一张锁屏壁纸 C:\Windows\Web\Screen\img105.jpg 损坏（chkdsk 顺带修过一点 NTFS 元数据）——与启动无关，是误导。
6. 用时间戳做 diff：把「脚本 7~10 运行时段」内被修改的注册表键全部列出来。SYSTEM 里只有寥寥几处，其中一处就是：
   ...\Services\WinSock2\Parameters\NameSpace_Catalog5\Catalog_Entries(64) —— 立刻核对计数。

5. 根因

注册表位置：

1
2
3
4
5
6
7

HKLM\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\NameSpace_Catalog5
├── Num_Catalog_Entries      = 9        ← 计数
├── Num_Catalog_Entries64    = 9
├── Catalog_Entries
│     ├── 000000000001 … 000000000007   （7 条）
│     └── 000000000009                  （Bonjour mdnsNSP）
└── Catalog_Entries64                    （同上）

• 删除前：条目 1..9（9 条），计数 9。
• 脚本 7 用 Remove-Item 删掉了第 8 条（NI 的 nimdnsNSP）：
  • 只剩 1..7 和 9（8 条），
  • 但计数仍是 9。
• 于是 Winsock 命名空间目录出现「计数 9 / 实际 8」的不一致，并且第 8 个索引缺失。

Windows 初始化 Winsock 时会按计数去读条目；读不到第 8 条 → 启动期在 Winsock/服务初始化阶段卡住。

为什么脚本会漏：Windows 正常增删 NSP 通过 API 完成、API 会自动维护计数；脚本直接删注册表子键，绕过了这个不变量维护。

6. 修复

离线（Arch 侧）修改 Windows 的 SYSTEM hive：

1. Num_Catalog_Entries / Num_Catalog_Entries64：9 → 8；
2. 把剩余的 Bonjour 条目 000000000009 重编号为 000000000008（使条目连续为 1..8）；
3. 写回 C:\Windows\System32\config\SYSTEM 并同步 hive 日志。

修改后校验：Catalog_Entries(64) = 1..8，计数 = 8。重启一次即恢复正常。

备份：~/ocwin/SYSTEM.bak-nsp-*，以及 ESP 上的 BCD.bak-scheng-*。

7. 为什么症状长这样

8. 教训与检查清单

1. 动「成对/成组」的底层数据（计数、索引、过滤器列表等）——要么走正规 API，要么改完立刻校验一致性。
2. 任何延迟到下次开机生效的改动，必须重启验证后再宣布完成。
3. 排查顺序建议：先分清「卡死」还是「崩溃」→ 看最近改了什么 → 做状态 diff → 小步改、每步重启验证。
4. 排查「无法启动」时，别急着相信 sfc 的「发现损坏文件」——它可能只是锁屏图片之类的无关文件。
5. 手边常备一个救援系统（双系统 / Linux live USB / Windows 安装 U 盘）+ 重要数据备份；比什么都实在。

9. 工具箱（本次实际用到）

• 离线挂载 NTFS / ESP：udisksctl / mount（ntfs3 / ntfs-3g）
• 注册表 hive 读写：hivexsh / hivexregedit / python-registry
• 日志解析：python-evtx、strings、NTFS USN 日志解析
• Windows 侧：WinRE、bcdedit、sfc、dism、chkdsk、reg
• 引导编辑：BCD（/boot/EFI/Microsoft/Boot/BCD）

记录整理自 2026-10-06 的排查过程。