I wrote an application late last year that is designed to clean up computers that have problems getting the .NET Framework 1.0 or 1.1 to install correctly.  I have been working on refining the tool for the past couple of months, working out some bugs, adding additional cleanup features, etc.  The .NET Framework setup Product Support team has been using this cleanup tool for the past few months to help resolve many cases, and the internal Microsoft helpdesk has also started using it to solve internal cases where employees cannot get .NET Framework service packs or hotfixes to install correctly.  I have also been sending this tool out to individuals who email me via my blog and ask for help resolving setup problems - most commonly this is because of issues installing .NET Framework service packs or hotfixes such as MS05-004.

Since I have been seeing really good success rates for using this cleanup tool and it has proven to speed up the process of resolving issues so customers can get the .NET Framework installed correctly and start using managed code on their computers, I decided to try to get a KB article written up with a copy of the tool that customers could download on their own without needing to contact me directly or call our PSS team.  The KB publishing process can sometimes take a while with technical reviews and things like that, so in the meantime I am going to post a link to the tool here on my blog.

You can download the tool by visiting the .NET Framework Cleanup Tool User's Guide and using one of the download links listed there.

There are a couple of very important caveats that you should read before using this tool to cleanup .NET Framework bits on your machine:

1. You should try to perform a standard uninstall first.  This tool is not designed as a replacement for uninstall, but rather as a last resort for cases where uninstall or repair did not succeed for unusual reasons.
2. This cleanup tool will delete shared files and registry keys used by other versions of the .NET Framework.  So if you use it, be prepared to repair or reinstall any other versions of the .NET Framework that are on your computer to get them to work correctly afterwards

The tool itself has been fairly well tested, but I'm sure it is still not perfect.  I'm still in the process of fixing bugs as I find them and adding features to make it more effective at cleaning up known issues and to make it more intelligent about identifying root causes so we can fix the underlying bugs in .NET Framework setup for future releases.  As I update it, I will post updates to my blogs and update the copy of the tool located at the link above.

I hope this tool will be helpful in resolving problems installing the .NET Framework.  Please let me know if you run into any issues while using the cleanup tool or if you are still unable to install the .NET Framework (or any service packs or hotfixes) after running it.

<update date="3/3/2009"> Added a link to the .NET Framework Cleanup Tool User's Guide, which contains the most up-to-date download location for this tool. <update>

A while back, I wrote a blog post about a .NET Framework 2.0 beta 2 installation problem that was caused by incorrect access control list (ACL) permissions on some registry hives.  In that post, I described how to use a tool in the Windows Resource Kit named SubInACL to reset file and registry ACLs to help solve this problem.

Ever since I wrote that post, I have run into installation errors for several other products that have been solved by using the SubInACL tool.  Therefore, I wanted to write a standalone set of instructions for how and when to use the SubInACL tool because the previous blog post is specific to the .NET Framework 2.0 setup and does not always appear in search results when people run into this kind of a problem and search the Internet for assistance.

How to download and run SubInACL

Here are some steps that can be used to download and run the SubInACL tool to repair file and registry permissions that are often needed to successfully install programs on Windows, particularly for MSI-based (Windows Installer) setups:

1. Download the SubInACL tool and install it.  By default it will install to c:\Program Files\Windows Resource Kits\Tools
2. If you are running Windows Vista, click on the Start menu, choose All Programs, then Accessories, then right-click on the item named Command Prompt and choose Run as administrator
3. If you are running an OS other than Windows Vista, go to the Start menu, choose Run, type cmd and click OK
4. In the cmd prompt, type notepad reset.cmd and click yes to open Notepad.exe and create a new text file named reset.cmd
5. Copy and paste the following contents into reset.cmd (or download it from this location on my file server and rename it from reset.cmd.txt to reset.cmd):
   

   
   cd /d "%programfiles%\Windows Resource Kits\Tools"
   
   subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators > %temp%\subinacl_output.txt
   subinacl /keyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators >> %temp%\subinacl_output.txt
   
   subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f /grant=users=r /grant=everyone=r /grant=restricted=r /setowner=administrators >> %temp%\subinacl_output.txt
   subinacl /keyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f /grant=users=r /grant=everyone=r /grant=restricted=r /setowner=administrators >> %temp%\subinacl_output.txt
   
   subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txt
   subinacl /keyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txt
   
   
   subinacl /subdirectories %programfiles%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txt
   
   subinacl /subdirectories %windir%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txt

   
   
6. Change the values named YOURUSERNAME to be the Windows user account that you are logged in with.
   
   Note:  The YOURUSERNAME value should match the name of your user folder at c:\Documents and Settings (or c:\users on Windows Vista and higher).  You can also find the value to use for YOURUSERNAME by launching Task Manager and looking at the user name listed in the User Name column of the Processes tab.
   
   
7. Save and close reset.cmd. 
8. In the cmd prompt, type reset.cmd and press enter to run the SubInACL tool.  This tool will take several minutes to run, and it requires that the user account you are using has administrator privileges on the system.  This is why it is necessary to run it from an elevated cmd prompt on Windows Vista.  Step 2 above can be used to start an elevated cmd prompt on Windows Vista.
9. After reset.cmd completes, try to install the product that previously failed to install correctly on your system.

Also note: Running the above command lines will cause SubInAcl to create a log file named %temp%\subinacl_output.txt.  If you see any errors reported in the cmd prompt after running SubInAcl, you can look in this log file for more detailed information about what file(s), folder(s) or registry value(s) are causing the errors.  To open this log file, you can click on the Start menu, choose Run, type notepad %temp%\subinacl_output.txt and click OK.

When looking at this log file, you may see some errors reported with error code 5.  That error code means Access Denied, and it is typically caused by Windows or some other program running on your system that is holding files, folders or registry values in use so that SubInAcl is unable to update the permissions for them.  Most of the time, that type of error in the SubInAcl output can be safely ignored, but you may need to try to reboot and then manually fix the permissions for these files, folders or registry keys as a workaround.

Example of a setup failure that was fixed by SubInACL

A customer contacted me with a problem installing Visual Studio 2005.  I looked at the main Visual Studio log file located at %temp%\dd_vsinstall80.txt, and I found that Windows Installer 3.1 setup was failing.  Then, I looked at the Windows Installer 3.1 setup log file located at %windir%\KB893803v2.log.  It showed the following error:

30.844: DoRegistryUpdates:UpdSpInstallFromInfSection Failed for MSI.Reg.Install: 0x5
30.844: DoInstallation:DoRegistryUpdates failed
30.875: Access is denied.

I had the customer run the above steps to use the SubInACL tool to update the file and registry ACLs on their system, and then they were able to install Windows Installer 3.1 and Visual Studio 2005 with no further problems.

<update date="11/15/2006"> Updated subinacl command lines to include recursive ACL updating for folders and files under %windir% </update>

<update date="3/22/2007"> Updated the steps to make them easier to follow by moving the directory change into the batch file. </update>

<update date="9/25/2007"> Updated the notes to indicate that some Internet Explorer script errors can be resolved with this tool as well. </update>

<update date="5/30/2008"> Updated command lines based on customer feedback regarding their experiences on Windows Vista. </update>

<update date="6/16/2008"> Updated command lines to cause SubInAcl to create a log file in the %temp% directory in case it is needed for troubleshooting afterwards. </update>

<update date="6/17/2008"> Added a link to a blog post where I describe a couple of workarounds for problems that can occur while trying to install and/or run SubInAcl. </update>

<update date="6/20/2008"> Updated command line to include a backslash after %SystemDrive% in the 2nd to last command. </update>

<update date="6/24/2008"> Updated wording of link to the post for troubleshooting SubInAcl errors to try to make it more visible. </update>

<update date="7/29/2008"> Updated directory ACL command lines to not affect the Documents and Settings sub-folders. </update>

<update date="3/12/2009"> Fixed broken link to reset.cmd. </update>

<update date="4/7/2009"> Added clarification about how to determine the correct value to substitute for YOURUSERNAME in the sample SubInAcl script. </update>

<update date="5/18/2009"> Added clarification about where to run reset.cmd after creating it. </update>

I have posted an updated version of the .NET Framework cleanup tool that now contains support for automatically cleaning up the .NET Framework 1.0, the .NET Framework 1.1, the .NET Framework 2.0, the .NET Framework 3.0 and the .NET Framework 3.5.

This tool automates the manual cleanup steps for the .NET Framework 2.0 that I posted a while ago.  These steps have helped solve most of the known .NET Framework 2.0 beta uninstall issues that I know of.  In addition, the tool can be useful to return your system to a known (relatively clean) state in case you run into any .NET Framework 2.0 installation failures so that you can try to install again.

The updated version of the cleanup tool contains options to clean up the .NET Framework 1.0, 1.1, 2.0, 3.0 and 3.5 separately and all versions simultaneously in a single step.  The cleanup tool contains logic so that if it is run on an OS version that includes the .NET Framework as an OS component, it will not offer the option to clean it up.  This means that running the cleanup tool on Windows XP Media Center Edition or Tablet PC Edition will not offer the option to clean up the .NET Framework 1.0, running it on Windows Server 2003 will not offer the option to clean up the .NET Framework 1.1 and running it on Windows Vista will not offer the option to clean up the .NET Framework 2.0 or the .NET Framework 3.0.

There are a couple of very important caveats that you should read before using this tool to cleanup .NET Framework bits on your machine:

1. This tool is designed as a last resort for cases where install, uninstall or repair did not succeed for unusual reasons.  It is not intended as a substitute for the standard uninstall procedure.  You should try to perform an uninstall from Add/Remove Programs before using this cleanup tool.
2. This cleanup tool will delete shared files and registry keys used by other versions of the .NET Framework.  If you run the cleanup tool, you will need to perform a repair or reinstall for all other versions of the .NET Framework that are on your computer to get them to work correctly afterwards.

I have been using this tool for a while, and it has proven reliable, but there may still be bugs in it in certain scenarios.  Please contact me if you run into any issues while using the cleanup tool or if you are still unable to install the .NET Framework (or any service packs or hotfixes) after running it.

The tool has a command line switch that allows it to be run in silent mode if needed.  There is more information about how to run it in silent mode in the .NET Framework Cleanup Tool User's Guide.

<update date="8/22/2007"> Added information about removing the .NET Framework 3.0 because the tool now supports this version of the .NET Framework in addition to 1.0, 1.1 and 2.0. </update>

<update date="9/13/2007"> Added information about removing the .NET Framework 3.5 because the tool now supports this version of the .NET Framework in addition to 1.0, 1.1, 2.0 and 3.0. </update>

<update date="12/3/2007"> Added a link to the silent install instructions for the cleanup tool </update>

