A Second Shot: Windows Vista SP1

What’s Fixed In SP1

Bug fixes are a big part of any Microsoft service pack, but not just for the bugs being fixed specifically by the service pack. Microsoft has released numerous hotfixes since Vista launched, correcting a number of issues declared significant enough that they need to be fixed before the next service pack, but minor enough that they’re not worth a full deployment and the kind of massive regression testing that entails. The result is that there are a number hotfixes already out that can potentially fix specific issues certain users are having, but because they aren’t well-tested they’re instead well-hidden with only a small number of users with extreme problems usually getting their hands on any given hotfix. Now that a service pack has arrived, Microsoft has rolled up all of these hotfixes into the service pack, in essence approving them for wide release and full support.

Among the 24 pages(!) of hotfixes that have been rolled into Vista SP1 are favorites such as the virtual address space fix and a fix for a conflict with NVIDIA’s USB controller and >2GB of RAM. Other additions include fixes for ejecting iPods, a fix for HybridSLI/HybridCrossfire (which is why the launch of these technologies is tied to SP1), and a fix for AMD Barcelona processors causing system reboots during Windows installations. While we could rattle off the entire 24 page list of hotfixes, the important thing to note here is that there are a number of small issues that have been “fixed” prior to SP1 but are only now being widely corrected. We’re going to spend most of our time going over the biggest and most noticeable fixes in SP1, but please keep in mind there are many more things addressed in this service pack than what we’re looking at today or are listed in Microsoft’s consumer-level product literature.

Among the most significant fixes to Vista in SP1 is Microsoft's work on further refining the User Account Control (UAC) prompts of Vista. Even after already being scaled down between the betas and Vista’s launch, these prompts are still rather prolific at times. An adjustment to the folder creation is the most prominently touted of these fixes, with the number of folder creation prompts (when creating a folder in a protected location) falling from four to one. Microsoft doesn’t list any further reductions in UAC dialogs, but as far as anecdotal evidence is concerned it certainly feels like they’ve done a bit more than that. This won’t change the public perception of UAC (or Apple jokes on the subject), but any reduction is welcome and perhaps will stem the tide of Vista users who are completely turning off this critical system feature.

Another significant fix appearing in SP1 is a partial resolution to the conflict between the MultiMedia Class Scheduler Service and networking. As we’ve talked about the issue a bit before, the Vista audio stack is now in user space, which has lead to a change in how it operates. MMCSS boosts the priority of multimedia processes to real-time levels so that lower-priority processes can’t interrupt multimedia playback. During this time many other operations are interrupted or delayed so that they do not themselves interrupt the audio stack. One area that is dialed back involves the network interfaces, which are limited to 10k packets per second as a precaution.

For SP1 we were hoping for a complete overhaul of the MMCSS so that it ceased adversely affecting network performance, unfortunately what we’re getting is something about mid-way towards that. With SP1 it is now possible to control the amount of network throttling that MMCSS does, which means that throttling hasn’t been removed completely nor has it even been adjusted as far as the defaults are concerned. A quick test with Microsoft’s NTttcp tool shows the throttling level remains the same post-SP1 as it was pre-SP1 (roughly 70Mbps on a 1000Mb connection), which means SP1 will not be bringing any immediate relief. Furthermore there’s no GUI component (or real documentation) for this tweak, so users will be left to directly modifying the registry, a very uninviting situation.

What we do know is that this tweak only affects network receive performance, with a key apparently dictating the maximum percentage of the amount of network traffic allowed while the MMCSS is actively working. The key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\NetworkThrottlingIndex

...defaults to 10 (for 10%) and can be adjusted to between 1 and 100, with the system requiring a reboot between adjustments. We did some quick testing with this key and were easily able to set it to 70%, which got us around 550Mbps of bandwidth through NTttcp, and we probably could have gone higher - especially on multi-core platforms.

Default throttling (top) and throttling with an index value of 70 (bottom)

While this is a solution to the MMCSS throttling issue, it’s not a good solution. The default value still makes for rather anemic performance on gigabit networks and the nature of the solution means that there is no single correct value to use to maximize network performance while not interrupting the audio stack; the highest value is highly dependent on processor performance. As a result power users wanting to correct this deficiency will have to a lot of experimenting on their own to find the highest value their system can tolerate without affecting multimedia playback. Had this value at least been auto-sensing we wouldn’t be so disappointed in Microsoft, but at the end of the day this isn’t a great solution. We’ll fully admit the problem will only affect a small number of users (those with gigabit networks who need high network performance while using multimedia applications), but then we’re exactly that kind of user.

For what it’s worth, we did inadvertently discover that the MMCSS throttling process doesn’t engage when audio streams are using APIs other than WaveOut and DirectSound (i.e. aren’t directly routed through the user-mode audio stack). OpenAL and ASIO do not trigger throttling, which means it’s possible to have both unthrottled networking and proper multimedia playback under Vista, as long as there’s hardware present that can deal with these APIs. This may very well be good news for Creative Labs in particular, whose DirectSound-to-OpenAL “Alchemy” wrapper can be used to have DirectSound applications routed to OpenAL instead and preventing throttling.

Moving on, SP1 also introduces a few interesting fixes for the user experience. For anyone who has a system running a 32-bit version of Windows and 4GB of RAM, they will be well aware that in 32-bit mode not all of that RAM can be addressed, and that Windows reports the amount that can be addressed accordingly. With Vista SP1 Windows will now be reporting the amount of RAM in the system, and not the amount that can be addressed. The advantage of this is that it will reduce the number of computer owners thinking something is wrong because Windows doesn’t “see” all of their RAM; on the other hand this is clearly disadvantageous because they will no longer be informed that Windows in fact isn’t using all of their RAM, nor will there be an easy way any longer to tell how much RAM it is capable of using.

Another user experience change with SP1 is that password hints are no longer optional when accounts are being created. It turns out that OEMs were complaining to Microsoft that users were forgetting their passwords and had no easy way to recover control of their computer since the Administrator account is no longer active by default, so Microsoft has done something about it. Password hints are now mandatory for all user accounts so that forgetful users are less likely to forget their passwords. How that will affect people that then forget what their hints mean remains to be seen.