DPC 看门狗超时导致桌面冻结

记录一次 Windows 卡死排查记录：DPC 看门狗超时导致桌面冻结

问题现象

这个问题其实不止发生过一次，大概之前也有过几次，机器突然完全卡死，只有一次好像是过了一段很长的时间后就好了。具体表现：

屏幕画面冻结在最后一帧，不是黑屏，刚开始可能可以调用一些窗口，但是一旦操作就不行了，之后可能过好几分钟会突然动一次，然后又不行了；
鼠标可以正常移动，键盘 CapsLock 灯按了会亮，打字有时候也有反馈；
Ctrl+Alt+Del、Ctrl+Shift+Esc 调任务管理器、Win+Ctrl+Shift+B 重置显卡，全部没有反应；
超过20分钟无任何效果之后，我只能长按电源键强制重启。

正好今天上午又发生了，这对于我来说非常难受，明明是可以移动鼠标键盘的，所以我这次想要认真排查一下。（之前也用过豆包，但好像不行，所以这次我决定使用 Agent 来协助调查，并且我觉得这个是有记录意义的一件事情：符合由人类主导+AI执行的一个最佳实践）

以下内容是通过 Hy3 协同调查 Windows 卡死原因的产物，仅供参考

排查过程

第一步，看系统事件日志

系统日志里有一条 Kernel-Power 的 Event 41，BugcheckCode 为 0。这说明上次不是正常关机，也不是蓝屏崩溃，而是被人强制断电，和“只能长按电源重启”能对上。不过 Event 41 本身不告诉我们卡死原因，只是确认了“是被硬关机的”。

第二步，找到看门狗转储文件

Windows 在内核检测到严重卡死时，会在 C:\Windows\LiveKernelReports\WATCHDOG\ 目录留下转储文件。我在里面找到了当天 09:11 生成的两个文件：WATCHDOG-20260823-0911.dmp 和 WATCHDOG4400-20260823-0911.dmp。

落在这个目录，说明是 DPC 看门狗违例：某个内核驱动在 DPC/中断里占用 CPU 太久，系统线程被全部卡住，画面因此冻住；但鼠标和键盘灯走的是硬件中断，所以还活着。

这也解释了为什么 Ctrl+Alt+Del 都进不去。那条命令要走系统线程，而系统线程已经被占死了。

第三步，用 WinDbg 做符号化分析

把转储文件交给 WinDbg 跑 !analyze -v，得到的关键信息：

BugCheck 1A8，参数 {1,0,0,0}
出问题的进程是 dwm.exe（桌面窗口管理器）
栈顶是 watchdog 的超时报告回调

也就是说，卡死发生在 DWM 的图形合成路径上，是被看门狗抓到的。

补充一句：0x1A8 在旧版 WinDbg 里会被误报成内存损坏，实际并不是内存条的问题，这个误报要排除掉。

第四步，看冻结瞬间内核里都加载了哪些驱动

进一步列出故障时刻的已加载内核模块，重点嫌疑集中在图形路径上：

nvlddmkm.sys：NVIDIA 独立显卡驱动
dxgkrnl.sys / dxgmms2.sys：显卡内核栈
OrayVGC.sys：向日葵（贝锐）的虚拟显卡驱动
360FsFlt.sys / 360qpesv64.sys 等：360 的文件过滤驱动
AliPaladinEx64、DsArk64：阿里和另一款安全过滤驱动

这里最关键的发现是 OrayVGC.sys。它是向日葵往系统里插的一个虚拟显卡驱动，会在内核里常驻，直接叠在 NVIDIA 驱动和 DWM 的同一图形 DPC 路径上。虚拟显卡驱动和真实显卡驱动抢同一条中断链，很容易把 DPC 看门狗触发，把 DWM 一起焊死。

另外这台机器同时堆了 360、阿里、DsArk 等多层文件过滤驱动（约十几个 360 内核模块常驻），每次磁盘 I/O 都要逐层扫描。而当时 C 盘 150G 只剩 10G 出头（约 93% 满），磁盘一旦繁忙，小卡顿很容易被放大成死锁。这些虽然不是直接原因，但都是放大器。

