Possible issue where .NET Framework 2.0 SP1 setup can fail and corrupt the .NET Framework 2.0
Last week, I started getting a larger than normal volume of emails from customers who ran into problems using applications that require the .NET Framework 2.0 and needed advice about how to get their systems back up and running. After investigating some of these cases and talking to some folks on the .NET Framework technical support team and Heath Stewart, I learned more about what was causing many of these issues. Heath wrote up an in-depth summary of this issue and posted a tool to help repair systems that get into this state in this post on his blog. I want to also briefly summarize the issue here and link to his blog in the hopes of making it easier to find in the future.
Description of the issue
Most of the customers I had talked to had the original version of the .NET Framework 2.0 on their system and then attempted to install the .NET Framework 2.0 SP1 (either by directly downloading it or by having it offered to them on Windows Update). However, the .NET Framework 2.0 SP1 setup failed due to an error encountered while uninstalling the original version of the .NET Framework 2.0. Note - behind the scenes, the .NET Framework 2.0 SP1 attempts to do a major upgrade of the original version of the .NET Framework 2.0.
Unfortunately, there are some issues in the uninstall rollback logic for the .NET Framework 2.0 that cause assemblies to not be put back into the global assembly cache (GAC) if .NET Framework 2.0 uninstall fails. That can leave systems in a state where the .NET Framework 2.0 is partially installed and applications that require the .NET Framework 2.0 will not run correctly. To complicate matters, on a system in this state, the .NET Framework 2.0 cannot be repaired or uninstalled and the .NET Framework 2.0 SP1 cannot be installed.
How to diagnose the issue
Systems that encounter this issue will have the following information in the .NET Framework 2.0 SP1 setup wrapper log file (named %temp%\dd_dotNETFX20error.txt):
[03/25/08,11:11:11] Microsoft .NET Framework 2.0a: [2] Error: Installation failed for component Microsoft .NET Framework 2.0a. MSI returned error code 1603
Looking deeper, these systems have the following information in the .NET Framework 2.0 SP1 verbose MSI log file (named %temp%\dd_net_framework20*.txt):
Error 1714.The older version of Microsoft .NET Framework 2.0 Service Pack 1 cannot be removed. Contact your technical support group. System Error 1612.
Windows Installer error 1612 means the following:
The installation source for this product is not available. Verify that the source exists and that you can access it.
How to fix a system that encounters the issue
Once a system encounters this issue, it is necessary to update the Windows Installer information for the .NET Framework 2.0 so it will be put back into a consistent state that will allow you to uninstall the .NET Framework 2.0 and install the .NET Framework 2.0 SP1.
Heath has created a tool named the Microsoft .NET Framework 2.0 Registration Correction Tool (clwireg.exe) that will attempt to surgically repair incorrect Windows Installer registration information for the .NET Framework 2.0 in order to unblock the uninstall process. This tool is available for download via a Microsoft knowledge base article (KB951950). This tool creates a log file named %temp%\dd_clwireg.txt that describes what it is doing to your system in more detail.
Some folks have also contacted me and indicated that they were able to resolve this issue by using the steps in this blog post. In my experience, those steps will also work, but they are much more time-consuming and invasive than the .NET Framework 2.0 registration correction tool, so if you run into an issue like this, I strongly encourage you to try that tool before resorting to these steps that I posted.
Root cause of the issue
On the systems we have looked at so far, one of the following things had occurred:
- The Windows Installer registry information for the .NET Framework 2.0 got into an inconsistent state; the system thinks that one or more hotfixes are installed for the .NET Framework, but the information about the source location of the hotfix is missing from the registry
- The Windows Installer cache (%windir%\Installer) is missing some information about a .NET Framework 2.0 patch that is installed on the system
We have not yet tracked down exactly why this problem happens with such a high frequency. I have heard from some customers who have manually deleted files from the %windir%\Installer directory, but that is not very common and does not explain very many instances I've seen of this problem so far.
We also suspect that some overly aggressive registry and file system cleaner utilities might be causing this on some systems, but we have not yet been able to reproduce that in our test lab. If you encounter this issue and can track it down to a registry or file system utility, then please post a comment on this blog post indicating the name, version and download location of the utility you saw this behavior from so that we can try to talk to the creator of the utility to make sure that they do not remove critical Windows Installer information from systems in future versions of their tools.
Final comments
There are many possible causes for .NET Framework 2.0 SP1 setup failures. If you are encountering a failure but have different information in your log files, you are likely running into a different problem. In those cases, I suggest consulting the .NET Framework setup troubleshooting guide for links to other possible installation issues and workarounds, links to log file locations, links to readme files, etc.
<update date="10/1/2008"> Added a link to the knowledge base article for the .NET Framework registration correction tool </update>