PC 使用时偶发卡顿 3-5 秒

[Shino]

高负载和低负载场景都有出现，发生时画面通常会卡住，偶尔黑屏，音频有时是卡住变成噪音，有时是变为慢放，卡顿结束后迅速恢复正常，不会蓝屏，不会短时间连续发生。

因为是光污染散热，温度都是可视化的，初步排除散热问题，事件查看器里也没找到任何疑似元凶，求教该如何排障。

主板 MS-7B45
CPU 8086K
RAM 影驰 DDR4 4000 8Gx2
硬盘 主：SanDisk SDSSDHII-120G | 从：ST5000NM0024+Optane32G / ST4000DM000 / WD10EALX-009BA0
PSU EVGA 650P2

[Shino]

@Actrace 这套机器是放在办公室的，和我们这的网络中心是同一套供电，电压不稳的几率应该比较小......一会借个在线式 UPS 试试。

[MinonHeart]

关闭游戏模式。有可能是显驱问题

[watch]

win10 下 ssd 加 hdd 假死的案例太多了 反正基本都是硬盘的锅

[ccnccy]

一般是电源问题

[qiuai]

我的电脑也有这个情况,然后比你这个还要复杂一点,我的工作文件都在局域网的其他机器上,开机正常,第二天或者更久一点的时间以后,会出现一个情况,只要访问局域网的机器,看个视频或者下载个文件,会巨卡无比.传输速度不大于 10Mbps.打开个带视频的 chrome 标签页也会卡的不行.但是如果不操作局域网机器,不看视频.又完全没问题....
唯一的解决方法就是重启电脑.重启后效果立竿见影,马上就好了........

[jedihy]

什么系统版本？
这个现象一般是 DPC starvation 造成的。不熟悉驱动开发的话，还是重装不同版本系统来解决吧。

[jedihy]

@jasonyang9 Win 的有中断优先级，内核里面很多 routine 是通过 DPC 执行的，DPC 工作时，中断优先级（ irql) 处于 Dispatch Level，用户程序以及系统 UI 都是 Passive Level。更重要的是 thread scheduler 也是 Dispatch Level，所以一旦内核有 DPC routine 执行的时候，当前逻辑 CPU 内的其他线程无法得到调度，因为 thread scheduler 自己就已经被抢占了。

[jedihy]

@jasonyang9 补充，同 IRQL 的 routine 不能互相抢占，所以一旦有一个 DPC 抢占了 Passive Level 的用户线程，这个 CPU 上的其他线程就要等这个 DPC 完成了才能被调度，因为 thread scheduler 无法抢占同优先级的 DPC。

[MorHop]

LatencyMon?

[jasonyang9]

@jedihy 多谢，本人只是学了一点皮毛。

1、那应该如何调试才能知道是哪个中断导致了这些 Passive Level 的进程被抢占？
2、另外，系统 UI 也是 Passive Level，那是不是说当这个抢占发生时，鼠标指针是无法移动的？鼠标指针的绘制是否属于系统 UI ？

[xuc]

我以前遇到过类似情况，排查后发现是最新的网卡驱动问题

[Kagari]

D 盘是机械盘吗，是的话切一小块 C 盘出来然后占住 D 盘的盘符。反正没效果也可以再合并回去，没啥损失

[jedihy]

@jasonyang9
1. https://blogs.msdn.microsoft.com/ntdebugging/2008/04/03/windows-performance-toolkit-xperf/
一般很少针对某个 app 来看抢占情况，都是 profile 整个系统。
2. 在多核处理器里面这个不是一定的，如果 UI 正好和 DPC 在同一个核，那么就会被抢占，抢占的时候鼠标是无法移动的。用户的反应一般是移动不平滑了，鼠标绘制这些都是系统 UI。系统 UI 的线程模型我不了解，如果 pin 到一个核上，那么该核上的 DPC 一定会导致 UI 卡死。

[iwtbauh]

@jasonyang9

内核是没有卡死，但是可能图形服务器卡死了，所以给你造成长“系统卡死”这种假象。

这个时候使用内核的某些紧急措施你会发现还是有效的。比如 windows 的内核调试（需要连接串口到调试机），Linux 的 sysrq 魔法按键等等