结论

这次卡死的根因，是向日葵的虚拟显卡驱动（OrayVGC.sys）常驻内核，和 NVIDIA 显卡驱动在图形 DPC 路径上冲突，触发 DPC 看门狗超时，把桌面窗口管理器（DWM）冻结，整个系统因此失去响应。360 的多层文件过滤驱动和 C 盘空间严重不足，是让问题更容易发生的放大器。

说明一下置信度：这两个 WATCHDOG 转储是轻量的分诊转储，只保存了看门狗自己的现场，不包含其他处理器卡死瞬间的完整调用栈，所以上面是基于实锤证据的强归因，还差一步才能字面定稿。要完全坐实，可以在下次再卡的时候开启注册表的 CrashOnCtrlScroll，按右 Ctrl + ScrollLock 两次逼出一个完整内核转储，再用 WinDbg 看所有处理器的栈，就能直接点名是哪一行代码。

处理建议

按性价比排序：

停用或卸载向日葵的虚拟显卡驱动（OrayVGC）。不远程时直接退出向日葵，并在设备管理器里禁用“向日葵虚拟显卡”。这是最直接的一步。
精简 360 的文件过滤层，临时关闭实时扫描做对照测试。
用 DDU 彻底卸载后重装 NVIDIA 显卡驱动。
把 C 盘从 10G 出头腾到 20G~30G 以上。

奚叔2099：直接卸载向日葵！！！

然后令我意外的是，彻底卸载向日葵内核驱动也是一个踩坑记录……

当通过软件管家把向日葵卸掉之后，我也以为干净了。结果又发生了类似的情况。

复查才搞明白问题出在哪：向日葵的虚拟显卡驱动 OrayVGC.sys，根本不在“应用”那一层的管辖范围里。软件管家卸载的是用户态的程序，而 OrayVGC 是一个内核驱动，有自己的服务注册项，开机自启、常驻内核。应用卸了，它还在 C:\Windows\system32\drivers\ 里躺着，内核里 State=Running、StartMode=System，每次开机照常自动加载。

软件管家卸载的是程序，内核驱动是系统组件，两者不是同一个卸载入口，下面是把这个残留驱动彻底清理干净的实际步骤。

操作步骤

确认驱动是否还在
以管理员身份打开命令提示符，执行：
1
sc query OrayVGC
如果返回 STATE : RUNNING 或 START_TYPE : SYSTEM，说明它还在。
禁用自启并删除服务注册项
1
2
sc config OrayVGC start= disabled
sc delete OrayVGC
sc delete 删的是服务注册表项，删完重启就不会再自动加载。注意这一步删不掉正在运行的实例本身，也删不掉磁盘上的 .sys 文件。
重启
这一步必须做。sc stop 对内核驱动通常是无效的（会报 1052 控件错误，属正常限制），只能靠重启让内存里的旧实例退场、释放对 .sys 文件的占用。
重启后确认已不再加载
1
sc query OrayVGC
正常应返回 1060 指定的服务未安装。再确认 C:\Windows\system32\drivers\OrayVGC.sys 确实还在磁盘上（待删）。
删除残留的 .sys 文件
直接删除很可能失败，因为这个文件归 TrustedInstaller 所有，即使管理员也没有直接删除权限。需要先夺取所有权：
1
2
3
takeown /f C:\Windows\system32\drivers\OrayVGC.sys
icacls C:\Windows\system32\drivers\OrayVGC.sys /grant Administrators:F
del C:\Windows\system32\drivers\OrayVGC.sys
拿回所有权、赋权之后就能删了。
顺手清理 OrayUSBVHCI（可选）
向日葵还有一个 USB 重定向驱动 OrayUSBVHCI.sys，同样可能残留。它是按需启动、默认停止，正常不会自启，但既然都清到这儿了，可以按上面同样的 sc delete + takeown + icacls + 删除文件流程一并处理掉。