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:  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 clwireg.zip 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 http://support.microsoft.com 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.