Strange .NET Framework 2.0 SP1, 3.0 SP1 and 3.5 installation error caused by orphaned registry value

Recently, I heard from a customer who could not get the .NET Framework 2.0 SP1 to install correctly on their system, and I wanted to explain the issue and how we were eventually able to resolve it in case anyone else runs into a similar issue in the future.

Description of the issue

The customer was able to successfully install the .NET Framework 1.1 and the original version of the .NET Framework 2.0.  However, when they launched the .NET Framework 2.0 SP1 installer, it allowed them to accept the license agreement, and then briefly showed the progress page before transitioning to a blank error page that looks like the following:

This error dialog is obviously not very helpful, and to complicate matters, there are not any errors reported in the .NET Framework 2.0 SP1 log files that are created in this scenario.  I had the customer use these steps to gather a list of installed products, and it did not list the .NET Framework 2.0 SP1, and the information in the application event log seemed to indicate that setup had not even attempted to install the 2.0 SP1 MSI.

Root cause of this issue for the .NET Framework 2.0 SP1

Eventually I discovered that there was an orphaned registry value on the system that was causing .NET Framework 2.0 SP1 setup to get confused and think that the product was already installed, even though the MSI was not actually installed on the system.  Once I discovered this issue, I was able to reproduce it on my test machine.  This is the exact registry value that causes this issue during .NET Framework 2.0 SP1 setup:

On x86 systems:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727]
Version

On x64 and ia64 systems:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v2.0.50727]
Version

How to resolve this issue for the .NET Framework 2.0 SP1

Here are the steps that can be used to resolve this issue if you encounter it during .NET Framework 2.0 SP1 setup:

  1. Click on the Start menu, choose Run, type cmd and click OK
  2. Run this command:  reg delete "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727" /v Version /f
  3. Run this command:  reg delete "HKLM\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v2.0.50727" /v Version /f
  4. Try again to download and install the .NET Framework 2.0 SP1 from here for x86, from here for x64 or from here for ia64

Root cause of this issue for the .NET Framework 3.0 SP1

While investigating this issue, I found that a similar issue can affect the installer for the .NET Framework 3.0 SP1.  A similar dialog to the one shown above will appear when attempting to run .NET Framework 3.0 SP1 setup, and like in the case of the .NET Framework 2.0 SP1, no errors are reported in the .NET Framework 3.0 SP1 setup log files.  This is the exact registry value that causes this issue during .NET Framework 3.0 SP1 setup:

On x86 systems:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0]
Version

On x64 and ia64 systems:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.0]
Version

How to resolve this issue for the .NET Framework 3.0 SP1

Here are the steps that can be used to resolve this issue if you encounter it during .NET Framework 3.0 SP1 setup:

  1. Click on the Start menu, choose Run, type cmd and click OK
  2. Run this command:  reg delete "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0" /v Version /f
  3. Run this command:  reg delete "HKLM\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.0" /v Version /f
  4. Try again to download and install the .NET Framework 3.0 SP1 from this location

Root cause of this issue for the .NET Framework 3.5

The above issue can also affect the installer for the .NET Framework 3.5 because it uses the same setup engine as the .NET Framework 2.0 SP1 and 3.0 SP1.  A similar dialog to the one shown above will appear when attempting to run .NET Framework 3.5 setup, and like in the cases above, no errors are reported in the .NET Framework 3.5 setup log files.  This is the exact registry value that causes this issue during .NET Framework 3.5 setup:

On x86 systems:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5]
Version

On x64 and ia64 systems:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.5]
Version

How to resolve this issue for the .NET Framework 3.5

Here are the steps that can be used to resolve this issue if you encounter it during .NET Framework 3.5 setup:

  1. Click on the Start menu, choose Run, type cmd and click OK
  2. Run this command:  reg delete "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Version /f
  3. Run this command:  reg delete "HKLM\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.5" /v Version /f
  4. Try again to download and install the .NET Framework 3.5 from this location

Another note about .NET Framework 3.5 setup

The above issues affects the standalone setup packages for the .NET Framework 2.0 SP1, the .NET Framework 3.0 SP1 and the .NET Framework 3.5.  However, since the 2.0 SP1 and 3.0 SP1 packages are also installed as prerequisites by .NET Framework 3.5 setup, that means this issue can also cause a different type of failure during .NET Framework 3.5 setup than the one described above.

The orphaned registry value issue is specific to the MSI-based versions of the .NET Framework 2.0 SP1 and 3.0 SP1, so it is only possible to see the problem below during .NET Framework 3.5 setup on Windows XP and Windows Server 2003 since those are the only OS's that you can install the MSI-based versions of the .NET Framework 2.0 SP1 and 3.0 SP1 on (as described here).

If the orphaned registry key is from .NET Framework 2.0 SP1 or 3.0 SP1 setup (as opposed to from 3.5 setup), then the behavior of .NET Framework 3.5 setup is a bit different than the behavior for the standalone .NET Framework 2.0 SP1 and 3.0 SP1 setups described above.  During .NET Framework 3.5 setup, an orphaned .NET Framework 2.0 SP1 or 3.0 SP1 registry value will cause an error dialog like the following will appear:

This is a generic error page that appears for all .NET Framework 3.5 installation failures.  In this orphaned registry value scenario, the error log that appears when clicking the link in this dialog displays misleading information about the cause of the failure.  If the system has the .NET Framework 2.0 SP1 registry value orphaned, the .NET Framework 3.5 setup error log will indicate that the .NET Framework 3.0 SP1 is failing.  If the system has the .NET Framework 3.0 SP1 registry value orphaned, the .NET Framework 3.5 setup error log will indicate that the .NET Framework 3.5 is failing like in the following log snippet:

[06/19/08,11:11:11] Microsoft .NET Framework 3.5 'package': [2] Error: Installation failed for component Microsoft .NET Framework 3.5 'package'. MSI returned error code 1603
[06/19/08,11:11:30] WapUI: [2] DepCheck indicates Microsoft .NET Framework 3.5 'package' is not installed.

However, if you look in the main install log file for .NET Framework 3.5 setup (%temp%\dd_dotnetfx35install.txt), you will not see any attempt to install the .NET Framework 2.0 SP1 or 3.0 SP1.  If your system has one of the 2.0 SP1 or 3.0 SP1 registry values present but does not have the corresponding MSI installed, then the same workarounds described above can help resolve this .NET Framework 3.5 installation issue as well.

Final note

There are many possible causes for .NET Framework 2.0 SP1, .NET Framework 3.0 SP1 and .NET Framework 3.5 setup failures.  The scenario in this blog post only describes one possibility.  If you are encountering a .NET Framework installation failure but have different symptoms or 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="12/2/2009"> Fixed broken links to images used in this blog post. </update>