记录一次 PC 反复卡死诊断结项（2026-10-08）

既然 HL_DRY_RUN=1，蓝屏就不是故障，是等 Verifier 点名的预期行为。

今天把这台从 6 月到 10 月反复硬锁死的交易机收了个尾：硬件根因已经修掉，软件根因还在监控，剩下就是让 Driver Verifier 布防，等它自己指名。整个过程踩了不少 Windows 运维的坑，值得原样记下来。

一、主机与运行环境

这台机器 PC-20260408JPNQ 是 7x24 交易栈宿主，跟 craw_app1_wz 同机。核心配置：Intel Core i5-14600KF（Raptor Lake Refresh，Family6 Model183），Maxsun MS-Terminator B760M D5 主板，单条 16GB Asgard DDR5 内存，1TB NVMe 系统盘加 8TB SATA 数据盘，RTX 2080 Ti，Windows 11 26H2 build 26300.9457。上面跑着 defi_dashboard（Streamlit+MySQL+多个 python/node）、YunpanHub、Hermes agent、ollama、Steam，还有 WSL2。

交易栈已经确认 HL_DRY_RUN=1，日志里能看到 [DRY_RUN] open ETH LONG ... (skip HL order, log only)。主网链路可用但不下真单，这就决定了后面所有“可接受的停机/蓝屏”决策——反正不涉及真实仓位，机器多蓝屏几次也能接受。

二、故障表现

反复整机硬锁死，无蓝屏，从 2026-06 到 2026-10 一共 8 次。我用 EventLog 6008 还原了真实起点，不是看最后一次重启时间，而是逐条对强制重启记录：

锁死开始 强制重启 时长
10-03 04:55 10-07 19:15 4 天 14 小时
09-11 19:14 09-13 20:28 约 2 天
07-08 19:36 07-09 20:21 约 1 天
09-06 09:32 09-06 16:07 约 6.5 小时
06-12 04:26 06-12 10:20 约 6 小时
06-12 10:20 / 06-13 01:17 / 09-14 00:12 — 24-36 分钟

其中 10-03 那次最长，锁死接近 4 天半才被强制重启。而且后来发现 EventLog 6008 报的“7:24:22”其实滞后约 32 分钟，不能拿它当死亡时刻，真正的最后磁盘写入在 07:56:10。

三、根因 1（已修复）：Intel 13/14 代 V-Shift 未打补丁

这部分是硬件层面，证据链很硬。

决定性证据有三个：WHEA-Logger EventID 3 的时间戳与每次锁死秒级吻合，解开 CPER 原始二进制后看到 Severity=0x00000003=Fatal，SectionType 是处理器通用错误节，Creator 为固件 GUID；Kernel-Processor-Power ID 37 固件限频，60 天 124 条，只出现在逻辑处理器 15/19（E-core），报文里写着“自上次报告以来已处于该低性能状态 86399 秒”，就是连续 24 小时；微码还是 0x104，BIOS 版本 E1.5D（2024-08-13），早于 Intel 全部修复微码（0x129B 2024-08、0x12B 2024-09-24、0x12F 2025-06-24）。而且 14600KF 官方规格 DDR5-5600，实际内存跑 6400 XMP 超频。

修复动作：BIOS 升到 E2.6D（2026-03-11），微码从 0x104 升到 0x133。

结果：WHEA 归零，固件限频归零，CPU 频率从 3140 MHz 恢复到 3500 MHz 满额。唯一一次真蓝屏（06-13 BugcheckCode=26 / 0x1A MEMORY_MANAGEMENT）也消失了。这部分可以结案。

四、根因 2（性质不同，仍在监控）：软件/驱动层挂死

10-08 07:56 又锁死 7 小时，但这次全程零硬件签名：WHEA=0、限频=0、CPU 满频、无磁盘/NTFS/显卡 TDR 错误，所以判定为软件/驱动级硬挂死，不是硬件。

死前机器并不空闲：交易栈满负荷，4 个 python + 5 个 node + mysqld + Steam 下载同时在跑。shadow_logs\sm_trader_mainnet.log 最后一次写入是 07:53:35，smart_money_oos.db 是 07:54:26，E:\yunpan_hub\server_stdout.log 是 07:56:10，然后机器就没了。

已排除的伪线索，这几个坑要避免重复劳动：

  • ConnectedStandbyInProgress=true 不是唤醒路径证据。这个位是电源管理器残留状态位：SystemSleepTransitionsToOn=0，固件明确不支持 S0ix（powercfg /a 报“系统固件不支持此待机状态”），Hypervisor 又额外屏蔽待机。181 天日志内 Kernel-Power 506/507=0、42=0、107=0、powercfg /lastwake=0。而且该位在 10-08 为 true，在 10-07 为 false，与是否真睡眠反相关——唯一真发生睡眠转换的 06-12 10:56，该位反而是 false。
  • RAM 降频不是决定性因素：XMP 已关，跑 4800 MT/s @1100mV，降频合理，但本次故障本来就没有硬件签名可修。
  • GameViewer (UU远程) 的 Kernel-PnP 219 是无害噪声。ROOT\DISPLAY\0000 的 ProblemCode=0、Status=Started，219 事件数与开机次数严格 1:1（10-07 9/9、09-13 5/5），是 IDD 虚拟显示设备的 UMDF 生命周期产物，不要卸载。

