Over the holidays, I was asked by a friend to look at a problem they were running into on their Windows Vista system.  They were unable to connect to Windows Update and check for updates and received a cryptic error message.  After a few minutes of poking around on the system, I recognized a common set of symptoms that I had also seen on a couple of co-workers' systems a few weeks prior to that.  I also recognized some symptoms that I've heard about from customers via my blog who had trouble getting the .NET Framework 3.5 to install on Windows Vista due to issues with the .NET Framework 2.0 SP1 and/or .NET Framework 3.0 SP1 OS update packages that it tries to install behind the scenes.

Since I had a system available to debug on, I ran through some troubleshooting steps that I've learned over the past couple of years related to Windows Vista OS update installation issues and identified several specific symptoms, and then eventually came up with a set of steps to fix this system.  Then I came back to work after the holidays and tried out the steps on my co-workers' systems and found that the same basic set of symptoms and resolution steps worked there as well.  As a result, I'm going to try to summarize these symptoms and the steps I used to resolve them in the hope that they might be helpful to others suffering from the same issues on their systems.

Symptoms of this problem

In the systems I've been able to find so far with this type of problem, I've observed a common set of symptoms.

Symptom 1: Blank Windows Features dialog

Going to the Programs and Features control panel and then clicking the link on the left labeled Turn Windows features on or off brings up the Windows Features dialog.  This can also be launched directly by running OptionalFeatures.exe.  In the error cases I've seen, the Windows Features dialog appears completely empty instead of listing all of the Windows components that can be enabled or disabled on the system.

Symptom 2: Blank list of installed updates

Going to the Programs and Features control panel and then clicking the link on the left labeled View installed updates brings up a list of installed service packs, updates and hotfixes for the OS and any applications installed on the OS.  In the error cases I've seen, the list of installed updates was completely empty, even when I knew for sure that some OS updates had been installed on the system.

Symptom 3: Error when attempting to check for updates using Windows Update

Going to the Windows Update control panel and choosing the Check for updates link either reports an error message and an HRESULT code (for example, 0x80070005 or 0x80073712) or states that there were no updates available for the system.

Symptom 4: Hang or error when attempting to manually download and install OS updates

Bypassing the Windows Update control panel by going to the Microsoft support site and directly downloading and attempting to install a Windows OS update package results in the update hanging and failing to complete installation or the update reporting that it is not applicable on the current OS and exiting without installing.

I saw the latter behavior for the .NET Framework 3.5 on systems in this state.  On Windows Vista, the .NET Framework 3.5 attempts to install the .NET Framework 2.0 SP1 OS update package (because the .NET Framework 2.0 is an OS component on Vista).  When the systems I observed were in this broken state, the .NET Framework 2.0 SP1 failed to install, and I observed the following error in the .NET Framework 3.5 or 3.5 SP1 log file named %temp%\dd_dotnetfx35install.txt:

[08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): ***ERRORLOG EVENT*** : Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1.

Error code 1 from the .NET Framework 2.0 or 3.0 CBS package means that the package is not applicable on the current OS.

Steps that might help resolve this problem

On the systems that I have been able to find in this state so far, I have used the following set of steps to get the system back into a working state so that it could display information in the Windows Features dialog, check for updates using Windows Update and successfully install OS updates.  I have only been able to work with a few systems in this broken state though, so I'm not sure the same set of steps will always work.  I wanted to post them here in case there are helpful in some cases though, but please keep in mind that your mileage may vary.

1. Download the System Update Readiness Tool and save the .msu file to your desktop.  You need to make sure to download the correct version of this tool because there is a different version for each OS type and processor architecture.  You can find the download links for this tool in this knowledge base article.
   
   
2. Run the System Update Readiness Tool.  Once you download the appropriate .msu file for your OS type and processor architecture, you can double-click on it to install it.  This tool is not an OS update, but it uses the .msu packaging logic that OS updates use.  Therefore, it will tell you that it is installing the package, but it is actually running the tool in the background.  When the tool is running, you will see processes named checksur.exe, checksurlauncher.exe and checksurpackage.exe listed in Task Manager.
   
   Note: The tool attempts to fix any problems that it finds on the system.  However, it was not able to fix the problems it found on the systems that I have seen that experienced this type of problem.  It is still useful to run the tool in order to create a log file that lists the issues it finds.
   
   
3. Look at the output in the CheckSUR.log file and make fixes based on what the tool reports.  The checksur.exe tool created a log file at the following location: %windir%\Logs\CBS\CheckSUR.log.  On the systems that I have seen this type of problem on, the CheckSUR.log reported problems with some of the registry values located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages on the system.  I used the information in CheckSUR.log to locate and manually delete keys with errors reported for them.  On one of the systems, some of the sub-keys only had permissions assigned to them for the local system account, so I had to add the Administrators group and then delete them.  On one of the other systems, some of the sub-keys were reported as orphaned from some previous OS update that had been installed on the system, so I manually deleted them.
   
   One very important note here - I strongly recommend making a backup of your registry before trying to manually change any of the sub-keys under this HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages key.  This sub-key contains information that is usually only modified by installing and uninstalling OS update packages, so it is possible to cause problems with the OS if you delete keys that are still needed.  If you do not feel comfortable manually backing up and modifying your registry, then I instead recommend that you try to repair your OS by re-running OS setup using your original OS installation disc.

Note - I found another blog post with a more detailed step-by-step description about how to fix the Component Based Servicing registry keys.  You can find that post at http://www.raymond.cc/blog/archives/2009/03/06/fix-blank-or-empty-list-in-vista-turn-windows-features-on-or-off-optionalfeaturesexe/.

Hopefully this set of steps will be helpful to some folks who run into this type of symptoms on their Windows Vista systems.  Again, I want to emphasize that I've only been able to directly look at a few systems that exhibited this type of symptoms, so these steps may or may not help 100% of the time if you have a system in a similar state.

<update date="2/11/2009"> Updated list of steps to run the CheckSUR tool because the packaging for the tool has changed since the time I originally wrote this blog post. </update>

<update date="4/3/2010"> Added a link to a blog post with additional steps about how to fix the Component Based Servicing registry keys. </update>