以下内容由 AI 生成：
排查结论：这三次蓝屏的根因是同一个：SOFTWARE 注册表配置单元（Hive）体积异常膨胀并导致内部结构损坏。三个不同的错误码（0x3B、0x51、0x1E）只是配置管理器在不同代码路径上读取到损坏数据后触发的不同异常。
以下是具体的分析过程。
一、 三次崩溃的调用栈分析
1. 2026/09/24 14:14 — 0x3B SYSTEM_SERVICE_EXCEPTION
崩溃进程是 Registry（配置管理器）。在 nt!memcpy 处发生访问违例。
往上追溯调用栈：
nt!HvReallocateCell
nt!CmpAddValueToListEx
nt!CmSetValueKey
崩溃点在于 HvReallocateCell 重新分配 Hive 单元格时，HvpDoAllocateCell 返回了一个超出该 Hive 映射区范围的 Cell 地址，导致 memcpy 拷贝数据时写入越界。当时涉及的 Hive 文件是 \System32\Config\SOFTWARE，大小为 93.5 MiB。
2. 2026/10/12 17:48 — 0x51 REGISTRY_ERROR
崩溃进程同样是 Registry。
调用栈：nt!HvpGetCellPaged -> nt!CmQueryValueKey。
查看 HvpGetCellPaged 的反汇编，触发 BugCheck 的条件是调用者传入的 CellIndex 为 0xFFFFFFFF（无效索引）。这种无效索引通常是因为 Hive 内部的 KEY_NODE 或 KEY_VALUE_LIST 数据已经损坏，读取到了无效数据。此时 SOFTWARE 文件已经增长到 100.0 MiB。
3. 2026/10/14 10:05 — 0x1E KMODE_EXCEPTION_NOT_HANDLED
崩溃进程依然是 Registry。
调用栈：nt!HvpMapEntryGetBinAddress -> nt!HvpGetCellPaged -> nt!CmQueryValueKey。
在 HvpGetCellPaged 中，通过 CellIndex 计算出的 Hmap 编号越界，导致取到的地址为 NULL，进而引发空指针访问。这与第二次崩溃属于同一类故障，都是由于读取了损坏的注册表结构。
二、 核心证据：SOFTWARE 配置单元异常膨胀
对比 9月24日和10月12日的两次转储数据：
- 9/24：
SOFTWARE 文件大小 93.5 MiB，已用空间 88.6 MiB，空闲空间仅 0.34 MiB。
- 10/12：
SOFTWARE 文件大小 100.0 MiB，已用空间 96.0 MiB，空闲空间 3.36 MiB。
18天内文件体积增长了约 6.5 MiB，且空闲空间占比极低。正常的 Windows 11 系统 SOFTWARE 文件通常在 20 到 50 MiB 之间。达到 100 MiB 且仍在快速增长，说明有程序在频繁向注册表写入数据或反复进行安装与卸载操作。当 Hive 空间耗尽或内部 Bin 结构不一致时，配置管理器就会分配或读取到非法的 Cell 地址，从而引发上述三次崩溃。
此外，三次转储中的 !blackboxbsd 显示的非正常关机 Boot ID 分别为 98、129、134，说明每次崩溃后都是强制断电或硬重启，这种非正常关机也会加剧注册表文件的损坏。
三、 系统中存在的其他风险点
除了注册表问题，内存转储中还反映出一些系统环境上的隐患：
1. 第三方驱动较多且部分存在异常
Ld9BoxSup.sys：雷电模拟器 9 的驱动，三次转储中均被加载。WinCPUoC64.sys 和 SWZoroHttps_amd64.sys：来自希沃（Seewo）服务目录，其中 WinCPUoC64.sys 在同一次崩溃中被加载了两次，存在逻辑异常。npf.sys：WinPcap 4.1.3 的驱动，时间戳为 2013 年，属于非常老旧的 NDIS 过滤驱动。wtd.sys：PE 时间戳非法，需要核查其来源和签名。- 其他如
hrdevmon.sys 等疑似火绒安全组件，以及 ViGEmBus.sys（虚拟手柄）等。
2. 系统状态与硬件环境
- Hyper-V 和 VBS（基于虚拟化的安全）处于开启状态，且系统组件版本存在不一致（如
nt 模块与 ahcache 模块版本不同），处于功能联机未完成状态。
- 硬件为希沃教学一体机，单条 8GB 内存（未组建双通道）。
- 驱动验证程序（Driver Verifier）未开启，无法自动捕获内存违规操作。
四、 排查与修复建议
针对上述分析，建议按以下顺序进行处理：
1. 定位注册表异常写入源并备份
在安全模式或 WinRE 环境下，先备份当前的注册表文件：
reg save "HKLM\SOFTWARE" D:\backup\SOFTWARE.hiv
reg save "HKLM\SYSTEM" D:\backup\SYSTEM.hiv
使用注册表编辑器或离线注册表工具加载备份文件，重点检查以下路径的子项数量，寻找异常增长的源头：
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallerHKLM\SOFTWARE\ClassesHKLM\SYSTEM\CurrentControlSet\Services
2. 清理或重建 SOFTWARE 配置单元
如果确认是特定软件导致的残留，可以手动清理上述路径。如果文件结构已经严重损坏，建议导出必要数据后重建该配置单元。需要注意，重建会导致第三方软件的注册信息丢失，相关软件需要重新安装或配置。
3. 检查磁盘与内存健康状态
注册表配置单元是磁盘文件，磁盘坏道会直接导致文件损坏。
chkdsk C: /f /r
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
同时建议运行 mdsched.exe 进行内存诊断，排除物理内存故障。
4. 清理第三方驱动环境
- 卸载或更新雷电模拟器，检查其驱动是否存在兼容性问题。
- 检查希沃相关服务，修复
WinCPUoC64.sys 重复加载的问题。
- 如果不需要抓包功能，建议卸载老旧的 WinPcap（
npf.sys），可替换为 Npcap。
- 使用
pnputil /enum-drivers 检查驱动存储库，清理不再使用的老旧第三方驱动包。
5. 调整系统设置
- 运行 Windows 更新，补齐系统补丁，确保组件版本一致，完成功能联机。
- 如果不需要使用虚拟机或特定的安全功能，可以考虑关闭 Hyper-V 和内核隔离（内存完整性），以减少底层驱动冲突的排查干扰。
- 如果问题依然存在，建议开启驱动验证程序（标准设置），并针对可疑的第三方驱动进行强制验证，以便在下次崩溃时直接定位违规驱动。