驱动栈隐患还没处理，等 Verifier 定位完成后再动：

  • 360Sensor_DM64.sys —— 360 安全卫士已经卸载干净（0 注册表项/0 进程/无程序目录），但驱动仍 Running + Auto 开机加载，版本 2022/10/11，签名证书 2023-02-04 已过期。
  • xlwfp.sys —— 迅雷目录 C:\Program Files (x86)\Thunder Network 已不存在，但 WFP 过滤驱动仍 Running+Auto；XLServicePlatform 服务 StartMode=Auto 但每次开机 45 秒启动超时（7000/7009），Thunder 自启项指向已删除路径。
  • 网络隧道/过滤 6 层并存：Tailscale+wintun、Clash for Windows(7890)、XLWFP、vwififlt/vwifimp、NeSigVerify(网易,System 启动)、cpolar(4040/6060/9200)、UU远程。
  • 非分页池 514 MB（健康值 100-250），6 次采样持平，属于非活跃泄漏，是驱动存量负担。
  • 运行中驱动 199 个（健康 150-180），含 boot-start 的 ACE-BOOT.sys（WeGame 反作弊）。
  • MSI Afterburner 4.6.7 Beta + RTSS 7.3.7 已安装但未运行。NVIDIA 驱动 10-07 刚升到 610.88，RTSS Beta + 新驱动是经典不兼容组合，这算埋雷。

五、当前状态：Verifier 已布防，等它指名

现在系统已经配好完整转储：

1
2
3
4
5
CrashDumpEnabled=1  AutoReboot=1  AlwaysKeepMemoryDump=1
页面文件 C:\pagefile.sys 32768 MB 固定 (生效值已确认, 需求 16225MB, 余量 16543MB)
本次开机 Event 49 = 0
Verifier Flags=0x001209bb  Boot Mode=Persistent  已验证 6/6:
  360Sensor_DM64.sys  xlwfp.sys  dokan2.sys  NeSigVerify.sys  wintun.sys  IndirectKmd.sys

选中这 6 个驱动后，系统自动追加了 WDF verification 和 File system filter verification 规则类。

蓝屏是预期行为不是故障。 蓝屏后第一时间要抢在完整转储被覆写之前拷出来：

1
2
Copy-Item C:\Windows\MEMORY.DMP E:\reroot\MEMORY.DMP -Force
& "E:\reroot\分析转储.ps1" -Dump "E:\reroot\MEMORY.DMP"

蓝屏码释义：0xC4 是 DRIVER_VERIFIER_DETECTED_VIOLATION，验证器直接点名，最理想；0xD1/0x7E 的参数2 是出错驱动指令地址；0x50 参数3 是出错驱动地址。内核转储不含可直接读的模块列表，精确定位要用 WinDbg !analyze -v。

工具脚本都在 E:\reroot\ 下：卡死诊断采集.ps1 导出 WHEA/6008/41/固件限频证据，分析转储.ps1 解析 minidump + 32/64 位内核转储，修复卡死-管理员运行.ps1 是 A 方案（清残留/页面文件），但定位完成前勿跑。Verifier 的布防脚本是 ~\.hermes\hermes-agent\apply_verifier.ps1，回滚是 verifier_off.cmd，页面文件 32GB 是 fix_pagefile.ps1。

回滚命令（管理员，安全模式或正常模式均可）：
& "C:\Users\Administrator\.hermes\hermes-agent\verifier_off.cmd"

如果连续 3 次开机即蓝屏，就进 WinRE -> 启动设置 -> 安全模式执行同命令。

六、复盘：工具/API 陷阱（复用价值高）

这次在 Windows 运维上踩了 5 次坑，全部同一个模式：凭印象写操作代码，没先验证。

  1. .cmd 里 chcp 65001 会破坏 cmd.exe 解析 —— 切代码页后文件指针与字符宽度失配，后续每行开头被吃掉（'et'←reset、'EM'←REM）。中文注释 + chcp 混用必炸。对策：批处理改用 .ps1；.cmd 只留纯 ASCII 启动器。
  2. verifier /adddriver 子命令不存在 —— 持久化形式只有 verifier /standard /driver <镜像名>；/adddriver 仅存在于 /volatile。/driver 要传镜像名（xlwfp.sys）不是路径。判别法：/volatile /adddriver 报 "Access is denied" = 语法对；报 "unsupported parameter" = 语法错。
  3. verifier 返回码 2 = 设置成功需重启，不是错误。返回 0 = 无需重启。
  4. Win32_PageFileSetting 是设置意图，Win32_PageFileUsage.AllocatedBaseSize 才是生效值。 New-CimInstance -ClassName Win32_PageFileSetting -Property @{InitialSize=...} 会报 HRESULT 0x80041005（类型不匹配），需 -ClientOnly + 显式 [uint32]，或直接写注册表 PagingFiles（MultiString 类型）。绝不可先 Remove 再 New —— 之前一个版本的脚本就是这么把页面文件配置清空的。
  5. Test-Path 查注册表【值】必然返回 False（Registry provider 下查的是子项）。正确查法：(Get-Item $k).GetValueNames() / GetValueKind() / GetValue()。另外，**验证 Event 是否为本次开机产生必须带 StartTime=LastBootUpTime**，-MaxEvents 1 会返回历史旧记录造成假阴性。

七、安全侧附带发现（与卡死无关，建议后续处理）

排查过程中顺手发现几个裸露面：0.0.0.0:3306 的 mysqld 绑所有接口，而 start-defi-dashboard.bat 里 root 密码为空（password=''）；还有 0.0.0.0:80 httpd(WampServer)、0.0.0.0:3389 远程桌面、cpolar 内网穿透 3 端口。等于数据库对内网裸奔。

下一步

等 Verifier 触发蓝屏，拿到 MEMORY.DMP 后跑 分析转储.ps1。如果定位到具体驱动，再决定是清残留还是更新签名；定位完成前不碰 修复卡死-管理员运行.ps1，也不动那批驱动栈隐患。安全侧那几个端口和空密码，等这轮蓝屏定位结束后再单独处理。