自从更新win10 1903之后（证明不是1903的锅），下载东西总是会导致鼠标卡顿，而且网速也上不去，在大流量时特别明显，下面附上自己的一些分析

场景复现:

当win10下载时或者测速时（IDM，迅雷，百度网盘，测速软件），只要流量到达某个值（未到达带宽最大值），便不会继续上升，而且鼠标移动会卡顿，音乐也会出现卡顿的情况。

考虑到软件比较多，而且不方便重做系统，下面便开始分析。

找遍了网上几乎所有的解决方案，包括关闭杀毒，关闭Windows Defender，关闭沙盒虚拟机（这个的确是有可能引起卡顿，但是这里情况不适用）等等，尝试把网卡的所有减负功能都关闭，发现也无效，关闭HPET，还是不管用，打开任务管理器，CPU占用30%，内存占用15%，硬盘占用2%，网卡占用30%，显卡占用0%

问题分析

考虑到鼠标和声卡同时卡顿，且系统资源占用较低，推测可能是有程序系统中断优先级比鼠标和声卡要高，便打开任务管理器，发现30%的CPU占用竟然有接近25%是系统中断引起。
系统中断参考资料: https://blog.csdn.net/zxh2075/article/details/78262568

找到了问题可能所在的地方，便开始检查，参考网上大神的教程，下载DPC Latency Checker，启动后和跑大流量后系统中断完全不是一个级别。
（因为怕卡顿无法截屏所以做了限速。。）

基本确认是系统中断的问题，那么是什么东西引起的呢？

下载LatencyMon，查找DPC计数高的设备。

查找资料中.. 稍等回来更新

---------------20190715 3:20 ----------------------------
困。。。

无意间发现LatencyMon中有total execution，发现是一个名为NDIS.sys的文件占用时间最长，猜测可不可能是这个文件导致的？
跑大流量的时候发现这个占用时间的确是暴增，那就可能是他了，从他下手。

NDIS是Network Driver Interface Specification，即网络驱动接口规范。NDIS的主要目的就 是为NIC（网络接口卡，Network Interface Cards）制定出标准的API接口。MAC（介质访问控制，Media Access Controller）设备驱动封装了所有的NIC硬件 实现，这样一来所有的使用相同介质的NIC就可以通过通用的编程接口被访问。 NDIS同时也提供一个函数库（有时也称作wrapper），这个库中的函数可以被MAC驱动调用，也可以被高层的协议（例如TCP/IP）驱动调用。这些wrapper函数使得MAC驱动和协议驱动的开发变得更加容易。

附上通过某404站找到的一份关于NDIS.sys导致蓝屏的文章，里面也粗略介绍了一下NDIS.sys

https://www.auslogics.com/en/articles/fix-ndis-sys-blue-screen-error-windows/

推测 会不会是因为网卡驱动导致或者其他程序与网卡驱动冲突导致的？

然后便开始了漫长的设备禁用之旅，从网卡设备开始。。
慢慢的，能禁用的都禁用了，只有现在正在用的killer网卡没禁用了，因为还要上网找资料，就先放着吧。
然后猜测会不会是killer网卡驱动导致的？ killer驱动可是给我背了不止一次锅了。（上次驱动有问题导致最大网速跑不过200Mbps，让我千兆网情何以堪啊。。）
考虑到为了方便测试，先开了个虚拟机跑了下大流量，发现能跑满。。而且不会出现这种情况
看样问题就是killer网卡的驱动了。

解决步骤

换用usb网卡，问题圆满解决。

小结&感想

问题往往都在想不到的地方，，查问题尽可能查到每个部分。
killer网卡真的驱动做的烂的一批

就这样 问题算是暂时解决，具体原因还在追踪中。
具体的那些东西，恐怕只有厂商知道了吧=.= 不过螃蟹卡的芯片的处理能力真的不敢恭维。千兆跑到最高800Mbps就不行了。

-------------------20190715 4:00更新--------------------
解决方案: 不要更新killer网卡的驱动，设备管理器卸载设备，选择删除此设备的驱动程序软件，然后重新发现下设备（重启后再点击上面的扫描检测硬件设备按钮都可以），使用win10自带的killer驱动，问题圆满解决。
killer还真是个不省心的东西。
正在使用的网卡:Killer E2400

-------------------20190716 12:00更新---------------------

问题貌似并没有解决

别着急走啊，下面还有分析呢。

-----------------20190717 5：43更新--------------------

经过一晚上的艰苦奋战，源头几乎找出来了，这里也不明确指明是什么厂商的软件了，懂得自然懂。

过程:

各种爬x找资料，发现国外站点类似的问题还不少，无意间了解到了Windows Software Development Kit (SDK)中有个性能分析工具，并简单了解了下用法。

食用方法:

1.先安装软件包，安装的时候只选Windows Performance Toolkit feature，其他都不勾选
2.安装完成后以管理员方式运行cmd，并输入xperf -on PROC_THREAD+LOADER+PROFILE+INTERRUPT+DPC+DRIVERS+POWER+IDLE_STATES -stackwalk Profile -BufferSize 1024 -MinBuffers 256 -MaxBuffers 256 -MaxFile 256 -FileMode Circular

3.进行一些让你感觉到卡顿的步骤（比如说跑个某雷）

这里补充一些东西，如果运行后出现xperf: warning: This system is not fully configured for x64 stack tracing，执行下列 命令
xperf -stop  ->停止追踪
REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management" -v DisablePagingExecutive -d 0x1 -t REG_DWORD -f     ->禁用分页执行

如果运行后出现xperf: error: NT Kernel Logger: A device attached to the system is not functioning. (0x1f)，则执行下列命令
verifier /reset    ->禁用Driver Verifier（这是个神奇的东西），然后重启电脑。

如果运行后出现xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7)，就检查下有没有影响捕捉ETW数据的软件把，比如说上面提到的LatencyMon，杀毒软件，如果这些结束了还不行，那就任务管理器把资源管理器（explorer)k一下把。

4.问题复现后，再次在以管理员权限运行的cmd中执行下列命令结束捕获
xperf -stop -d C:\CPU.etl

此时在C盘根目录应该生成了CPU.etl，双击 会自动用Windows Performance Analyzer打开。
打开后，当我刚看到这些图的时候，其实我是拒绝的。
但是仔细看看其实也没啥。如果想玩的可以自己玩玩，挺好玩的。不想玩的或者玩够的请看下列步骤:

展开CPU Usage（Sampled），双击DPC and ISR Usage By Module，Stack，此时在右面应该出现图形。

在图形中选择Weight最高的一项，慢慢向下展开，只展开最高的一项即可。

可以看到产生问题的原因了，至于下面的内核进程为什么也占用这么多时间，可能是被拖累把。 看第一个不知道是啥的系统文件，这个是啥，懂的自然会懂。在这个系统文件的根节点下继续展开能看到他调用的Stack。

这个文件为啥要这么做就不清楚了，也希望大家能多多思考下。

解决方案(final)

找到这个sys文件删了就可以了。

具体这个sys怎么来的还不清楚，反正以前因为蓝屏原因删过这个文件。但是不知道什么软件带进来了

解决后测试

完美解决。某厂商我也不想说什么了。

原因分析（final）

考虑到涉及到DPC，加上自己并不是真的很了解，就不放出自己的思考了。不过这里有一篇文章，感兴趣的可以看看，学习下，根据这里面的基本能推出来原因
https://blog.csdn.net/shenjin_s/article/details/82781397