Microsoft .NET Framework 2.0 Service Pack 1 Fails to Install

Microsoft .NET Framework 2.0 Service Pack 1 Fails to Install

  • Comments 12

A lot of customers have recently started seeing the following errors, all stating in various ways that Microsoft .NET Framework 2.0 Service Pack 1 failed to install. You may also see this when attempting to install other updates on top of .NET 2.0 SP1. The error you will see depends on how you are applying updates.

If you are installing .NET 2.0 SP1 or other updates on top of .NET 2.0 RTM by installing the package directly, you may see the following dialog.



If you click on the Error Log hyperlink, the error log simply states the following.

[04/17/08,17:08:27] Microsoft .NET Framework 2.0a: [2] Error: Installation failed for component Microsoft .NET Framework 2.0a. MSI returned error code 1603

If you are attempting to install updates using Windows Update or Microsoft Update, you may see a dialog similar to the following.



If you view the history of the updates you've applied and click on the error icon, the following dialog denotes the same generic error.



To determine the root cause, you need to look in your %TEMP% directory for a file named dd_NET_Framework20_Setup*.txt, where * will be 4 random alphanumeric characters. Find the most recent log if there are multiple logs by sorting by Date Modified.

The problem described here can be found by searching for "Resolving Patch source" in the log file.

How to workaround this issue

If you found the text "Resolving Patch source" in the log file described in the problem description above, you can download the Microsoft .NET Framework 2.0 Registration Correction Tool attached as and extract the contents. There are three directories corresponding to different computer architectures. Most customers will need to open x86ret and run clwireg.exe. You need to be an administrator to run this utility, and it is only to repair this issue with Microsoft .NET Framework 2.0.

Administrators may also use this utility in scripts by passing either /q or /quiet and it will not display any user interface and will, therefore, not block scripts.

In either case, this tool keeps a running log in %TEMP%\dd_clwireg.txt in which you can read more information about what it has done.

Description of the issue

The specific failure detailed here is caused by corrupted patch registration or a missing patch package.

When Windows Installer performs any maintenance installation - that is any installation after the initial installation, including repairs, patch install and uninstall, and uninstall of the product - it must load the cached installation database and all applicable patches. If those packages are not found in the Windows Installer cache, then Windows Installer attempts to find them previous source directories. Failing to find them, Windows Installer fails the installation with error message 1714, which reads,

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.

System error 1612 is a Windows error code, which identifies the message,

The installation source for this product is not available. Verify that the source exists and that you can access it.

Because .NET 2.0 SP1 is a major upgrade which uninstalls previous versions of .NET 2.0, toward the end of the installation it attempts the uninstall of .NET 2.0 which is a maintenance installation. Because a patch package could not be found, the uninstall attempt fails which causes .NET 2.0 SP1 to rollback and report failure. This may also cause .NET applications to err because of an incomplete rollback.

This problem likely occurs for one of the following two reasons.

The Installer cache is missing the necessary files

The Windows Installer cache located in %WINDIR%\Installer is critical for repairing, updating, and even uninstalling products. It must not be removed, nor any files in it. It is safe - though not advised - to only remove %WINDIR%\Installer\$PatchCache$ or subdirectories if space is critical. This may lead to prompts for source for any products, however, when you attempt to repair or update them.

If this is the case, the line above where you found "Resolving Patch source" would read something similar to the following.

MSI (s) (D0:B0) [19:05:57:843]: Couldn't find local patch 'C:\WINDOWS\Installer\50bad.msp'. Looking for it at its source.
MSI (s) (D0:B0) [19:05:57:843]: Resolving Patch source.

The attached tool attempts to fix this by deleting all patch registration specific to this patch so that future maintenance installations do not attempt to load the patch package.

You may also attempt to fix this by rebuilding the installer cache. You will most often find the KB# for the patch in the lines that follow "Resolving Patch Source", as shown in the following example.

MSI (s) (D0:B0) [19:05:57:859]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (D0:B0) [19:05:57:859]: Note: 1: 1706 2: -2147483647 3: NDP20-KB917283-X86.msp

Browse to and search for the KB# to download the patch again. You can extract the patch using /x or /extract and then following the instructions on rebuilding the installer cache.

Patch registration is corrupt

While we have not yet determined the cause, patch registration may have become corrupted. If this is the case, the line above where you found "Resolving Patch source" would read something similar to the following.