<update date="2/28/2009"> Added links to the .NET Framework Cleanup Tool User's Guide, which contains download locations and detailed information about how to use the cleanup tool. </update>

Hey all, first off I want to apologize for not posting anything in a couple of weeks.  I have had a couple of mini-vacations and been wrapped up with some other stuff, but I'm back now!  I've been working with some Product Support folks I know to turn some documents I wrote for internal troubleshooting into knowledge base articles, and I decided that I wanted to go ahead and post some of the information here so it would be available sooner rather than later.  The first installment is some detailed information about the dreaded 1935 (or 2908) error that sometimes happens when trying to install the .NET Framework or other MSI-based products that install managed assemblies to the GAC.  This is a long post, but hopefully with some useful info.  Let me know if you see any scenarios not covered by this information or have any questions....

1935 Errors in Setup

Abstract

The following document describes causes of 1935 errors during .NET Framework, J# redistributable package, language pack, or Visual Studio setup.  It also explains how to diagnose the root cause of a 1935 error and workaround or fix the error.

Introduction

A 1935 error is one of the most common problems that can prevent a user from being able to install the .NET Framework, J# redistributable package, Visual Studio or any other application that uses the Windows Installer MSIAssembly and MSIAssemblyName tables to install assemblies.

In general, this error means that Windows Installer encountered an error while trying to install assemblies to the Global Assembly Cache (GAC) or the Win32 GAC (WinSxS).  This error is considered fatal and causes setup to fail and initiate rollback.

If the setup is run in UI mode, the user will see a message box indicating that a 1935 error occurred, and it will list the HRESULT and the Windows Installer component GUID of the assembly that caused the error.  If the setup is run in silent mode, the user will see no visible error.  In both cases, more detailed information about the error can be found in the Windows Installer verbose log file.

Affected Products

·         .NET Framework 1.0

·         .NET Framework 1.1

·         .NET Framework 1.1 language packs

·         Visual J# .NET redistributable 1.1

·         Visual J# .NET redistributable 1.1 language packs

·         Visual Studio .NET 2002 (all versions)

·         Visual Studio .NET 2003 (all versions)

Finding log information for 1935 errors that occur during setup

Where to find the log files

In order to diagnose the cause of a 1935 error, it is first necessary to locate information in the Windows Installer verbose log.  If the error occurred during Visual Studio setup or during the .NET Framework or J# redistributable setups that are run as a part of Visual Studio Prerequisites (or Windows Component Update) setup, verbose logging is enabled by default.  The log files vsmsilog*.txt, netfx.log, or jsredistmsi.log in %temp% will provide the necessary information, depending on which product’s setup failed.

If the error occurs during standalone setup for the .NET Framework, .NET Framework SDK or J# redistributable package setup, it will be necessary to rerun the failing setup with an extra command line parameter to enable Windows Installer verbose logging in order to produce a log file with the necessary information to debug the failure.  To enable verbose logging, rerun the setup with the following command line syntax:

Note: The log file location can be controlled by passing a full path after the /l switch to install.exe or inst.exe.  The locations listed in the table are the default locations if no path is provided.

Where to find error information in the log file

To pinpoint the cause of a 1935 error, search for the string return value 3 in a verbose Windows Installer log file.  This will show the exact point in which setup failed and initiated a rollback.  The following is an example of the information written to a Windows Installer verbose log file in the case of a 1935 error:

Error 1935.An error occured during the installation of assembly component {7D4B5591-4C80-42BB-B0E5-F2C0CEE02C1A}. HRESULT: -2146234301. assembly interface: IAssemblyCacheItem, function: Commit, assembly name: Microsoft.Vsa.Vb.CodeDOMProcessor,Version="7.0.5000.0", PublicKeyToken="b03f5f7f11d50a3a", Culture="neutral",FileVersion="7.10.3052.4", ProcessorArchitecture="neutral"

In this example, the assembly named Microsoft.Vsa.Vb.CodeDOMProcessor.dll failed to install properly due to an error with HRESULT value -2146234301.

List of causes of 1935 errors and their HRESULT values

There are many different underlying causes of a 1935 error, each represented by a different HRESULT.  Once you locate the information in the Windows Installer verbose log file indicating which assembly is causing the error and what the HRESULT of the error is, you can use the table below to determine more specific information about the cause:

NOTE: The Windows Installer team created separate error codes for 3 of the above return types starting with the version that shipped with Windows Server 2003.  The following are the new error codes and the return types they correspond to in Windows Server 2003 and in versions of Windows Installer greater than 2.0 (all other return types from the above table continue to be represented by error code 1935):

Resolving 1935 errors that occur during setup

Most of the above HRESULT values in the table of 1935 errors above indicate some kind of setup authoring problem, and they require that the MSI package or some of the files in the package be patched and repackaged.  All return types that begin with FUSION fit into this category.

1935 errors with HRESULT -2147319761 (function not defined in specified dll)

The most common source of a 1935 error is HRESULT -2147319761 (which means that a function is not defined in specified DLL).  This error is typically caused by a mismatch or incompatibility between the version of mscoree.dll in the Windows system directory and the version needed by the product being installed.  Often this can occur if a user has a previous beta version or technology preview build of the .NET Framework installed on their machine (even if they then uninstall it).

There are several possible ways to workaround this type of 1935 error.  The workarounds depend on the product being installed and the OS that the product is being installed on.  Refer to the sections below for more details for the individual products.

.NET Framework

This workaround applies to all versions of the .NET Framework. 

The following steps will fix most cases of a 1935 error with HRESULT -2147319761 on operating systems that do not contain the .NET Framework as part of the operating system (applies to Windows 98, Windows Me, Windows NT 4, Windows 2000, and Windows XP except as noted below):

1. Rename the file %windir%\system32\mscoree.dll (or %windir%\system\mscoree.dll on Windows 98 and Windows Me).  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Delete the folder %windir%\system32\urttemp (or %windir%\system\urttemp on Windows 98 and Windows Me) if it exists.
3. Re-run the .NET Framework setup that failed originally.

Because the .NET Framework ships as part of the OS for Windows XP Tablet PC Edition, Windows XP Media Center Edition and Windows Server 2003, it is dangerous to delete mscoree.dll from the system directory because it can affect OS functionality.  In some cases, it is impossible to delete this file because it is under system file protection.  The following steps will fix most cases of a 1935 error with HRESULT -2147319761 on these OS types:

1. Rename the file %windir%\system32\mscoree.dll.  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Extract the file mscoree.dll from netfx.cab in the i386 directory of your original OS installation media or network path.
3. Copy mscoree.dll from netfx.cab to %windir%\system32.
4. Re-run the .NET Framework setup that failed originally.

NOTE: This error should not ever be seen for .NET Framework v1.1 on Windows Server 2003 because .NET Framework v1.1 shipped as part of the operating system, and the Windows Installer package for this version should block if a user attempts to install it on this OS.  This error should also not ever be seen for .NET Framework v1.0 on Windows XP Tablet PC or Media Center editions because .NET Framework v1.0 shipped as part of the OS.

J# Redistributable Package, Language Packs, and Visual Studio

In most cases, a 1935 error with HRESULT -2147319761 during installation of the J# redistributable package, .NET Framework or J# redistributable package languages packs, or Visual Studio will require a repair of the highest version of the .NET Framework currently installed on the machine.

If you have the .NET Framework installed via a Windows Installer MSI package, you can perform the following steps to repair the .NET Framework:

1. Rename the file %windir%\system32\mscoree.dll (or %windir%\system\mscoree.dll on Windows 98 and Windows Me).  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Delete the folder %windir%\system32\urttemp (or %windir%\system\urttemp on Windows 98 and Windows ME) if it exists.
3. If you are trying to repair the .NET Framework v1.0, locate the file repair.htm in the folder %windir%\Microsoft.NET\Framework\v1.0.3705 and follow the instructions on that page.
4. If you are trying to repair the .NET Framework v1.1, locate the file repairRedist.htm in the folder %windir%\Microsoft.NET\Framework\v1.1.4322\1033 and follow the instructions on that page.
5. Rerun the setup that failed originally.

If you have the .NET Framework installed as part of the operating system and find that it needs to be repaired, you should first try the following steps:

1. Rename the file %windir%\system32\mscoree.dll.  Also, please take note of what the version of this file is to aid in tracking down why this error is occurring.
2. Extract the file mscoree.dll from netfx.cab in the i386 directory of your original OS installation media or network path.
3. Copy mscoree.dll from netfx.cab to %windir%\system32.
4. Re-run the setup that failed originally.

If these steps fail, you may need to rerun OS setup to trigger a repair of the entire .NET Framework.

What to do if the above troubleshooting steps do not work

In some cases, the 1935 error with HRESULT -2147319761 can be caused by orphaned registry keys from a different version of the .NET Framework, and replacing mscoree.dll or repairing the .NET Framework will not fix the error.  In these cases, try to look in the registry key HKLM\Software\Microsoft\.NETFramework and look for any sub-keys or values containing version numbers of previous builds of the .NET Framework.  If any are present, rename or delete them, then try to rerun the previously failing setup.

In addition if you are trying to install the .NET Framework v1.0, delete the following registry keys and any sub-keys and values, if present:

·         HKLM\Software\Microsoft\NET Framework Setup\Full

·         HKLM\Software\Microsoft\NET Framework Setup\Product

NOTE:  Be very careful when directly modifying the registry in this way, particularly on operating systems where the .NET Framework ships as part of the OS.  It is always recommended to backup your registry prior to making direct modifications to it so that you can roll back to a known state.

If there are no orphaned registry keys or deleting orphaned keys did not fix the problem, it may be necessary to completely uninstall and reinstall the highest version of the .NET Framework on the machine.  This can be done by locating the entry in the Add/Remove Programs control panel applet and choosing to uninstall, then reinstalling from the original source.

If uninstalling and reinstalling also does not work, it may be necessary to perform a manual removal of the highest version of the .NET Framework on the machine.

NOTE: Manual removal is not recommended and can be very dangerous if the .NET Framework shipped as part of the operating system.  In these cases, it is recommended to repair the OS by rerunning OS setup.

Additional Information

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;308096

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;824643

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;830646

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;839547

·         http://support.microsoft.com/default.aspx?scid=kb;en-us;872904  

A while back, I posted a set of instructions that can be used to try to resolve .NET Framework installation issues in case other troubleshooting steps listed on my blog, in knowledge base articles or elsewhere do not work.  Those steps are out of date now because several new versions of the .NET Framework have been released since then, a new verification tool has been released and there are some other helpful steps that are not listed there.  Instead of trying to update those steps in that old post, I decided to write a replacement post that contains the new information.

