显卡：外接4060运行中掉链（GPU is lost）排查记录

外接 ASUS RTX 4060（OCuLink 显卡坞）在运行中会突然从 PCIe 总线消失，导致全屏黑；拔掉显卡坞的 DP 线把显示器改接核显后画面恢复，但外接卡要重启才会重新枚举。本文只记录外接卡自身这个问题（核显被连带打崩成 Code 43 是另一个独立问题，见文末关联）。

🔴 现象

• 外接卡可能开机后几分钟到十几分钟内任意时刻无前兆掉链，规律性不定
• 掉链后屏幕全黑（当时显示输出全在该卡上），显卡风扇仍在转
• 驱动自己给出的判词：GPU is lost. Reboot the system to recover this GPU
• 卡先变 CM_PROB_FAILED_POST_START（Code 43），随后从总线移除（CM_PROB_PHANTOM）；硬件重扫扫不回来，必须重启
• 核显会被连带打崩成 Code 43，需要用 pnputil /restart-device 单独救（见另一个笔记）

📅 死亡现场（精确到秒，2026-10-04 14:33 那次）

存活时长不定：同一天三次死亡，卡分别活了约 2 分钟、12 分 46 秒、更短 —— 不是固定倒计时，是随机间歇。

📊 临死前遥测（决定性负结果）

用 nvidia-smi 每秒轮询采到的临死前 2 分钟数据，全部正常，无任何前兆：

⇒ 卡是在「各项指标全部正常」的状态下，下一秒突然失去响应。这种无前兆的瞬间失联不是渐进劣化的形态。

✅ 已确认的硬件/软件环境事实

❌ 已排除的可能性（逐项实测，每行独立）

✅ 死亡后的连锁反应（实测顺序）

🔬 证据从哪里来（可复用的取证方法）

解 WATCHDOG 转储的 bugcheck（不需要 WinDbg）

LiveKernelReports 的 .dmp 是标准 DUMP_HEADER64，头部明文，用 Python struct 直接读：

import struct, glob, os
for f in sorted(glob.glob('C:/Windows/LiveKernelReports/WATCHDOG/*.dmp')):
    d = open(f, 'rb').read()
    bc = struct.unpack_from('<I', d, 0x38)[0]      # BugCheckCode
    p1,p2,p3,p4 = struct.unpack_from('<QQQQ', d, 0x40)
    print(os.path.basename(f), hex(bc), [hex(x) for x in (p1,p2,p3,p4)])

对照表：0x116 VIDEO_TDR_FAILURE、0x117 VIDEO_TDR_TIMEOUT_DETECTED、0x141 VIDEO_ENGINE_TIMEOUT_DETECTED。

查设备何时到位/何时消失（精确到秒）

Get-PnpDeviceProperty -InstanceId '<设备实例ID>' -KeyName DEVPKEY_Device_LastArrivalDate
Get-PnpDeviceProperty -InstanceId '<设备实例ID>' -KeyName DEVPKEY_Device_LastRemovalDate
Get-PnpDeviceProperty -InstanceId '<设备实例ID>' -KeyName DEVPKEY_Device_ProblemCode

轮询遥测等它死（脚本已就绪）

egpu-trace.ps1（位于 Hermes profile 的 scratch 目录）每秒采一次 nvidia-smi 遥测，设备失联即停并保留最后一条好数据。要点：

• 用 nvidia-smi --query-gpu=... --format=csv,noheader,nounits 轮询，不要用 Get-PnpDeviceProperty 轮询（CIM/WMI 极慢，实测单次 5~6 秒）
• 字段名要从富到简降级验证：nvidia-smi 只要有一个字段名非法就整条查询失败，会被误判成「设备掉了」
• 失联判定不能只看退出码：设备丢失时 nvidia-smi 可能仍返回 0 并给出文本 Unable to determine the device handle ... GPU is lost，必须同时匹配该文本

🎯 剩余可能性与判决实验

「无前兆、与负载/温度/电源/链路全部无关、存活时长不定」—— 只剩三个候选：

实验一（判决性）：把卡插到普通台式机 PCIe 槽

因为现在故障已高度可复现（十几分钟内必发），这个实验成本很低。

实验二（不用拆机）：限制功耗/频率看存活时长变化

nvidia-smi -pl <降低的功耗上限>
nvidia-smi -lgc <核心频率上限>

逻辑：若限制后存活时间显著变长甚至不再死 → 强烈指向供电侧问题（B 或 A 的 VRM）；若照旧随机死 → 更像瞬时接触/电气事件（C）。可逆（重启即还原）。

实验三（优先级最低）：隔离显示负载

不接显示器、只让卡挂着看是否照死。从今天数据看（占用仅 8~21%、温度 50°C）几乎可确定与显示负载无关。

📌 复发史

⚠️ 注意事项

• 不要把 /restart-device 用在这块卡上。实测：对已经 Code 43 的外接卡执行 pnputil /restart-device，结果是 Code 43 → Code 31 (CM_PROB_FAILED_ADD) → 硬件重扫后 CM_PROB_PHANTOM（直接掉出总线）。该命令只适合用在被连带打崩的核显上。
• 掉链后卡已经不在总线上，任何软件手段都救不回来（重扫不行），必须重启。
• OCuLink 不支持热插拔，插拔必须关机进行。

🔗 关联

本文只针对外接卡自身。核显被连带打崩成 Code 43 是另一个独立问题，见同目录下的《显卡：外接显卡掉链后核显报Code43的诊断与恢复》：