而网络DPC的处理要求几乎是最高的，因为它将把数据包传送至TCP/IP驱动，这需要长时间的计算才能完成。TCP/IP驱动校验每个数据包、确定每个 包使用的协议、更新连接状态、寻找接收应用程序，并将接收到的数据复制到应用程序的缓冲区内。这一个Process Explorer截图显示了当我将一个大文件复制到其它系统时，DPC的CPU占用率的上升。
在Vista开发时对MMCSS的测试中，发现即使增加线程优先级，大规模的网络传输也会使长时间运行的DPC影响到播放线程。因此MMCSS将会发送一条消息至NDIS驱动，使其每毫秒仅传输10个数据包(每秒1万个)。
标准以太网的帧大小大约为1500字节，1万个包每秒的限制使得速度被限制在15兆每秒左右。这对于百兆网络没有影响，但将会使千兆网络的性能下降到最大值的15%。
同时在NDIS的这段限制代码中，一个BUG将使得这种限制在多网卡的系统中放大。比如如果你有一台同时拥有有线和无线网卡的机器，这个限制将扩大到8000包/秒，而三块网卡时则进一步扩大到6000包/秒。这个限制此时在百兆网络上也显而易见。
我在我的3网卡笔记本上也发现了这一限制。在我向另一台机器复制文件的同时，我打开WMP播放音乐。任务管理器显示千兆网络的使用率从20%降低至6%。
你能通过在性能监视器视图的Network对象中添加“每秒接收数据包”来监视NDIS的数据包接收情况。下面你能看到我在实验中接收数据率的变化。NDIS处理的数据包数没有达到6000的“理论最大值”，可能是因为与对方机器进行的连接准备有关。
就算限制如此之大，Internet传输也不会受影响，因为多次中转远远降低了数据包的传输率。
Vista的这个限制来自在百兆网络上高传输率的同时达到低延迟流畅播放的实验结果。这个硬编码的限制是短视的，它忽略了今日多处理器系统和千兆网络普及的现状。现在Windows的网络开发组正和MMCSS组共同努力，开发一个补丁来应对此问题。
(译者评论：不是一个BUG，是一个功能。难道为了那该死的多媒体组件，就要牺牲网络性能?那些超高端的视频编辑系统，通过千兆网编辑文件服务器 上那些码率上百Mbps的低压缩率高清视频素材，这样一来不就“卡”到死了吗?再进一步说，如果Windows Server 2008正式版上这个MMCSS服务还是默认启用的，那么攻击者就有了一种新的Dos服务器的方法，只要他有服务器的一般用户权限，3389上去一放歌， 外面疯狂DDoS、CC，服务器的当机还会远吗?)
在评论中有人提出了解决方案：
修改注册表
HKEY_LOCAL_MacHINESYSTEMCurrentControlSetServicesAudiosrvDependOnService
将Windows Audio服务的依存服务选项中的MMCSS服务去掉，
再禁止MMCSS服务，就能破解掉这一限制。
标签：