I have created a .NET Framework troubleshooting guide that contains links to information about various types of .NET Framework installation issues that we've seen over the years.  However, the links in that article do not cover all possible errors, and there are likely some scenarios that cannot be resolved by any of the workarounds listed in that article.

If you run into an issue installing or using the .NET Framework or a .NET Framework hotfix or service pack, and the links in the .NET Framework troubleshooting guide do not help, I usually suggest trying the following steps in order to get your system back into a known state and then re-installing the .NET Framework and any hotfixes or service packs that apply to it:

1. Go to the Add/Remove Programs control panel and attempt to repair the version of the .NET Framework that is causing problems on the system
   
   Note: There are a few versions of the .NET Framework that are installed as OS components, and therefore will not appear in Add/Remove Programs.  The .NET Framework 1.0 is an OS component on Windows XP Media Center and Tablet PC Editions.  The .NET Framework 1.1 is an OS component on Windows Server 2003.  The .NET Framework 2.0 and 3.0 are OS components on Windows Vista and Windows Server 2008.  The .NET Framework 2.0, 3.0 and 3.5 are OS components on Windows 7.  The .NET Framework 2.0, 3.0, 3.5 and 4.5 are OS components on Windows 8.
   
   
2. If a repair does not help, then try to download and run the .NET Framework Repair Tool to see if it can find and fix any issues with the .NET Framework on your computer.
3. If the repair tool does not help, then go to the Add/Remove Programs control panel and attempt to uninstall the version of the .NET Framework that is causing problems on the system
4. If uninstall still fails from Add/Remove Programs, download the .NET Framework cleanup tool and choose to remove the version of the .NET Framework that is causing problems on your system
5. Download and install the version of the .NET Framework that you cleaned up in step 2 or 3.  Here are some download links for various versions of the .NET Framework:
   
   .NET Framework 1.0
   .NET Framework 1.1
   .NET Framework 2.0
   .NET Framework 3.0
   .NET Framework 3.5
   .NET Framework 4
   .NET Framework 4.5
   
   Note - if you are having trouble installing the .NET Framework 2.0, 3.0 or 3.5, I recommend trying to installing the .NET Framework 3.5 SP1 because it will install the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes, and these versions contain additional fixes not in the original 2.0, 3.0 or 3.5 releases.  Plus, 3.5 SP1 will automatically uninstall any older versions of 2.0, 3.0 or 3.5 that are on your system, so you can save some time by not trying to install a version of the .NET Framework that 3.5 SP1 is going to uninstall during its install process.
   
   
6. (optional) Download and run the .NET Framework verification tool to double-check that the version of the .NET Framework that you installed in step 2 installed correctly
7. Download and install any service packs or hotfixes for the version of the .NET Framework you just installed by running the setup package directly instead of using Windows Update.  Running it directly will allow the service pack or hotfix to display error dialogs (whereas, Windows Update will automatically suppress any error dialogs).  Here are some download links for various .NET Framework service packs:
   
   .NET Framework 1.0 SP3
   .NET Framework 1.1 SP1
   .NET Framework 3.5 SP1 family update; there are several versions depending on what OS you are running - Windows XP and Server 2003 x86, Windows XP and Server 2003 x64, Windows Vista and Server 2008 x86, Windows Vista and Server 2008 x64
   
   Note - the .NET Framework 2.0 SP1 and SP2 and 3.0 SP1 and SP2 are slipstream replacements for the original versions of 2.0 and 3.0, and the .NET Framework 3.5 SP1 is a slipstream replacement for the original version of 3.5.  You do not need to install 2.0 then SP1 and SP2, 3.0 then SP1 and SP2, or 3.5 then SP1 as separate steps like you do for 1.0 and 1.1.  Instead you can skip directly to installing 2.0 SP2, 3.0 SP2 and 3.5 SP1.

.NET Framework setup log file locations

If none of the above help, then it can be useful to look at the .NET Framework setup log files for more in-depth troubleshooting.  Here are links to information about the log files created by each version of the .NET Framework:

• .NET Framework 2.0
• .NET Framework 2.0 SP1 and SP2  
• .NET Framework 3.0
• .NET Framework 3.0 SP1 and SP2
• .NET Framework 3.5 and 3.5 SP1

The .NET Framework 1.0 and 1.1 are not listed above because they do not create log files automatically.  You need to use steps like the ones listed in this blog post in order to create log files for .NET Framework 1.0 and 1.1 setup.

.NET Framework setup packaging notes that affect uninstalls

The .NET Framework 1.0, 1.1 and 2.0 are all side-by-side versions that can be installed and uninstalled without affecting the others.  This means that if you are running into an issue in the .NET Framework 2.0, for example, you do not necessarily need to remove the .NET Framework 1.0 and 1.1 in addition to removing 2.0.

The .NET Framework 3.0 is an add-on that requires the .NET Framework 2.0 to be present as a prerequisite.  If you have the .NET Framework 3.0 installed, you will not be allowed to uninstall the .NET Framework 2.0 until you first uninstall the .NET Framework 3.0.

The .NET Framework 3.5 is an add-on that requires the .NET Framework 2.0 SP1 and the .NET Framework 3.0 SP1 to be present as prerequisites.  If you have the .NET Framework 3.5 installed, you will not be allowed to uninstall the .NET Framework 3.0 SP1 or 2.0 SP1 until you first uninstall the .NET Framework 3.5.  You will also not be allowed to uninstall the .NET Framework 2.0 SP1 until you first uninstall the .NET Framework 3.5 and the .NET Framework 3.0 SP1.

The .NET Framework 3.5 SP1 is an add-on that requires the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 to be present as prerequisites.  If you have the .NET Framework 3.5 SP1 installed, you will not be allowed to uninstall the .NET Framework 3.0 SP2 or 2.0 SP2 until you first uninstall the .NET Framework 3.5 SP1.  You will also not be allowed to uninstall the .NET Framework 2.0 SP2 until you first uninstall the .NET Framework 3.5 SP1 and the .NET Framework 3.0 SP2.

<update date="4/22/2008"> Added information and a link to the Microsoft .NET Framework 2.0 Registration Correction Tool, which should be used before resorting to trying the cleanup tool for .NET Framework 2.0 issues. </update>

<update date="9/21/2008"> Added a link to download the .NET Framework 3.5 SP1 now that it has shipped. </update>

<update date="9/23/2008"> Updated the link to the .NET Framework 2.0 Registration Correction Tool to point to the official knowledge base article now that it has been published. </update>

<update date="1/25/2009"> Added a link to the standalone .NET Framework 2.0 SP2 installer. </update>

<update date="2/25/2009"> Added links to the .NET Framework 3.5 SP1 family update installers. </update>

<update date="3/23/2009"> Fixed broken link to the .NET Framework cleanup tool. </update>

<update date="3/28/2009"> Fixed broken link to the .NET Framework setup verification tool. </update>

<update date="12/2/2010"> Added download link for .NET Framework 4. </update>

<update date="9/8/2012"> Added download link for .NET Framework 4.5 and fixed broken links to other versions of the .NET Framework. </update>

<update date="1/24/2013"> Added a link to the .NET Framework Repair Tool. <update>

NOTE - this blog post was originally written for the .NET Framework 2.0 and 3.0 on Windows Vista.  Since then, Windows 7 has shipped, and it includes the .NET Framework 2.0, 3.0 and 3.5 as OS components.  The steps in this blog post apply equally to Windows 7 as well. 

Since the Windows Vista public launch in January 2007, I have been receiving questions about how to repair the .NET Framework 2.0 and 3.0 to try to resolve various bugs.  As I previously described here, the 2.0 and 3.0 versions are installed as OS components on Windows Vista and do not appear in the Programs and Features (formerly known as Add/Remove Programs) control panel.

Many of the customers I have heard from have tried to use the .NET Framework cleanup tool, but it does not list the .NET Framework 2.0 as a valid removal option when it is run on Windows Vista.  This is by design - the cleanup tool does not offer the option to remove any version of the .NET Framework that is an OS component on the OS it is being run on.

Windows Vista OS files and registry information (including those that are a part of the .NET Framework 2.0 and 3.0) are protected by Windows Resource Protection (WRP) in Windows Vista.  This means that only the OS installer service (named TrustedInstaller) has permission to modify/remove these files or registry keys unless you specifically take ownership of the files/keys and add additional user accounts to the access permission list (which you should not need to do except in extraordinary circumstances).

If you run into problems using .NET Framework applications on Windows Vista, and you suspect that files or registry entries that are a part of the .NET Framework 2.0 or 3.0 are corrupt, you can use the instructions listed below to attempt to repair them.

Repairing .NET Framework 2.0/3.0 files on Windows Vista

You can use the following steps to repair the files that are a part of the .NET Framework 2.0 and 3.0 on Windows Vista and Windows Server 2008:

1. Click on the Start menu, choose All Programs, then Accessories, then right-click on the Command Prompt item and select Run as administrator
2. Click Continue to authorize opening a command prompt with administrative privileges
3. Run this command in the cmd prompt: sfc /scannow
4. The cmd prompt should list text stating "Beginning system scan. This process will take some time."
5. Wait for the scan to complete (this can take several minutes so be patient).  This command will scan all protected system files and replace incorrect versions with correct Microsoft versions
6. When the scan completes, the SFC tool will indicate whether or not it found any problems and whether or not it was able to fix them
7. If any errors are reported that SFC was unable to fix, there are steps in this knowledge base article and this how-to guide that explain how to locate and attempt to fix the errors

Repairing .NET Framework 2.0/3.0 registry entries on Windows Vista

Unfortunately, there is not an easy way of repairing the registry keys/values that are installed by Windows Vista like there is for files.  If you want to try to repair the registry keys/values that are a part of the .NET Framework 2.0 and 3.0, you will need to run Windows Vista OS setup again and repair the OS.

<update date="9/8/2008"> Added a link to a knowledge base article with instructions that can be used to fix errors reported by sfc.exe on Windows Vista and Windows Server 2008. </update>

<update date="10/7/2008"> Clarified what SFC does behind the scenes in more detail. </update>

<update date="8/9/2009"> Fixed broken link to knowledge base article in step 7. </update>

<update date="3/10/2010"> Added a note about Windows 7. </update>

In response to the blog article I posted last week where I provided a link to a .NET Framework manual cleanup tool, I got some questions about whether or not a comparable version is available for cleaning up the .NET Framework 2.0.  I am currently working on a couple of small work items in the code for the tool to enable it to work with 2.0, but in the meantime I wanted to post some manual steps.  I know there have been a lot of uninstall/reinstall issues because we have released an alpha, a beta and numerous Community Tech Preview (CTP) versions and not all of them will uninstall completely cleanly in order to allow a future beta version of 2.0 to install correctly.

