很多人正确地指出了导致媒体播放时网络性能下降问题的根源在于多媒体类计划程序(MMCSS)，一项曾在Technet杂志上连续三期介绍的Vista内核新改变。多媒体播放需要媒体流具有一个稳定的速率，否则当要求达不到时播放就会出现“卡”的现象。MMCSS服务运行于服务宿主Svchost.exe 中，它自动提升音视频播放的优先级以防止其他软件过分占用播放软件应得到的CPU时间。

      当一个多媒体应用程序开始播放，多媒体API自动请求MMCSS服务在每10毫秒中的最多8毫秒时间将其播放线程的优先级提升至级别16-31的最高级 （Realtime），而这决定于播放线程需要多少CPU时间。由于其它线程运行在动态优先级15以下，就算是CPU占用相当大的应用程序都不会影响播放。

      你能够通过在WMP中播放一段音视频剪辑来看到这一变化。在播放时运行可靠性与性能监视器（perfmon.exe），选中性能监视器，在Thread对 象中对所有WMPlayer.exe的线程加入Priority Current选项。将图像范围调整至31（Windows中最高优先级）你就能够轻易看到被提升的线程，在这里是优先级21：

    不仅是其他线程的活动，媒体播放也能受到网络活动的影响。当一个数据包到达系统，触发一个CPU中断，将会使网络设备的驱动程序执行一个中断服务程序 （ISR）。其它设备的中断请求在ISR运行时将被阻止，因此ISR通常用于执行一些设备记录并且在一个DPC（Deferred Procedure Call）中进行一些在一个更长的数据传输。当DPC在中断启用的状态被执行，它们将无视优先级而优先于任何线程，因此可能对媒体播放线程造成冲击。

      而网络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_MACHINE\SYSTEM\CurrentControlSet\Services\Audiosrv\DependOnService

     将Windows Audio服务的依存服务选项中的MMCSS服务去掉，再禁止MMCSS服务，就能破解掉这一限制。