Recently worked on a 2008 SP2 server that was receiving error 800F0902 when trying to check for updates. I confirmed access to the WSUS server manually via Internet Explorer and also confirmed no proxy settings were coming into play. I tried the age old trick of stopping the Windows Update service and renaming the C:\Windows\SoftwareDistribution folder to SoftwareDistribution.old and restarting the service. This regenerates the Windows Update configuration for you. This stubborn error survived that reset, so I finally came across a Microsoft FixIT KB article to fix Windows Update problems. I’m quite skeptical of using these, and I prefer to know exactly what’s being fixed, but without any other options, I decided to give it a try. No surprise, it said it found a configuration problem and fixed it, but the error persisted. A few other posts suggested an issue with trustedinstaller.exe (aka Windows Module Installer Service) so I gave that a restart and started receiving 80080005 errors. Another post suggested that after a reboot, this error cleared for that user. Sure enough, a reboot solved the problem for me as well.
After Microsoft released February’s patches, I ran into a strange issue on my custom-built Win7 x64 desktop. I would get to the windows 7 splash screen, but the system would inexplicably reboot at that screen. In order to get my system back up and running, I would have to boot into Safe mode to allow it to unconfigure the failed patch attempt, and then boot Safe mode a second time before I could boot windows normally. No memory dump was created and nothing was logged to Event Viewer about the failed attempts.
I spent one evening installing each patch one-by-one and rebooting until I was able to narrow it down to KB2479628 and KB2485376. The first patch affects kernel mode drivers and given the type of failure I was seeing, I started looking at driver issues. The most logical was my graphics driver since I could load safe mode without issue. I have an ATI Radeon HD5770 and a co-worker recommended trying driver ver 10.11 but that didn’t solve the issue. Since SP1 was around the corner, I figured I just hide the patches and deal with it then.
Fast-forward to yesterday, and I decided to give the SP1 install a try after I finished working for the day. Installation went off without a hitch, but alas, I ran into the same issue on first reboot. It was time tackle the driver issue. First thing I did was get back to a good desktop, and then perform a reboot and enable boot logging (press F8 after the POST to enable boot logging). Doing so will write a list of drivers loaded to C:\windows\ntbtlog.txt. This can be helpful in finding the last driver loaded before a failure when no BSOD occurs.
Knowing that KB2479628 caused the same behavior as the SP1 install, was directly related to drivers and only took a second to install, I decided that I would use it to “test” if a change I made solved the problem. So, I ran the install and on reboot I enabled boot logging again – last driver to load lis flpydisk.sys … hmmm … I don’t even have a floppy drive. I then compared to the reference log looking for what might load right after this driver. First thing that pops up is my graphics card, so after I go through the safe mode process to boot back to a desktop, I uninstall the display adapter, selecting the “Delete driver software for this device” option and then reboot. I have to repeat the process several times as it keeps picking up an older version of the driver but eventually, I get the base MSFT VGA driver. At that point, I retry the patch installation with boot logging enabled, but again windows automatically power cycles at the splash screen.
Long story short, I repeat the process for nearly every driver on my system: SATA controller, Realtek HD audio, Realtek NIC, etc. The boot logging led me on a wild goose chase and had me uninstalling any software that had a device associated with it including MagicDisc, my IOCell NDAS software, even Microsoft Intellipoint all to no avail. Finally, I remember that when I first built this system, I had an issue with the SATA controller mode. I had tried installing Windows 7 in AHCI mode, but saw something similar to this issue so switched to IDE mode. Looking at the BIOS settings, it was still set to IDE mode, but I tried switching to AHCI mode since nothing else had worked and I was basically out of ideas at that point. To my surprise, system booted after the patch installation.
I was then able to re-install the latest drivers from the mobo manufacturer’s website and finally, I tried a SP1 install. After about an hour, the system rebooted and updated to SP1 properly. After all was said and done, I tried switching SATA mode back to IDE and for whatever reason, I now can’t reproduce the issue. It’s possible it was a race condition with the driver for the SATA controller in IDE mode while trying to update (perhaps the updates were looking to replace though drivers but couldn’t because of some incompatibility) – though the currently loaded driver is from 2006 so that’s doubtful.
For reference, this is a Core i5-750 on a Gigabyte P55-UD4P motherboard running BIOS F10. If you have similar problems, try switching your SATA controller mode from IDE to AHCI or vice-versa.
UPDATE: After installing a OCZ Vertex SSD, I had to set the controller mode back to AHCI as I was experiencing the same issue. Since changing it, I’ve had no problems.
<UPDATE>John Bigg brought to my attention a hotfix Microsoft recently released for Windows Installer 3.1 v2: http://support.microsoft.com/kb/916089 that fixes this specific issue. Thanks John!</UPDATE>
You may have noticed since switching to Microsoft Update to get your updates, that your computer is unresponsive after startup when you have Automatic Updates enabled. You’ll also experience this problem when connecting to the Microsoft Update site. Task Manager will show near 100% CPU usage and extremely high Disk I/O for the svhost.exe process. Running tasklist /SVC from the command line will show that the matching PID contains the wuauserv service. The only known current solution, is to revert back to Windows Update. The problem manifests itself in the fact that Microsoft Update will search all cached installs on your local PC; a very CPU and Disk intensive process.
To revert back to the standard Windows Update, connect to the Microsoft Update site. On the left pane, click “Change Settings”. In the next window, scroll down to the “To stop using Microsoft Update” section and select the “Disable Microsoft Update software and let me use Windows Update only” checkbox. Click “Apply Changes”.