The following steps will help resolve .NET Framework 2.0 installation failures/hangs in most cases. Before proceeding please note these important caveats:

• These steps will only work for the .NET Framework 2.0 installed by dotnetfx.exe (the MSI-based setup).  There is a version of .NET Framework 2.0 that is installed as part of the OS if you are running any pre-release builds of Windows codename Longhorn.  You should not use these steps on Longhorn.
• These steps will damage the .NET Framework 1.0 or 1.1 if you have either of these versions installed on your computer.  This is because you are instructed to rename the file mscoree.dll that is shared by all versions of the .NET Framework.   If you have 1.0 or 1.1 installed, you will need to immediately install a later build of .NET Framework 2.0 to update mscoree.dll or perform a repair of the .NET Framework 1.0 or 1.1.  To repair .NET Framework 1.0 or 1.1, go to the Add or Remove Programs control panel, click on the link for support information, and then click on the Readme link.
• If you are running Windows Server 2003, Windows XP Media Center Edition or Windows XP Tablet PC Edition, there is a version of the .NET Framework that ships as part of the OS.  In those situations, you cannot repair by using the instructions in Add or Remove Programs under the readme link.  In those scenarios it is strongly recommended that you immediately install .NET Framework 2.0 to provide an updated version of mscoree.dll.  If that is not an option, you must repair your OS to fix the issue.

Steps to clean up a machine to fix a failed .NET Framework 2.0 installation:

• Using Add or Remove Programs, locate any versions of the .NET Framework 1.2 or 2.0 and choose Remove to uninstall them
• Using regedit, navigate to HKLM\Software\Microsoft\.NETFramework and delete any keys and values that have 1.2 or 2.0 in it, including keys/values that are in subkeys underneath .NETFramework.
• Using regedit, navigate to the sub-hive HKLM\Software\Microsoft\.NETFramework\Policy and delete any key or value that has 1.2 or 2.0 in it. 
• Using regedit, navigate to HKLM\Software\Microsoft\ASP.NET and delete any key or value that has 1.2 or 2.0 in it, including keys/values that are in subkeys underneath ASP.NET. 
•  Right-click on My Computer and choose Manage. Expand Computer Management (Local), then Local Users and Groups, then click on the Users folder. In the right-hand pane, right-click on the ASPNET user account and choose Delete to remove it.
•  Go to %windir%\assembly and delete anything with *1.2* or *2.0* in the folder name. Delete the GAC_32 and GAC_MSIL folders as well.
  
  You can not view the contents of %windir%\assembly in Windows Explorer when the .NET Framework is installed.  In order to view the contents, you will need to set the following registry value and reopen Windows Explorer
  
  Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
  Value name: DisableCacheViewer
  Data type: REG_DWORD
  Value data: 1
  
  Note: You should remove the DisableCacheViewer value after you complete this step because this is only used for debugging purposes.
  
  
• Go to %windir%\Microsoft.NET\Framework and delete any folders named v1.2.* or v2.0.* along with all of the files and subfolders they contain.  You may get errors when trying to delete some of the files because they are in use.  In most cases, rebooting the machine and trying again will work.  If not, you can rename the files to be <filename>.old and then delete them after a future reboot.
•  Rename %windir%\system32\mscoree.dll to mscoree.dll.old.
•  After doing all of this, try to install the previously failing version of the .NET Framework 2.0.

If you have any trouble getting these steps to work correctly please let me know.  Also stay tuned for a future post once I get the cleanup tool updated to work with .NET Framework 2.0 and post it for download.

I’ve heard from a few customers over the past few days who have had trouble installing the new 2009 version of TurboTax.  In the cases I’ve heard about so far, the installer for TurboTax reports that the .NET Framework 3.5 SP1 is not correctly installed and instructs the user to re-install it.  Unfortunately, attempts to uninstall and re-install the .NET Framework did not help in some of these cases.

Behind the scenes, it appears that TurboTax setup is running a verification process that is similar to the .NET Framework setup verification tool.  This verification process checks that files and registry keys that should be installed by the .NET Framework 2.0, 3.0 and 3.5 setup packages are correctly installed on the computer.  It is possible for the .NET Framework to be installed but for some of the files and/or registry values to have been removed by some other program (such as a registry cleaner tool, a disk cleanup tool, or even manual deletion by the user).

If TurboTax reports a problem with the .NET Framework 3.5, it suggests that you try to uninstall and re-install the .NET Framework 3.5.  However, the exact steps needed to do this depend on what version of Windows you are running, and this has ended up causing confusion for the users I’ve heard from so far because the different steps aren’t very well documented in general.

For Windows XP and Windows Server 2003

If you are running a version of Windows before Windows Vista (such as Windows XP or Windows Server 2003), then in most cases, you can use the entry in Add/Remove Programs to repair the .NET Framework 3.5 or 3.5 SP1.  If that doesn’t help, then you can use the steps in this blog post to remove and then re-install the .NET Framework 3.5 SP1.

For Windows Vista or Windows Server 2008

If you are running Windows Vista or Windows Server 2008, then the .NET Framework 2.0 and 3.0 are installed as OS components.  As a result, the repair steps are more complicated.  You will need to try the following:

1. Try to repair the .NET Framework 3.5 or 3.5 SP1 using the entry in the Programs and Features control panel.
2. If that doesn’t help, try to use the steps in this blog post to remove and re-install the .NET Framework 3.5 SP1.
3. If the above steps do not help, run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

For Windows 7

If you are running Windows 7, then the .NET Framework 2.0, 3.0 and 3.5 are all installed as OS components, and you cannot remove or re-install these versions using the Programs and Features control panel.  On Windows 7, this is your only built-in repair option:

Run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

What to do if the above doesn’t help

Unfortunately, sfc.exe will only repair files that are protected by Windows Resource Protection.  For the .NET Framework, only binary files that can be repaired using sfc.exe.  Non-binary files (such as .config files) and registry keys cannot be repaired using sfc.exe.  For non-binary files, the only options are to manually replace them with files from other computers or to repair your OS.  For registry keys, the only options are to manually re-create them in regedit.exe or to repair your OS.

Here are some steps I’ve been able to use to narrow down the exact missing files and/or registry keys that cause TurboTax setup to think that the .NET Framework 3.5 SP1 is not correctly installed:

1. Download and run the TurboTax verification utility from http://turbotax.intuit.com/support/kb/installing/errors/7659.html
2. When the utility finishes, click the button named Save Logs on Desktop
3. Go to your desktop and open the zip file named TurboTax2009UtilityLogFiles*.zip
4. Find the file named *_TurboTax 2009 Utility – *.log (where the first * is a date-time stamp and the 2nd * is a version number)
5. Search for the string ****ERROR**** in this log file and take note of the files and/or registry keys that it reports are missing

From the information in this log file, it is usually possible to figure out what files and/or registry keys need to be manually repaired on the computer.  So far, the cases I’ve seen reported missing .config files and we have been able to get TurboTax setup to run correctly after copying the .config files from another computer or downloading them from here and putting them in the locations reported in this log file.

If you run into problems getting TurboTax 2009 setup to run correctly due to errors related to the .NET Framework 3.5, I encourage you to try the steps above.  If they don’t help, please don’t hesitate to leave a comment on my blog and/or contact me and I’ll try to help as best as I can.

<update date="2/3/2010"> Added a link to a zip file that I posted with the .config files that have been causing the majority of the issues with TurboTax setup that I've seen so far. </update>

I have heard of several folks running into issues playing protected content (such as purchased songs/movies, or HBO television shows) after installing Update Rollup 2 for Media Center 2005.  As I described here, Update Rollup 2 installs an updated Digital Rights Management (DRM) redistributable package.  We are still investigating reports of content protection problems in order to identify root causes and provide fixes.  In the meantime, I wanted to offer some suggestions.

First, I highly encourage you to backup your licenses for protected content prior to installing Update Rollup 2.  You can do the following to backup licenses:

1. Open Windows Media Player
2. On the Tools menu, select Manage Licenses
3. (optional) To change the backup location, click Change and then select a location where you want to store backup copies of your licenses
4. Click Back Up Now

Note - there are some license issuers that will not allow you to store backup copies of their license files, so this backup process may not back up all licenses on your system.

Second, if you have already installed Update Rollup 2 without backing up licenses, and you are now unable to play protected content there is a knowledge base article that describes how to reset the DRM system on your computer.  There is one step that should be added to that article that is not there currently - before deleting the Windows Media DRM folder, you need to close any programs that might be holding files in that folder in use.  Specifically, make sure to close Media Player and Media Center, and run the command net stop ehRecvr to stop the Media Center Recording service immediately prior to trying to delete that folder.

Resetting DRM restores the ability to play protected content in most cases.  However, if you use these steps to reset the DRM system and do not have backup copies of your licenses, you will lose the ability to play any previously acquired protected content.  If you have content that you do not want to lose, I would encourage you to wait until we can identify and post a fix.  If you are not concerned about any previous content, I encourage you to try out the steps in the KB article - they are semi-complicated, but I have used them in the past and had some success.

There is a new hotfix available as of 4/14/2006 that is designed to fix protected content playback issues in Update Rollup 2 for Media Center 2005.  Please try out this hotfix if you have DRM/protected content playback issues in Update Rollup 2.

<update date="11/4/2005"> Added an additional step for the knowledge base article - stopping any processes that may have DRM files in use </update>

<update date="4/15/2006"> Added a link to a new DRM hotfix that is now available in case people find and read some of my older blog posts in an attempt to fix this type of issue </update>

There have been a few reports so far from customers who have installed Update Rollup 2 for Media Center 2005 and have had problems getting their infrared (IR) receivers or devices such as remote controls or wireless keyboards to work correctly afterwards.  Update Rollup 2 setup installs an updated set of IR drivers (also shipped independently as KB888795) that have caused some sporadic issues.  Here is a list of the workarounds we have seen be successful so far to resolve IR receiver/remote control issues after installing Update Rollup 2:

1.  The IR receiver appears to be installed correctly but pressing buttons on the remote does not do anything

In this scenario, it is possible that the remote control has been configured to broadcast on a channel range that was supported previously but has since been removed.  You can use the steps that I previously posted here to reconfigure your remote control to broadcast on a different channel to resolve this issue

2.  One or more of the IR drivers is configured incorrectly in Device Manager

In this scenario, if you look in Device Manager (by going to the Start menu, choosing Run and typing devmgmt.msc), you will see yellow exclamation points next to one or more items in the Human Interface Devices category.  The following steps will resolve this issue in most cases:

1. Go to the Start menu, choose Run and type devmgmt.msc
2. Expand the Human Interface Devices category
3. Right-click on each of the items with eHome Infrared Transceiver in the name and choose Uninstall
4. Unplug the IR device from the computer and wait for approximately 30 seconds
5. Plug the IR device back into the computer and wait for Windows plug-and-play detection to kick in and re-install the device

3.  Some remote control buttons (number keys, arrows, enter) fail to function, while other buttons work as expected

We have not yet been able to reproduce this scenario in our test lab, but we have seen this set of steps resolve this issue on some customer machines so I wanted to post it here in case someone runs into a similar problem:

1. Delete the file named %windir%\inf\keyboard.pnf.  Please note that the correct file to delete ends in PNF - do not delete keyboard.INF.
2. Go to the Start menu, choose Run and type devmgmt.msc
3. Expand the Human Interface Devices category
4. Right-click on each of the items with eHome Infrared Transceiver in the name and choose Uninstall
5. Unplug the IR device from the computer and wait for approximately 30 seconds
6. Plug the IR device back into the computer and wait for Windows plug-and-play detection to kick in and re-install the device

4.  If none of the above suggestions work

There are some cases that we have seen where none of the above suggestions work.  A customer posted a comment indicating that it sometimes helps to short the Media Center remote control to forcibly reset it.  You can see more information about how to do that in this blog post.

<update date="12/29/2005"> Added a link to a new post I created with a description of how to short a remote control </update>

I have previously posted command lines that can be used to install, repair and uninstall the versions of the .NET Framework in silent mode and unattended mode.  Now that the .NET Framework 4 has shipped, I wanted to post an equivalent set of steps to install, repair and uninstall the .NET Framework 4 Client Profile and Full.

The .NET Framework 4 uses a different setup chainer than in previous versions of the .NET Framework.  As a result, the command lines are somewhat different than in previous releases.  There are also a few differences in how the repair and uninstall processes work that I wanted to call out specifically:

• There are different repair and uninstall command lines for 32-bit and 64-bit versions of the .NET Framework 4
• The .NET Framework 4 includes both a client profile and a full version.  Uninstalling the full version requires 2 steps – one to uninstall the extended component and another to uninstall the client profile.

.NET Framework 4 product family

• Download location
• Deployment guide with silent install command lines

.NET Framework 4 Client Profile (32-bit) – silent repair

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /q /norestart

.NET Framework 4 Client Profile (32-bit) – unattended repair

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /passive/norestart

.NET Framework 4 Client Profile (32-bit) – silent uninstall

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /q /norestart

.NET Framework 4 Client Profile (32-bit) – unattended uninstall

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /passive /norestart

.NET Framework 4 Client Profile (64-bit) – silent repair

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /q /norestart

.NET Framework 4 Client Profile (64-bit) – unattended repair

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /passive /norestart

.NET Framework 4 Client Profile (64-bit) – silent uninstall

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /q /norestart

.NET Framework 4 Client Profile (64-bit) – unattended uninstall

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /passive /norestart

.NET Framework 4 Full (32-bit) – silent repair

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /q /norestart

.NET Framework 4 Full (32-bit) – unattended repair

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /passive /norestart

.NET Framework 4 Full (32-bit) – silent uninstall

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Extended\setup.exe /uninstall /x86 /x64 /ia64 /parameterfolder Extended /q /norestart

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /q /norestart

.NET Framework 4 Full (32-bit) – unattended uninstall

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Extended\setup.exe /uninstall /x86 /x64 /ia64 /parameterfolder Extended /passive /norestart

%windir%\Microsoft.NET\Framework\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /passive /norestart

.NET Framework 4 Full (64-bit) – silent repair

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /q /norestart

.NET Framework 4 Full (64-bit) – unattended repair

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /passive /norestart

.NET Framework 4 Full (64-bit) – silent uninstall

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Extended\setup.exe /uninstall /x86 /x64 /ia64 /parameterfolder Extended /q /norestart

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /q

.NET Framework 4 Full (64-bit) – unattended uninstall

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Extended\setup.exe /uninstall /x86 /x64 /ia64 /parameterfolder Extended /passive /norestart

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /uninstall /x86 /x64 /parameterfolder Client /passive /norestart 

<update date="6/1/2010"> Fixed incorrect command lines for uninstall of the .NET Framework 4 extended. </update>

There is a trick I use very often when trying to figure out why an MSI-based setup is failing that I wanted to share with everyone.  I believe it is commonly known among setup developers and people who have to troubleshoot failed setups, but I could not find any "official" documentation for it.  This trick helps narrow down the root cause of error code 1603, which is a generic catch-all error code that means "fatal error during installation".  The 1603 error code is returned when any action fails during an installation, and most commonly it indicates that one of the custom actions in the MSI failed.

When I encounter a failed setup with return code 1603, here are the steps that I follow:

1. Re-run the setup with verbose logging enabled using steps similar to those that I listed here (if there is not already a verbose log file available).  Those steps will generate a verbose log file named msi*.log in the %temp% directory the next time the setup package is executed.
   
   Important note - some MSI-based setups, including the .NET Framework 2.0, 3.0, 3.5 and higher and Visual Studio, will not create log files named %temp%\msi*.log even if using the instructions listed below.  Please see this blog post for more details about why that is the case and also for a list of some products that I know of that use different log file creation logic and the locations of the log files that they create.
   
   
2. Open the verbose log in a text editor such as notepad and search for the string "return value 3".  In nearly all cases, this takes me to the section in the verbose log that lists the action that failed that initially caused setup to rollback.
3. Review the contents of the log file immediately above the "return value 3" string to determine which custom action or standard action failed.
4. Depending on which action is failing, I will proceed to more detailed debugging from here

I find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for "return value 3" ends up helping speed this process up in nearly all cases.  Of course, it does not work in 100% of scenarios.  Notably, if you are running setup on a non-English version of Windows, the string "return value 3" is written to the log file in the language of the operating system instead of in English, so string searches will not work.

Also note that there is an MSI verbose log parsing tool in the Windows Installer PSDK that is also very useful in locating errors inside verbose log files.  You can read more about this parsing tool (called wilogutl.exe) by clicking here.  This tool is more thorough in identifying errors, but most often I end up not using it because it is faster to open the log in notepad and do a string search than it is to load up the parsing tool, browse to the log file, wait for it to parse the whole log and then read the output it produces.

<update date="1/21/2009"> Added a caveat to these instructions indicating that some setups create their own verbose logs and enabling verbose logging using the Windows Installer logging registry keys will not work as expected for those setups. </update>

Question:

I am using the Visual Studio setup/deployment project to create an MSI to install my application.  I would like to add some functionality to this MSI that does not appear to be supported in the Visual Studio IDE (such as modifying the default install path based on a registry value on the system).  I know how to do this by directly editing the MSI, but I don't want to have to manually edit the MSI each time I build.  Are there any other options I can use in this scenario?

Answer:

There is a limited set of customizations you can make to an MSI in the Visual Studio IDE UI for a setup/deployment project.  By limited, I mean that there are a lot of features that are natively supported in Windows Installer MSI format that are not exposed for customization in the Visual Studio IDE.  Examples include changing the default install path based on a registry value, advanced setup UI features such as updated banner text or a "launch my product" checkbox on the final screen, creating custom actions that reference external executable files, or setting various custom action attributes (among other things).

If you would like to automate the ability to customize an MSI that is built by the Visual Studio setup/deployment project in a way that is not currently supported by the UI in the Visual Studio IDE, you can write a script that accesses the Windows Installer object model to perform these customizations.  Then you can create a post-build step in your Visual Studio setup/deployment project to run your script after the MSI has been built so that the final result each time you build will be an MSI package with your additional customizations made to it.

As an example, you can use the sample script at this location to add a checkbox to your MSI's setup UI that will let the user choose whether or not to launch your product after setup finishes.

If you would like to include this script as a post-build step in a Visual Studio setup/deployment project, you can use the following steps:

1. Download the sample script and extract the contents to the directory that contains the Visual Studio setup project you are working on.
   
   Note: You should end up with the file EnableLaunchApplication.js in the same directory as the .vdproj file for your setup project.  The rest of these steps will not work correctly if you do not put EnableLaunchApplication.js in the correct location, so be careful about this step.
   
   
2. Open the file EnableLaunchApplication.js in a text editor such as notepad, locate the variable at the top of the file that is set to the value WindowsApplication1.exe, and change it to the name of the EXE that is in your setup that you want to launch when the MSI is done installing
3. Open the project in Visual Studio
4. Press F4 to display the Properties window
5. Click on the name of your setup/deployment project in the Solution Explorer
6. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
7. Click on the "..." button to display the Post-build Event Command Line dialog
8. Copy and paste the following command line into the Post-build event command line text box:
   
   cscript.exe "$(ProjectDir)EnableLaunchApplication.js" "$(BuiltOuputPath)"
   
   
9. Save your project
10. Build your project in Visual Studio

Note that the quotation marks in the command line in step 8 are very important because the script will not work correctly without them.  Make sure to double-check that you have put quotes in the proper places.

You can find another example script that will update the MSI setup UI banner text in this MSDN forum post.

<update date="8/23/2006"> Updated the steps needed to configure post-build commands in the Visual Studio UI because they are different for setup projects than for other Visual Studio project types </update>

<update date="5/31/2007"> Updated steps to mention the need to rename WindowsApplication1.exe to the name of the EXE in each project that you want to launch.  Also fixed a typo in the variable BuiltOuputPath. </update>

<update date="8/26/2008"> Updated steps to be more specific about what folder to save EnableLaunchApplication.js to </update>

<update date="3/15/2009"> Fixed broken link to the sample script </update>

<update date="7/26/2012"> Fixed bad HTML formatting and misnumbered steps </update>

Since I posted the instructions for gathering setup log files for Update Rollup 2 for Media Center 2005 and asked folks to send the logs to me, I have gotten several sets of logs.  I'm still looking through some of the issues to try to figure them out (and I apologize for the slow replies to those of you who have not heard back from me yet).  There is one issue that I've now seen on multiple customer machines that I wanted to post a workaround for in case anyone else runs into it in the future.

What are the symptoms of this issue?

For this particular problem, customers have reported the following types of problems while using Media Center after upgrading to Update Rollup 2:

• A Component Registration Failure error appears while trying to navigate to My TV.  The text of the error message states "Some of the files needed to play radio or video are missing or corrupt. Media Center component registration may have failed."
• A Critical Process Failure error appears while trying to configure an internet connection during first run.  The text of the error message states "A critical Media Center process has unexpectedly failed. If problems persist, please restart your machine and try again, or contact technical support. Code: 3"
• A Tuner Not Found error appears while trying to setup a TV signal during first run
• Errors related to the Media Center Guide in the application event log