MSI (s) (CC:5C) [03:02:56:181]: Couldn't find local patch ''. Looking for it at its source.
MSI (s) (CC:5C) [03:02:56:181]: Resolving Patch source.

Notice that the location of the patch is missing. In this particular case, a patch is still registered to a product but location information for the patch is missing. The file may or may not exist, but Windows Installer wouldn't even know the path to the file to load.

The attached tool attempts to fix this by deleting all patch registration for this patch so that future maintenance installations do not attempt to load the patch package.

How to prevent this issue

It is critical that you do not remove files located directly in %WINDIR%\Installer, and that you are careful using any disk space reclamation utilities that free up space by deleting large or seldom used files so that you do not allow them to remove these same files. If you have used such a utility that did this, please leave a comment with information about that tool and we'll work with developers to try to mitigate this problem in the future.

The Windows Installer CleanUp Utility which uses msizap.exe (also shipped with the Windows SDK) is capable of deleting some or all files in the Installer cache but should be used only as a last resort and after carefully reading all information and warnings about the tool. It is always best to uninstall a product or patch correctly using Windows Installer either through Add/Remove Programs on Windows 2000, XP, or Server 2003; Software Explorer on Vista and newer; or using msiexec.exe on the command line if the product does not provide its own uninstaller.

Updated: the issue and workaround have been adapted for KB951950 and I have updated the attachment to refer to the Microsoft Download Center location.

Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post
  • Just incase , there's another solution - Installing the .NET 3.5 Runtime which includes .NET 2.0 SP1 in it ( as well as .NET 3.0 SP1 )

    I had the problem in Vista - and that did the trick =)

  • Adlai, .NET 3.5 does fail to install for the same reason on downlevel platforms. It also installs .NET 2.0 SP1, as you pointed out, which is the same package as the separate download. But on Vista, .NET 2.0 and .NET 3.0 are not installed as Windows Installer packages, but are instead installed as Windows Vista components which use a different installation technology and, thus, do not suffer from the same problem as downlevel platforms (2000, XP, and Server 2003).

  • Last week, I started getting a larger than normal volume of emails from customers who ran into problems

  • A while back, I posted a set of instructions that can be used to try to resolve .NET Framework installation

  • The tool msizap.exe that is available in the Windows SDK and elsewhere on the web (remember to always

  • Hi, we were having trouble installing .NET Framework 2.0 SP 1 on our Windows 2000 Server. It would simply fail when through windows update, and it would crash with a request to submit an error report when run from the downloaded installer (dotnetfx.exe). My log file has:

    MSI (s) (70:68) [14:20:28:710]: LUA patching is disabled: only available on Windows XP and greater platforms

    MSI (s) (70:68) [14:20:28:710]: Resolving source.

    MSI (s) (70:68) [14:20:28:710]: Resolving source to launched-from source.

    MSI (s) (70:68) [14:20:28:710]: Setting launched-from source as last-used.

  • .NET caches its source to a sub-directory of where .NET is installed (under %WINDIR%\Microsoft.NET\Framework\v2.0.50727). Was anythign after that in the log? It should resolve its source correctly and continue.

  • I have been trying everything - everything including ALL of your directions to no avail. I thought I had it a few times, but no.


  • John, please run the collect utility documented at and post the logs to a location I can access.

  • All this reading and trouble shooting is beyond my capeablity. $150.00 is a great deal of money for me and I feel like this zune should work without me spending hours reading and troubleshooting Microsoft bugs.

  • I'm just stating this for the public good. Its not to refute what Heath has said nor the registry utility he has which may be at the root of the problem; but it won't usually fix it so if youve been trying to reinstall Net Framework 2.0 over and over to no avail read this.

     Download the microsoft clean up utility msicuu2.exe  at the url I've added ;install it and select and remove Microsoft Net Framework 2.o.

     Then go into youre automatic updates client directory.. C:\Windows\Software Distribution\Download\Install and re-run NetFX2OSP1_x86.exe. It will be successful.

      Bsaically its an old, half installed version that has to be removed before the automatic Updates KB110806 will install.

     Its possible that the registry was messed up and caused it to begin with.

  • tombobiche, the tool I posted is to fix a specific issue - not all issues. And it was, in fact, and older copy of the Clean Up Utility that had an older version (2.x and older) of msizap.exe that was found to cause this problem.

Page 1 of 1 (12 items)