Fix that Addresses Issues with SVCHOST.EXE and Windows Update / Microsoft Update

Just received the following that is related to the SVCHOST issues that I've written about in the past...

MS has released "Microsoft Security Advisory (927891) - Fix for Windows Installer (MSI)" that's not really a direct security concern, but actually addresses concerns that might prevent people from getting critical security or other updates.

As previously mentioned, it involves MS KB 927891 - "You receive an access violation error and the system may appear to become unresponsive when you try to install an update from Windows Update or from Microsoft Update", and the current revision of the article (8.0) states "This fix is one component of a two-part fix that includes a Windows Update client software update. These updates will be deployed automatically using Windows Update in May 2007 and June 2007."

Again, this update is one of two that need to be applied to fully address the issue. The other update is version 3.0 of the Windows Update Client Software, available from MS KB 932494, "When you use Automatic Updates to scan for updates or to apply updates to applications that use Windows Installer, you experience issues that involve the Svchost.exe process".

One can also hope that this will help address the 0x8ddd0009 problems that MANY have been experiencing...



Reading List

Initially, I was going to start off by saying that I've been reading more books and less content online, but that wouldn't be accurate. I've actually picked up more online reading, but I'm also more frequently finding myself with a good book in hand before bed. Currently, I'm finding my way through Eldad Eilam's Reversing: Secrets of Reverse Engineering. It's a good read so far and I hope to learn a lot.

I've ALWAYS got Russinovich & Solomon's Windows Internals open, and I've been through it cover to cover a few times as well. There's just so much good stuff there, and I've got a memory like a goldfish... =8->

Recently, I also read Hoglund and Butler's Rootkits: Subverting the Windows Kernel for the second time. The chapter on DKOM is probably my favorite.

I just finished Raymond Chen's The Old New Thing: Practical Development Throughout the Evolution of Windows. The anecdotes range from light to heavy, and the lessons to be learned are well presented. I like Raymond's writing style and it is good to hear his perspectives on why things are the way they are. For whatever reason I hadn't picked up Raymond's blog on MSDN, "The Old New Thing", though I was well aware of it. Probably had something to do with the volume; two posts per day seems quite high to me. After reading the book, though, I'm subscribed! Sigh. I'm not a fan of the "bonus online chapters" concept, though I am sure that I'm going to go and read them sometime. Kind of detracts from the whole "book" experience if the whole book isn't... well, whole, I suppose.

A later post will detail some of the stuff I'm subscribed to online.



Hey! Where'd my E: Drive Go, Vista?

I use ReadyBoost in Vista. One day, I went to power up my laptop and when Vista resumed from hibernation I noticed that the light on the USB Flash-memory Device (UFD) was not on. Finding this a bit odd, I jumped into Windows Explorer, double-clicked on the E drive (the letter assigned to the UFD), and was presented with an interesting dialog:

Title: Item Not Found
Text: Could not find this item
This is no longer located in <%3 NULL:OpText>.
Verify the item's location and try again.
Removable Disk

Try Again Cancel

So I looked at the back of my laptop to verify the item's location, and deciding that the item was still there I clicked "Try Again". (I know, I know - not really what the person who wrote the message for the dialog intended...) I don't recall if the dialog dismissed and another instance reappeared, or if it was just that nothing happened. Either way, I wasn't getting anywhere. I unplugged the UFD, and plugged it back in again and things were fine.

A few days later, the same thing happened. I suspect I'll be dealing with this for a while.

Procedurally, I hate to think that I'm going to have to eject the device prior to hibernating, and then plug the device in again when Vista resumes - that's too tedious for my tastes. ReadyBoost would have to have a significant impact on performance for me to go through that rigamarole, and at this point I'm just not convinced that's the case.

Anyone else coping with %3 NULL:OpText? How are you dealing with it?



Setting the Priority of a Service Process via Script

Previously (here and here), I've written about isolating shared services so that they run in their own process, with a specific focus on the Windows Update Automatic Updates Service (wuauserv) that typically runs in the NETSVCS SVCHOST.EXE instance. One thing that can be done once this is accomplished is to lower the priority of the process so that when the service winds up consuming 100% of the CPU, the system doesn't become unresponsive.

Since we're dealing with a service, setting the priority of such a SVCHOST.EXE process can become problematic - the service may already be running, or, because it is a service, it is not started as non-service processes are, so one is not able to use START / [LOW NORMAL HIGH REALTIME ABOVENORMAL BELOWNORMAL] to impose a priority when the process starts. One can use a utility like Task Manager or Process Explorer to set the priority of a process on an ad hoc basis, but when the service restarts or the system reboots one has to remember to set the priority again.

Though not an ideal solution the following scripts (VBS using WMI, and PowerShell) can be used to set the priority of the SVCHOST.EXE instance hosting the isolated Windows Update Automatic Updates Service service to "below normal". Note that no check is done to ensure that the SVCHOST.EXE instance is only hosting one service - if wuauserv is found to be a service inside of the process, the priority is adjusted. Note also that no error handling is implemented.

I'll try to format the code so it looks nice, but I fear I will be limited...

Here's the code for the VBS / WMI script:

Const BELOW_NORMAL = 16384
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colServices = objWMIService.ExecQuery( _
"SELECT * FROM Win32_Service where name='wuauserv'")
For Each oService in colServices
Set colProcesses = objWMIService.ExecQuery( _
"SELECT * FROM Win32_Process where ProcessId=" & oService.ProcessId )
For Each oProcess in colProcesses

Here's the code for the PowerShell script:

(gps -id (get-wmiobject win32_service where {$_.name -eq "wuauserv"}).ProcessId).PriorityClass="BelowNormal"

The different values for the priority parameter of the SetPriority method of the Win32_Process WMI class can be found in the documentation for the SetPriority method.

The different values for the PriorityClass in the PowerShell script are "Normal", "Idle", "High", "RealTime", "BelowNormal", or "AboveNormal". Or, to get a list of the available options, one can use the following PowerShell command:


Once the script is in place and working, one can cause it to be invoked at will, or via scheduled task at specific times, or after logon, or any other way that one can get something to happen when Windows boots or a user logs on.