How do I know if this issue is the one affecting my machine?

The machines I have seen that have had these problems so far have had errors logged in %windir%\medctroc.log.  This log is appended to during every Media Center setup action, so you have to find the section that corresponds to the registration that happens at the end of Update Rollup 2 setup.  To find this, you can search for the string 5.1.2710.2732.  There should be multiple instances of this string in this log file.  You will need to find the entry that is followed a few lines later by a line stating Will run in registration mode.

Once you have found the Update Rollup 2 registration section, look for the group of commands labeled Removing existing native assemblies...  In each of the cases I have seen so far, there are entries in this section like the following:

Executing line "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\ngen.exe /nologo /delete ehiwmp"
 Warning: Process Return Value is 0xc0000139 --> (null)
 Error: Failed to apply command to ehiwmp (return value: 0xc0000139).

Then you should see another entry in the log file during this same registration session that states:

Encountered errors during registration of Windows Media Center.  Please see {C:\WINDOWS\medctroc.Log} for details.

How can I workaround this issue?

If you have the above entries in your %windir%\medctroc.log file, you can do the following to repair your computer:

1. Download and reinstall the .NET Framework 1.1 SP1
2. Go to the Start menu, choose Run and type cmd.
3. From the cmd prompt, run %windir%\ehome\medctrro.exe /o /p RunOnce to re-run Update Rollup 2 registration code.  This command will not display any UI, so you will have to keep track of the process in Task Manager to know for sure when it completes.
4. After the process in step 3 completes, restart your computer to complete the Media Center registration process.

What is the root cause of this issue?

There are a couple of problems that cause this issue.  The first is a logic problem with the setup registration program (%windir%\ehome\medctrro.exe).  When it encounters an error like the NGEN error listed above, it continues until it is done processing managed assemblies but then it stops without performing the rest of the registration steps.  This means that the machine is left in the state where new assemblies from Update Rollup 2 are added to the GAC, but the ehSched and ehRecvr services and the ehRec and ehMsas executables are unregistered.  These services and COM servers are used for a lot of functionality inside of Media Center, particularly TV.  Therefore if they are left in an unregistered state, MCE fails in many places.

The second issue is that the command to run NGEN is failing with an unexpected error code 0xc0000139 in some cases.  This error code means "entry point not found" but I have not been able to reproduce this on one of my test machines so I don't understand exactly why this error is appearing.  I have asked a couple of folks who hit this problem to try running the NGEN commands directly to see if they give more descriptive error messages.  I will update this blog post when I know more about the root cause of NGEN failing in these scenarios.

<update date="10/20/2005"> We have found one root cause of this type of error, and I have posted a description and a simpler workaround for this error in this blog post </update>

<update date="10/30/2005"> It appears that the link to the simpler workaround isn't being found in the update text, so I've updated the workaround to contain the steps from my newer blog post to avoid confusion </update>

<update date="1/12/2010"> Added a note about rebooting at the end of the registration process. </update>

If you try to install the Windows Phone SDK 7.1 or XNA Game Studio on Windows 8, you may encounter an XNA Game Studio setup failure.

How to work around this issue

If you run into this issue, here are steps that you can use to work around it:

1. Download and install the latest version of the Games for Windows – LIVE Redistributable from http://www.xbox.com/en-US/LIVE/PC/DownloadClient
2. If you are installing the Windows Phone SDK 7.1, re-run setup and choose to repair it.  This will re-run the previously failing XNA Game Studio installers and they should install correctly this time.
3. If you are install a standalone XNA Game Studio product, re-run setup and it should install correctly this time.
4. If you are planning to do Windows Phone development, you should also install the Windows Phone SDK 7.1.1 Update after installing the Windows Phone SDK 7.1.  This update fixes an issue that prevents the emulator in the Windows Phone SDK 7.1 from working correctly on Windows 8.

What to do if the workaround doesn’t help

If you have tried the above steps and setup still fails, you are running into a different issue than the one described above, and you will have to look at the setup log files to determine the root cause.

If you are installing the Windows Phone SDK 7.1, you can use the log collection tool to gather your setup log files. This log collection tool will create a file named %temp%\vslogs.cab.

If you are installing XNA Game Studio, you can find log files at the following locations:

• XNA Game Studio 4.0 Refresh - %temp%\XNA Game Studio 4.0 Setup\Logs
• XNA Game Studio 4.0 - %temp%\XNA Game Studio 4.0 Setup\Logs
• XNA Game Studio 3.1 - %temp%\XNA Game Studio 3.1 Setup\Logs
• XNA Game Studio 3.0 - %temp%\XNA Game Studio 3.0 Setup\Logs
• XNA Game Studio 2.0 - %ProgramFiles%\Microsoft XNA\XNA Game Studio\v2.0\Setup\Logs

Once you have gathered your setup log files, please upload them to a file server of your choice (such as http://skydrive.live.com), and post a link to the log files in the App Hub Forums or in a comment on my blog to get additional support.

What is causing this failure behind the scenes

XNA Game Studio installs a version of the Games for Windows – LIVE Redistributable behind the scenes.  Some older versions of the Games for Windows – LIVE Redistributable attempt to install and use a file that is being installed by Windows 8, and the older versions of the redistributable are not compatible with the newer version of the file that is installed by Windows 8.  Newer versions of the Games for Windows – LIVE Redistributable are compatible with Windows 8, and if you pre-install the new redistributable before installing XNA Game Studio, setup will recognize that it is already there and use the new version instead of trying to install the old version.

The reason this issue also impacts the Windows Phone SDK 7.1 is that this SDK installs XNA Game Studio behind the scenes, which in turn installs the Games for Windows – LIVE Redistributable behind the scenes.

<update date="7/12/2012"> Added a note about installing the Windows Phone SDK 7.1.1 Update after installing the Windows Phone SDK 7.1 to fix an emulator issue on Windows 8. </update>

<update date="7/22/2012"> Fixed broken link to the Windows Phone SDK 7.1.1 Update </update>

<update date="10/30/2012"> Removed outdated reference to the Windows 8 consumer preview. This post applies equally to the final release of Windows 8. </update>

I've gotten some email questions from customers about setup failures that they've seen on their computers.  Some of them are 1935 errors that match some of the previous blog posts I've written, some are .NET Framework errors, and some are general problems getting some program installed.

I cannot guarantee that I will be able to help solve all setup-related problems you may encounter, but I can guarantee that I will take a look and try to help if I can.  In order to do so I would like to ask that you try to gather some detailed information and send it to me if you contact me via email to aid in troubleshooting and debugging:

1. As much detail about the error message as possible, including the full text of any error messages.
2. Any troubleshooting steps that you have already tried, including links to any of my other blog posts that you've already tried.
3. Most importantly - log files from the setup if at all possible.  You can zip and upload log files to a file server of your choice and include a link to the log files when you contact me.  My preference is http://skydrive.live.com because it is free, gives you a lot of storage space, and doesn't contain annoying ads to try to get you to pay for "premium" services like faster download speeds.

Most setups are Windows Installer MSIs.  For those products, you can enable verbose logging by setting a couple of registry values and then reproducing the problem.  Here are a set of steps you can use to gather a Windows Installer verbose log file:

Important note - some MSI-based setups, including the .NET Framework 2.0, 3.0, 3.5 and higher, will not create log files named %temp%\msi*.log even if using the instructions listed below.  Please see this blog post for more details about why that is the case and also for a list of some products that I know of that use different log file creation logic and the locations of the log files that they create.

1. If you are running Windows XP or older:  Click on the Start menu, choose Run, type cmd and click OK
2. If you are running Windows Vista or newer:  Click on the Start menu, choose All Programs, then Accessories, then right-click on the item named Command prompt and choose Run as administrator
3. Copy this command into the cmd prompt and press enter to run it:  reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Debug /t REG_DWORD /d 7 /f 
4. Copy this command into the cmd prompt and press enter to run it:  reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Logging /t REG_SZ /d voicewarmupx! /f
5. Re-run the setup and let it fail one more time
6. Go to your temporary folder (go to the Start menu, choose Run, and type %temp%)
7. Locate a file named msi*.log (where * is a randomly generated set of letters and numbers)
8. Zip the msi*.log file (because it tends to be very large but since it is text it compresses nicely)
9. Run this command in the cmd prompt:  reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Debug /f
10. Run this command in the cmd prompt:  reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Logging /f
11. Upload the zipped log files to a file server such as http://skydrive.live.com

<update date="3/27/2007"> Changed steps to enable/disable verbose logging to not require downloading .reg files from my file server </update>

<update date="2/27/2008"> Added a link to a new blog post with information about some products that create their own verbose log files and therefore do not create %temp%\msi*.log, even when the verbose logging policy is enabled on the system. </update>

<update date="12/2/2010"> Added information about uploading log files to http://skydrive.live.com. </update>

<update date="11/17/2011"> Added clarifications to steps 2 and 3 to indicate that the commands need to be run separately, not as a single command. Also added a note about running as administrator on Windows Vista or later. </update>

March 7, 2008 update - I have written a replacement version of these instructions.  Please refer to http://blogs.msdn.com/astebner/archive/2008/03/07/8108332.aspx instead of using the steps listed below.

I have heard from many customers who have run into various types of installation problems while trying to install the .NET Framework 1.0 or 1.1 or .NET Framework hotfixes and service packs.  Some of my other blogs posts have described various workarounds, and I am working on an article that consolidates these workarounds.  However, there are some problems that aren't able to be resolved with the other workarounds I have posted.

Nearly every time when I run into a scenario where my other posts do not help, I try to use the following steps to get the machine back into a known state and then install things back one by one:

1. Download the .NET Framework cleanup tool and choose to cleanup the version of the .NET Framework that is causing problems on your system
2. Download and install the version of the .NET Framework that you cleaned up in step 1 (such as the .NET Framework 1.0, .NET Framework 1.1 or .NET Framework 2.0)
3. (optional) Download and run the .NET Framework verification tool to double-check that all .NET Framework files are correctly installed
4. Download and install the desired .NET Framework service pack (such as .NET Framework 1.0 SP3 or .NET Framework 1.1 SP1) by running the setup package directly instead of using Windows Update.  Running it directly will allow the service pack setup to display error dialogs instead of having Windows Update suppress them

Running these steps should ideally put your machine back into a known good state with the .NET Framework plus a service pack installed.  From there, it will usually work to install applications that require the .NET Framework (such as Visual Studio) or to install additional .NET Framework hotfixes (such as the security updates listed here).

<update date="3/7/2008"> I have written a replacement version of these instructions.  Please refer to http://blogs.msdn.com/astebner/archive/2008/03/07/8108332.aspx instead of using the steps listed above. </update>

Question:

I have built an installer using the Visual Studio 2005 setup project wizard.  It installs correctly on Windows XP but fails on Windows Vista.  I investigated and found that the failure on Windows Vista is caused by a custom action that fails with an access denied error.  However, I am running the setup with elevated privileges in Windows Vista.  How can I fix my setup so it will work correctly on Windows Vista?

Answer:

As Robert Flaming described in this blog post, it is necessary to set the NoImpersonate flag for custom actions that modify the system in Windows Vista.  This was an uninforced architectural intent that is now enforced in Windows Vista.

Unfortunately, there is not a way to directly set this flag for a custom action in the UI for the setup project in the Visual Studio IDE.  In Visual Studio 2005, you can use a post-build step that modifies the MSI to set this bit using a strategy previously described in this blog post.

You can use the following steps to set the NoImpersonate bit in a Visual Studio 2005 setup project:

1. Download the sample script and extract the contents to the directory that contains the Visual Studio project you are working on
2. Open the project in Visual Studio 2005
3. Press F4 to display the Properties window
4. Click on the name of your setup/deployment project in the Solution Explorer
5. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
6. Click on the "..." button to display the Post-build Event Command Line dialog
7. Add the following command line in the Post-build event command line text box:
   cscript.exe "$(ProjectDir)CustomAction_NoImpersonate.js" "$(BuiltOuputPath)"
8. Build your project in Visual Studio 2005

<update date="1/22/2007"> Updated command line in step 7.  The variable I had specified previously was incorrect.  It actually needs to be spelled wrong using "ouput" instead of "output" in the $(BuiltOuputPath) variable </update>

<update date="3/18/2009"> Fixed broken link to the sample script. </update>

I was helping investigate a .NET Framework installation failure last week that turned out to have an interesting root cause, so I wanted to pass along the information I learned.  The .NET Framework was failing with a 1935 error, and the HRESULT value was 0x80070002.  In general this HRESULT means "the system cannot find the file specified" - and since the .NET Framework is packaged up in a single self-extracting package, it is nearly impossible to get this particular HRESULT during setup.

One of the developers investigated a similar issue and found that this particular HRESULT can be caused by a certain type of adware running on the machine.  If you launch Task Manager and then look at the Processes tab, take a look for a process named wtoolsa.exe.  If this process is running, you will need to clean off this adware (for example by following the suggestions at this site).

One note - the machine that I looked at that was infected with this adware was pretty difficult to clean up.  It relaunched itself when I killed the process, it replaced entries in the Run and RunOnce keys when I deleted them.  I didn't get a chance to try all of the recommended steps in the article I linked to, but I'm guessing there are some more aggressive tactics you could take to rip it off your machine.

Hopefully this will help some of you solve installation issues for the .NET Framework and other products that fail with 1935 errors with HRESULT 0x80070002.

Question:

You previously posted a list of command line switches to perform silent and unattended installations of the Visual C++ 2005 runtime redistributable packages.  How can I perform silent and unattended installations of the Visual C++ 2008 runtime redistributable packages?

Answer:

The Visual C++ 2008 redistributable packages (vcredist_x86.exe, vcredist_x64.exe and vcredist_ia64.exe) support the following command line installation options.

The same command lines are valid for the VC++ 2008 redistributable packages and the VC++ 2008 SP1 redistributable packages.

The examples below use the file named vcredist_x86.exe, but you can substitute the 64-bit versions of the EXEs with equivalent command lines to achieve the same behavior for them as well. 

Unattended install

This option will run setup and display a progress dialog but requires no user interaction.

<full path>\vcredist_x86.exe /qb

For example, if you download vcredist_x86.exe to a folder named c:\vc2008redist, then the command line would look like this:

c:\vc2008redist\vcredist_x86.exe /qb

Unattended install with no cancel button

This option is the same as the previous option, except that the user will not have the option to press cancel during installation.

<full path>\vcredist_x86.exe /qb!

For example, if you download vcredist_x86.exe to a folder named c:\vc2008redist, then the command line would look like this:

c:\vc2008redist\vcredist_x86.exe /qb!

Silent install

This option will suppress all UI during installation.

<full path>\vcredist_x86.exe /q

For example, if you download vcredist_x86.exe to a folder named c:\vc2008redist, then the command line would look like this:

c:\vc2008redist\vcredist_x86.exe /q

Related links:

• How to perform a silent install of the Visual C++ 2005 redistributable packages
• How to detect the install state for the Visual C++ 2005 redistributable packages
• How to detect the install state for the Visual C++ 2005 SP1 redistributable packages
• How to detect the install state for the Visual C++ 2008 redistributable packages

<update date="7/7/2009"> Added information to indicate that you must provide the full path to the file vcredist_x86.exe when running the silent install command lines or they will display UI. </update>

As I was reading one of the posts on Quan To's new blog, I noticed that someone posted a link to a tool named msiinv.exe on their tools page.  This tool (which stands for MSI Inventory) wraps some of the publicly documented MSI APIs to provide information about the state of all Windows Installer products, features and components that Windows Installer thinks are installed on your computer.  I say "thinks are installed" because there are some rare cases where the actual installation state of a given product can get out of sync with the information Windows Installer has stored in its internal data structures, which can cause confusion for setup packages.

I use this tool nearly every day as one of the first troubleshooting tools for setup problems because it allows me to get a baseline snapshot of what the current state is for a machine before I start trying to make changes to fix any problems a customer might be having.

Example usage of msiinv.exe

One of the common uses of msiinv.exe is if someone is trying to install one of the recent beta builds of VS 2005 or .NET Framework 2.0 and the setup UI states that you are not allowed to install because a previous beta version of <insert product name here> is on the machine and you must uninstall that first.  Sometimes after receiving this error message, a user will look in Add/Remove Programs and the product that setup is complaining about is nowhere to be found, or there is an Add/Remove Programs entry for that product but trying to remove it claims that the product is not on the computer and asks if you would like to remove the entry from the Add/Remove Programs list.

In these cases, you can use the following steps:

1. Download msiinv.zip from the following location:
   
   
   
   
2. Extract the contents of msiinv.zip to the folder c:\msiinv on your system
3. Click on the Start menu, choose Run, type cmd and click OK
4. Type this command:  c:\msiinv\msiinv.exe -p > c:\msiinv\msiinv_output.txt
   
   Note: This command must be run from a cmd prompt or it will not create a log file as expected.

These steps will create a text file named c:\msiinv\msiinv_output.txt with a list of each product that Windows Installer thinks is installed on the system.  Then you can open the text file in any text editor and search the list of products for the name of the product that setup told you to uninstall.  The output will look something like this (I am using an example from a machine that has .NET Framework 2.0 beta 2 installed):

Microsoft .NET Framework 2.0 Beta 2
 Product code: {7A1ADD0C-17F3-47B8-B033-A06E189C835D}
 Product state: (5) Installed.
 Package code: {856D48D2-6F94-466D-9732-534DB5854FB3}
 Version: 2.0.50215
<note: there is more info after this but I am omitting it because it isn't useful to the rest of my example>

Now we have the Windows Installer product code and we can use that to uninstall the product by running msiexec /x <product code> (make sure that you include the curly braces in this command line).  If the product is actually installed on your system you will see a progress screen and uninstall will complete, and from there you should be able to re-run VS or .NET Framework setup and successfully install.

If Windows Installer thinks that the product is installed but it really isn't, then running msiexec /x <product code> will give you an error stating that this command is only valid for installed products.  If this happens, you will need to perform an extra step to remove the data that causes Windows Installer to think this product is installed.  You can download the Windows Installer Cleanup Utility and install and run it on your machine to fix this.  In the list of applications that this tool displays, choose the one that matches the product name displayed when you first ran VS or .NET Framework setup and choose to remove it.  After this removal completes, you should be able to re-run VS or .NET Framework setup and successfully install.

Advanced usage of msiinv.exe

The msiinv.exe tool has several command line parameters that you can see by running it with the /? switch.  A couple of the more interesting options are the following:

• msiinv.exe -v - This option will list all feature GUIDs and component GUIDs for each Windows Installer product that is installed on the machine.  This can be useful to see which products share components (which can help track down why running uninstall for one product leaves behind some files and/or registry).  If you have a lot of products installed on the machine, running with the verbose switch will take a long time.
• msiinv.exe -x - This option will list Windows Installer components that are installed on the machine that do not have any products that hold reference counts on them anymore.  In most cases, this is caused by one or more setup being installed on the machine at some point in the past that violated the MSI component rules. (more info about component rules can be found here and here if you are interested)

<update date="12/1/2008"> Updated the link to msiinv.zip because the old location was no longer available. </update>

<update date="2/12/2009"> Updated command line for running msiinv.exe so it will work on Windows Vista and Windows Server 2008. </update>

<update date="4/1/2009"> Removed broken link to msiinv.exe tool </update>

<update date="10/11/2012"> Embedded new SkyDrive link to msiinv.exe tool </update>

I have heard from some folks who have been encountering Tuner Not Found error messages when trying to view live TV in Media Center 2005 after installing Update Rollup 2.  Many of these errors have been caused by the .NET Framework versioning issue that I previously described in this blog post.  However, recently I have seen this error on systems that had no error messages listed in their setup log files.  Fortunately, I got a chance to look at one of these systems because we found a repro machine that belonged to a Microsoft employee and they brought the system in for us to take a look at in our lab.

On the system I looked at, the Media Center receiver and scheduler services (named ehRecvr and ehSched) were installed and registered, but were in a stopped state.  I could verify by running sc query ehrecvr and sc query ehsched that this was the case.  However, when I tried to manually start these services by running sc start ehrecvr or sc start ehsched, they each failed with an error message and an error code stating that a class was not registered.

I used the following steps to fix these services, and once I did this, live TV started working again in Media Center 2005 with Update Rollup 2.  Note that before running these steps, I verified by looking at the setup log files that setup ran correctly and that the setup error described here was not present:

1. Click on the Start menu, choose Run and type cmd
2. Run the command regsvr32.exe atl.dll
3. Run the command %windir%\ehome\ehrecvr.exe /unregServer
4. Run the command %windir%\ehome\ehsched.exe /unregServer
5. Run the command %windir%\ehome\ehrecvr.exe /service
6. Run the command %windir%\ehome\ehsched.exe /service

Note that the command line parameters to unregister and re-register are case sensitive, so you must spell it /unregServer with a capital S and /service all in lower case.

If the above steps do not help, I have also seen the following steps work in some cases to fix Tuner Not Found error messages in Media Center 2005:

• Update your video card and tuner drivers from the websites for your hardware manufacturers
• Launch Media Center, go to Settings | TV and try to re-run the TV setup wizard
• Use the MceRepair tool created by Peter Rosser to forcibly re-register all Media Center binaries (note that this tool does things that standard setup does not do, so please use it with caution)

I have heard from a couple of customers who have tried to download and install the software to enable using Xbox 360 as an Extender for Media Center 2005 with Update Rollup 2, but have encountered a crash dialog from the DvcSetup.exe process at the beginning of setup.  I finally located a computer in our test lab that reproduced this issue and found a possible root cause and workaround in case anyone else runs into this.

Problem description

The Xbox 360 PC setup package crashes almost immediately after it is launched.  The error dialog indicates that DvcSetup.exe crashed, and it may ask if you want to debug the problem.

Workaround

I was able to use the following steps to clean up the machine in our test lab that exhibited this problem:

1. Go to Add/Remove Programs and remove the .NET Framework 1.1 (and any .NET Framework 1.1 language packs if you have any installed)
2. Download the .NET Framework cleanup tool, run it and choose to clean up the .NET Framework 1.1
3. Reinstall the .NET Framework 1.1 
4. Reinstall the .NET Framework 1.1 SP1

Details about the root cause if you are interested

On the machine I investigated, the .NET Framework 1.1 had been installed, but none of the files were correctly installed in the global assembly cache (GAC).  I found that there were folders created for each assembly (for example - %windir%\assembly\GAC\Accessibility\1.0.5000.0__b03f5f7f11d50a3a), but the folders did not actually contain the assembly.  I also saw the following entries in the verbose MSI log file for the .NET Framework 1.1 on this machine:

MSI (s) (C8:D8): skipping installation of assembly component: {45B8FB98-2A6C-11D6-A551-0090278A1BB8} since the assembly already exists

There is a bug in the version of Fusion that shipped with the .NET Framework 1.0 and 1.1 where it would skip installing an assembly to the GAC if the folder already existed, even if the file was not in the folder.  Windows Installer uses Fusion to try to install assemblies into the GAC, and as the log file shows, each of the .NET Framework 1.1 assemblies was skipped because Fusion thought they already existed.

So far, I have only seen one scenario where empty folders exist in the GAC and cause this type of behavior for .NET Framework 1.1 setup.  If you have an operating system installed and have the .NET Framework 1.1 installed, and then you peform a clean install of your operating system to the same partition and choose not to format the partition, OS setup will create a new Windows directory for you.  When it does so, OS setup copies your Windows directory to a backup location and creates the same set of folders that previously existed in your Windows directory.  However, OS setup will not mirror any of the files because it assumes that you will want the copies of the files that are a part of the OS setup that you are currently installing.

This type of OS install leaves your computer in a state where the .NET Framework 1.1 assembly folders exist in the GAC, but they are all empty, and then due to the bug in Fusion that I previously installed, reinstalling the .NET Framework 1.1 does not fix the problem.  The workaround I described above will work correctly because the .NET Framework cleanup tool will remove these empty directories, which will allow a reinstall of the .NET Framework 1.1 to correctly install the assemblies to the GAC.

Now that the .NET Framework 2.0 and VS 2005 are officially released, those of you who have been running beta and CTP builds will need to prepare your machines to install the final release.  As I'm sure many of you are aware of if you've had a beta installed in the past, beta uninstall and migration to newer builds has been a very painful subject dating all the way back to VS 2005 and .NET Framework 2.0 beta 1.  Fortunately there is a lot more awareness that uninstalling the various pieces of VS 2005 is not trivial, and there are some automated uninstall tools and much better documentation.

For those of you who will need to uninstall a previous beta in order to install the final release of VS 2005 and/or the .NET Framework 2.0, you should make sure to review the official uninstall instructions before starting to uninstall anything.  In case you read nothing else, please make sure that you leave the .NET Framework 2.0 beta uninstall until the very end.  Most of the other pieces of VS 2005 will not uninstall fully if you remove the .NET Framework 2.0 beta first, and that can cause problems in some scenarios after installing the final release.

In order to make the uninstall process easier, there are a couple of automated uninstall tools available for various scenarios:

1. Tool to uninstall beta and CTP builds of VS 2005 and .NET Framework 2.0 - this tool should be run on a machine that still has the beta or CTP build installed to uninstall all pieces of the beta or CTP to prepare a machine to install the final release
2. Troubleshooting tool - this tool should be run to find and fix problems while running the final release of VS 2005 and .NET Framework 2.0 if you previously uninstalled in the incorrect order; this tool also has the automatic uninstall functionality built-in, but you should use the first tool if you only need to uninstall
3. Tool to uninstall beta and CTP builds of WinFX - this is similar to the first tool, but is specifically designed to remove WinFX beta/CTP builds in addition to VS 2005 and .NET Framework 2.0 beta/CTP builds
4. "The Hammer" - this tool is designed for scenarios where you have installed the final release of VS 2005 and/or the .NET Framework 2.0 and it does not work and the troubleshooting tool does not fix it; this tool will fully uninstall the final release of VS 2005 (in addition to any beta versions you might have installed) so make sure you only run it if you want to uninstall the final build; this tool is intended to be used to remove VS 2005 and get a machine back into a known state to try to install it again to clean up any problems that other troubleshooting steps are not able to resolve

The uninstall tools (#1, #3 and #4 above) are designed to run Windows Installer APIs and command lines to discover whether or not a known, fixed set of products are installed and then remove them.  As we discover additional issues that these tools do not cover, I will be updating the troubleshooting tool.  The main goal of the troubleshooting tool is to fix up a machine that already has the final release installed without needing to have the user resort to uninstalling everything and starting from scratch.  It tries to perform more "surgical" fixes for specific issues related to incomplete/incorrect beta uninstalls.

As always, let me know if you run into any issues or have any feedback on any of the above tools and I'll try my best to help.

Important note - the steps in this blog post have typically only proven useful in cases where a previous beta of Visual Studio 2005 was installed on the system prior to installing the final release of VS 2005.  If you have never had a beta of VS 2005 on your system and are encountering package load failure errors, these steps will most likely not help.  In that type of scenario, I recommend running devenv.exe with the /log switch (described in this MSDN topic) to create a log file of the packages it tries to load and then search in that log file for errors and warnings to help narrow this issue down further. 

Ever since the final version of Visual Studio 2005 was released, I have been hearing from customers who are running into Package Load Failure errors while trying to get beta versions uninstalled and the final version installed.  I have previously posted a set of steps that I have found will resolve nearly all cases of these Package Load Failure errors.  However, there have been some cases where these steps are not enough and more in-depth manual removal steps have proven necessary.  Up until now, I have been resisting posting the additional steps that are necessary in some cases because I really want folks to try out the other steps I have posted first.  However, I am going to go ahead and post a complete set of steps and just duplicate my previous steps in an effort to communicate the workarounds I have found as widely as possible while also making my best effort to make things as easy as possible for the majority of customers.

So, without further ado, here is a complete, hopefully definitive set of steps that will help resolve all Package Load Failure errors seen while trying to use the final release of VS 2005 on a system that previously had a beta version installed.  Please try these steps in the order listed and check to see if the Package Load Failure errors are resolved after completing each step so that you can try to avoid needing to perform more removal steps than are strictly necessary on your system.

Please note - if you have Dotfuscator 3.0 installed on your system, you should first try the workaround described here to see if you are running into a known issue that has been fixed by Preemptive (the company that produces Dotfuscator).

1.  Try to repair the .NET Framework 2.0

Sometimes, package load failures have a very simple cause - the .NET Framework 2.0 is somehow in a broken state.  Before trying any of the more complicated steps listed below, it is worth trying to repair the .NET Framework 2.0.  To do this, go to the Add/Remove Programs control panel, locate the item named Microsoft .NET Framework 2.0 and choose to repair it.

3.  Try to run the following command line to clear out parts of the native image cache

• Close Visual Studio and/or reboot the system to make sure that there will not be any files in use
• Click on the Start menu, choose Run and type cmd
• Type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32\Microsoft.VisualStu# and press enter to remove a subset of the native images that have proven problematic in the past from the cache.

4.  Try to run the following command line to clear out all of the native image cache

• Close Visual Studio and/or reboot the system to make sure that there will not be any files in use
• Click on the Start menu, choose Run and type cmd
• Type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32 and press enter to remove all VS 2005 native images from the cache.

5.  Remove the version of VS 2005 you have installed, manually clean the system and try installing again

• Uninstall all of VS 2005 using the uninstall instructions and automated uninstall tool
• Click on the Start menu, choose Run and type cmd
• Type cd /d %windir%\assembly
• Type rd /s /q GAC_32 and then rd /s /q GAC_MSIL
• Type dir and locate any directories named NativeImages_v2.0* and type rd /s /q <directory> to delete all VS 2005 native image directories as well
• Using regedit.exe, remove all of the following registry sub-hives, including all registry keys and values underneath them:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDN\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\MSDN\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VBExpress\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\VBExpress\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCExpress\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\VCExpress\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCSExpress\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\VCSExpress\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VJSExpress\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\VJSExpress\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VWDExpress\8.0
  HKEY_CURRENT_USER\SOFTWARE\Microsoft\VWDExpress\8.0
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Hatteras
• Run this set of steps to locate and delete any files with versions 2.0.xxxxx.xx and 8.0.xxxxx.xx that are still left on your system.  Please note that all of the Package Load Failure errors that I have seen so far have been caused by files left behind in %windir%\assembly (the GAC) on the machine, so pay special attention to any leftover files in this location and make sure that all orphaned files with versions 2.0.xxxxx.xx and 8.0.xxxxx.xx are removed before attempting to reinstall VS 2005
• Run this set of steps to clean up the WinSxS folder
• Reboot the machine
• Try to install VS 2005 again

If none of the above steps work for you, please leave a comment on this blog post or contact me and I will try my best to help you further.

<update date="12/19/2005"> Added a new step to remove some registry data related to VS 2005 as part of step 4 above </update>

<update date="1/10/2006"> Added link to information about a package load failure scenario caused by Dotfuscator 3.0 </update>

<update date="1/15/2006"> I have seen a couple of issues caused by orphaned keys under the Express Edition hives and the MSDN hives, so I added those to the list in step 4 above </update>

<update date="11/18/2006"> Added a new first step to try repairing the .NET Framework 2.0 </update>

<update date="4/2/2008"> Added caveat that the steps in this post are typically only useful when a beta of VS 2005 was previously installed on the system. </update>

<update date="4/24/2009"> Fixed broken link to the VS 2005 beta uninstall troubleshooting tool. </update>