Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

  • Aaron Stebner's WebLog

    Automated cleanup tool to remove the .NET Framework 1.0, 1.1, 2.0, 3.0 and 3.5

    • 235 Comments

    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>

     

  • Aaron Stebner's WebLog

    Removal tool to fix .NET Framework install failures

    • 280 Comments

    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>

     

  • Aaron Stebner's WebLog

    Solving setup errors by using the SubInACL tool to repair file and registry permissions

    • 310 Comments

    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):

      @echo off
      title Resetting ACLs...

      setlocal

      echo.
      echo Determine whether we are on an 32 or 64 bit machine
      echo.

      if "%PROCESSOR_ARCHITECTURE%"=="x86" if "%PROCESSOR_ARCHITEW6432%"=="" goto x86

      set ProgramFilesPath=%ProgramFiles(x86)%

      goto startResetting

      :x86

      set ProgramFilesPath=%ProgramFiles%

      :startResetting

      echo.

      if exist "%ProgramFilesPath%\Windows Resource Kits\Tools\subinacl.exe" goto filesExist

      echo ***ERROR*** - Could not find file %ProgramFilesPath%\Windows Resource Kits\Tools\subinacl.exe. Double-check that SubInAcl is correctly installed and re-run this script.
      goto END

      :filesExist

      pushd "%ProgramFilesPath%\Windows Resource Kits\Tools"

      echo.
      echo Resetting ACLs...
      echo (this may take several minutes to complete)
      echo.
      echo IMPORTANT NOTE: For this script to run correctly, you must change
      echo the values named YOURUSERNAME to be the Windows user account that
      echo you are logged in with.
      echo.
      echo ==========================================================================
      echo.
      echo.
      subinacl.exe /subkeyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators > %temp%\subinacl_output.txt
      echo.
      echo.
      subinacl.exe /keyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators >> %temp%\subinacl_output.txt
      echo.
      echo.
      subinacl.exe /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
      echo.
      echo.
      subinacl.exe /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
      echo.
      echo.
      subinacl.exe /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txt
      echo.
      echo.
      subinacl.exe /keyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txt
      echo.
      echo.
      echo System Drive...
      subinacl.exe /subdirectories %ProgramFilesPath%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txt
      echo.
      echo.
      echo Windows Directory...
      subinacl.exe /subdirectories %windir%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txt
      echo.
      echo.
      echo ==========================================================================
      echo.
      echo FINISHED.
      echo.
      echo Press any key to exit . . .
      pause >NUL

      popd

      :END

      endlocal

       
    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.

    Note: There are a couple of scenarios where installing or running SubInAcl can fail.  For example, some non-English versions of Windows have the name of the Administrators group translated to another language, and the command lines listed above will fail in that case.  I have posted workarounds for the issues that I know of in this separate blog post.

    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.

    When is SubInACL useful

    I have found that the SubInACL tool is most useful when a setup package fails with error code 5 or 0x5 or 0x80070005.  All of these error codes mean Access Denied, and this type of error code is often caused by missing ACLs for the Administrators group or the built-in System account.  The Windows Installer service runs with System account permissions in most cases.  If the System account does not have sufficient permissions to access the file system or parts of the registry, an MSI-based setup package will fail with an Access Denied error.

    SubInACL can also help resolve Internet Explorer script errors caused by incorrect access control permissions for specific user accounts on the system.

    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>

     

  • Aaron Stebner's WebLog

    How to repair the .NET Framework 2.0 and 3.0 on Windows Vista

    • 189 Comments

    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>

     

  • Aaron Stebner's WebLog

    Updated: what to do if other .NET Framework setup troubleshooting steps do not help

    • 169 Comments

    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
      .NET Framework 4.5.1
      .NET Framework 4.5.2

      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:

    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>

     

  • Aaron Stebner's WebLog

    Troubleshooting 1935 and 2908 errors during installation

    • 171 Comments

    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:

     

    Product

    Command line syntax

    Log file location

    .NET Framework

    dotnetfx.exe /c:”install.exe /l”

    %temp%\netfx.log

    .NET Framework SDK

    setup.exe /c:”install.exe /l”

    %temp%\netfxsdk.log

    .NET Framework Language Pack

    langpack.exe /c:”inst.exe /l”

    %temp%\langpackmsi.log

    J# Redistributable Package

    vjredist.exe /c:”inst.exe /l”

    %temp%\jsredistmsi.log

    J# Redistributable Package Language Pack

    Vjredist-LP.exe /c:”inst.exe /l”

    %temp%\langpackmsi.log

     

    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:

     

     

    Return type

     

     

    Return code

     

    HRESULT

     

    Description of error

    TYPE_E_DLLFUNCTIONNOTFOUND

    0x8002802F

    -2147319761

    Function not defined in specified DLL

    ERROR_ACCESS_DENIED

    0x7FF8FFFB

    -2147024891

    Access is denied

    COR_E_MODULE_HASH_CHECK_FAILED

    0x80131039

    -2146234311

    The check of the module's hash failed

    FUSION_E_REF_DEF_MISMATCH

    0x80131040

    -2146234304

    The located assembly's manifest definition does not match the assembly reference

    FUSION_E_INVALID_PRIVATE_ASM_LOCATION

    0x80131041

    -2146234303

    The private assembly was located outside the app-base directory

    FUSION_E_ASM_MODULE_MISSING

    0x80131042

    -2146234302

    A module specified in the manifest was not found

    FUSION_E_UNEXPECTED_MODULE_FOUND

    0x80131043

    -2146234301

    Modules which are not in the manifest were streamed in

    FUSION_E_PRIVATE_ASM_DISALLOWED

    0x80131044

    -2146234300

    A strongly-named assembly is required

    FUSION_E_SIGNATURE_CHECK_FAILED

    0x80131045

    -2146234299

    The check of the signature failed

    FUSION_E_DATABASE_ERROR

    0x80131046

    -2146234298

    An unexpected error was encountered in the Assembly Cache database

    FUSION_E_INVALID_NAME

    0x80131047

    -2146234297

    The given assembly name or code-base is invalid

    FUSION_E_CODE_DOWNLOAD_DISABLED

    0x80131048

    -2146234296

    HTTP download of assemblies has been disabled for this app-domain

    FUSION_E_UNINSTALL_DISALLOWED

     

    0x80131049

    -2146234295

    Uninstall of given assembly is not allowed

    FUSION_E_NGEN_DEPENDENCY_NOT_FOUND

    0x80131050

    -2146234288

    One of the native image dependencies cannot be found

    FUSION_E_NGEN_INDEX_CORRUPTED

    0x80131051

    -2146234287

    ngen index corrupted

     

    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):

     

    Error code

    Return Type

    1936

    FUSION_E_PRIVATE_ASM_DISALLOWED

    1937

    FUSION_E_SIGNATURE_CHECK_FAILED

    1938

    FUSION_E_ASM_MODULE_MISSING

     

     

    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  

     

  • Aaron Stebner's WebLog

    How to manually cleanup a failed .NET Framework 2.0 install

    • 136 Comments

    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.

     

  • Aaron Stebner's WebLog

    How to locate the cause of error code 1603 in a verbose MSI log file

    • 100 Comments

    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>

     

  • Aaron Stebner's WebLog

    Using MsiInv to gather information about what is installed on a computer

    • 69 Comments

    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>

     

  • Aaron Stebner's WebLog

    How to manually uninstall SQL Express if uninstalling from Add/Remove Programs fails

    • 54 Comments

    I have heard from a few customers (inside and outside of Microsoft) who have had problems uninstalling previous beta versions of SQL Express via Add/Remove Programs or via the cleanup tools we have released (located here and here).  These customers have seen unexpected errors in the datastore related to the actions named RestoreSetupParams and/or Write_CommitFlag.  The exact error message states that setup is unable to write property into the cache: IsClustered and unable to write property into the cache: flagCommit.

    I haven't narrowed down the exact sequence, but these uninstall errors are caused by uninstalling beta versions of SQL 2005 and/or VS 2005 in specific orders.  The officially recommended uninstall order for these products can be found at this location.  However, this order is not enforced via the Add/Remove Programs control panel and it is pretty easy to overlook the readme and uninstall in alphabetical order or some other random order and get into this state.

    If you encounter either or both of the above error dialogs, you can use the following steps to resolve the errors:

    1. Download and run msiinv.exe using the instructions in this previous blog post
    2. Look at the output from msiinv.exe in a text editor such as notepad and locate each of the products that are installed that have SQL 2005 in the name
    3. Click on the Start menu, choose Run and type cmd
    4. For each of the SQL 2005 product codes found in the msiinv.exe output, run msiexec /x {Product Code} from the cmd prompt - this command will likely generate the same errors shown above but it is good to run it just in case
    5. Download the smartmsizap tool
    6. For each of the SQL 2005 product codes found in the msiinv.exe output, run smartmsizap.exe /p {Product Code} from the cmd prompt

    After running smartmsizap to cleanup each of the SQL 2005 products left behind on your machine, you should be able to successfully install later builds of SQL Express and/or VS 2005.

    <update date="11/26/2005"> Added text descriptions of the error messages to make it more likely that this blog post will be found from internet search engines because I have heard from a lot of customers who have run into this error but not found this blog post. Also modified the uninstall instructions to use the smartmsizap tool that I had not yet written at the time that I originally wrote this blog post. </update>

    <update date="4/14/2009"> Fixed broken link to the smartmsizap tool and removed broken image links. </update>

    <update date="8/27/2010"> Fixed broken link to the VS 2005 uninstall instructions and the TTool.zip tool. </update>

     

  • Aaron Stebner's WebLog

    More detailed steps to fix .NET Framework install errors that ask for tmpXXXX.tmp

    • 24 Comments

    I previously described a set of steps in this blog post that can be used to manually remove the .NET Framework and reinstall it if you receive an error message stating that setup is unable to find the file tmpXXXX.tmp when attempting to install a .NET Framework service pack or hotfix.   However, I've heard from a couple of customers over the past few weeks who still received errors related to tmpXXXX.tmp after performing the cleanup steps in that blog post.  As a result, I posted a more complete set of steps that you can use to clean up your system and reinstall the .NET Framework.  You can find them at http://blogs.msdn.com/b/astebner/archive/2008/03/07/8108332.aspx.

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

    <update date="5/6/2011"> Removing the old instructions in this post and pointing to updated steps. </update>

     

  • Aaron Stebner's WebLog

    Orca install package

    • 56 Comments

    Stephane Rodriguez posted an interesting comment that I hadn't thought of - it isn't the easiest thing in the world to download Orca.  You have to go through the Platform SDK web-based installer tool and also install a bunch of pieces of the core SDK to get orca.msi which lets you install Orca.  I have a copy of it that I downloaded and posted at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%5E_Tools/orca.zip for easier access.  I hope this makes things easier for you as you debug your setup packages.

    <update date="4/9/2010"> Fixed broken link to orca.zip. </update>

     

  • Aaron Stebner's WebLog

    More detailed troubleshooting ideas for .NET Framework 1.0 SP3 and 1.1 SP1 failures

    • 44 Comments

    I have posted a couple of previous items about .NET Framework 1.0 SP3 and 1.1 SP1 installation issues (at http://blogs.msdn.com/astebner/archive/2004/09/20/232236.aspx and http://blogs.msdn.com/astebner/archive/2004/09/21/232653.aspx).  There is a KB article in the works with more information but it appears to not be posted for viewing yet, so I wanted to include the info that it contains here in the hopes that it might help some folks who are stuck installing one of these .NET Framework service packs.

    .NET Framework SP Setup Issues

     

    Overview

     

    This document provides a reference to common setup issues and workarounds for .NET Framework 1.1 Service Pack 1 (SP1) and .NET Framework 1.0 Service Pack 3 (SP3).

     

    Windows Update Failures

     

    Windows Update Failed – Detailed Error Code “E0434F4D”

     

    0xE0434F4D (-532459699) is a generic COM exception.  This is caused by a failure in the managed patch wrapper.  There are 3 recommended steps that may fix this problem.  If these do not work, further investigation will be required.

     

    1.                  Repair .NET Framework 1.1 RTM (click Start, click Control Panel, click Add or Remove Programs, click Microsoft .NET Framework 1.1, click “Click here for support information”, click the Readme link).  This page has the 4 steps you will need to run to repair the .NET Framework

    2.                  Clear the Windows Update temporary downloads cache.  See http://support.microsoft.com/kb/193385 for more information.

    3.                  Clear the temporary directory.  Click Start, click Run, type “%temp%”, click Ok.  An Explorer window will open.  Select all of the files, and hit the delete key.

     

    If these steps do not solve the problem then more information must be gathered.  To see a more detailed error, download the service pack from http://download.microsoft.com/ and then double-click the EXE package.  If the issue occurs again, a crash dialog will be displayed this time.

     

    Windows Update Failed – Detailed Error Code “643”

     

    0x643 = 1603 = ERROR_INSTALL_FAILURE.  This error can be caused by one of the issues listed in the Error Dialogs section below.  The two most likely causes are the netfx.msi resolve source issue or the info 9002 issue.

     

    To see a more detailed error, download the service pack from http://download.microsoft.com/ and then double-click the EXE package.  If the issue occurs again, an error dialog will be displayed this time.

     

    Windows Update Failed – Detailed Error Code “652”

     

    0x652 = 1618 = ERROR_INSTALL_ALREADY_RUNNING.  This error is caused by the item titled Windows Installer Error 1618 – Another installation is already in progress described below.

     

    Crash Dialogs

     

    TargetInvocationException in SLxxx.tmp – missing registry key

     

    TargetInvocationException in SLxxx.tmp can occur for many different reasons.  One of the reasons that this crash occurs is when the Windows Installer registry hive is missing the LocalPackage value for the version of the .NET Framework being serviced. 

     

    Use the registry editor (regedit.exe) to navigate to

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData.  Next, search for the string “.NET Framework”

     

    When the search completes, several registry name/value pairs will be listed in the right-hand window pane.  If a DisplayName value of “Microsoft .NET Framework” exists but there is not a LocalPackage value then the TargetInvocationException is being caused by this issue.

     

    Reinstalling .NET Framework 1.0 or 1.1 will fix this problem. 

     

    TargetInvocationException in SLxxx.tmp – missing MSI file

     

    Another variation of the TargetInvocationException error is caused by a missing cached MSI file in the %windir%\Installer directory.  This crash occurs when the Windows Installer registry hive contains a LocalPackage value that points to a nonexistent file.

     

    See the previous topic (TargetInvocationException in SLxxx.tmp – missing registry key) for details on how to find the LocalPackage registry value.  Once the key is found open a command prompt (click Start, click Run, type cmd) and use the dir command to try to locate the target of the LocalPackage value.  For example, if the LocalPackage key was d:\windows\installer\f493a.msi you would type “dir d:\windows\installer\f493a.msi”.  If the dir shows “file not found” then the TargetInvocationException is being caused by this issue.  Reinstalling the .NET Framework 1.0 or 1.1 will fix this issue. 

     

    If the file does exist then the TargetInvocationException is being caused by another issue. 

     

    TargetInvocationException in SLxxx.tmp – virus scanner

     

    A TargetInvocationException can occur if the service pack setup “cancel” button is pressed while a virus scanner is running.

     

    In this scenario, the TargetInvocationException appears right before the success dialog is displayed and does not harm the computer.  This TargetInvocationException can be ignored.

     

    TargetInvocationException in SLxxx.tmp – low system resources

     

    A TargetInvocationException can occur when the system is out of memory.

     

    Rebooting the computer and then re-running the service pack setup can correct this problem.

     

    SLxxx.tmp – Configuration Error

     

    The error "Configuration Error: Unable to load JIT compiler (MSCORJIT.DLL) File may be missing or corrupt.  Please check your setup or rerun setup!" is a known issue with the setup for both the .NET Framework 1.1 SP1 and .NET Framework 1.0 SP3 releases.  The error is harmless and does not damage the machine.  On heavily loaded machines (machines in which it takes at least 5 seconds for setup to launch), before setup has begun installing, a dialog can be displayed that warns about an issue with any one of the following files:

     

    1.                  fusion.dll

    2.                  mscorjit.dll

    3.                  mscorlib.dll

    4.                  mscorsn.dll

    5.                  mscorwks.dll

    6.                  perfcounter.dll

    7.                  corperfmonext.dll

    8.                  aspnet_isapi.dll 


    The workaround is to reduce the load on the machine by closing applications before re-running setup. 

     

    SLxxx.tmp – Unable to Locate DLL

     

    This dialog is a variation of the SLxxx.tmp – Configuration Error issue described above.

     

    SLxxx.tmp – Common Language Runtime Debugging Services

     

    This crash dialog can be displayed for many reasons. A list of known causes and workarounds follows.

     

    ·         Check the My_Computer_Zone has FullTrust permissions enabled

     

    1.       Click Start, Control Panel, and open Administrative Tools.

    2.       Select the latest version of the Microsoft .NET Framework Configuration tool.

    3.       Drill-down to Runtime Security Policy, Machine, Code Groups, All_Code, My_Computer_Zone.

    4.       Right-click on My_Computer_Zone, select the Permission Set tab, and verify/change the permission set to FullTrust.

     

    Installation Hangs

     

    Service Pack installation hangs while running IIS

     

    The service pack installation may hang due to unresponsive IIS services on the machine (specifically WS3SVC and SMTP).  This is because setup attempts to stop some services if they are running on the machine before patching.

     

    If the service pack installation repeatedly hangs then the workaround is to manually stop the WS3SVC and SMTP services before running setup using the following steps:

     

    1.       Run "%SystemRoot%\system32\services.msc /s" to start the Services Manager

    2.       Find World Wide Web Publishing Service (WS3SVC) and Simple Mail Transfer Protocol Service (SMTP) in the services list.

    3.       Right-click on each service name and select Stop

     

    Alternately, turning off IISADMIN by opening a cmd prompt and running net stop /y iisadmin will also solve this service pack installation hang issue.  Both WS3SVC and SMTP are dependent on IISADMIN, so stopping IISADMIN will also stop WS3SVC and SMTP.

     

    After the installation, rebooting the computer or restarting the services by clicking "Start" instead of "Stop" in the Services Manager will return the computer to its original state.

     

    Error Dialogs

     

    Windows Installer Error 1618 – Another installation is already in progress

     

    Another installation is already in progress. Only one Windows Installer setup can run at a time.  You should complete the other installation before proceeding with this install.

     

    Windows Installer Dialog – cannot find ‘netfx.msi’

     

    Windows Installer may display a dialog asking the user to provide the location of netfx.msi.  This is called a Resolve Source Dialog.  Sometimes patches can prompt for the original installation media (asking the user for the location of netfx.msi).  This can happen when Windows Installer determines that the original product has missing or corrupt files which are not included in the patch package. 

     

    Repairing or reinstalling the original product will fix this issue.  Here are the repair instructions for .NET Framework 1.0 and 1.1:

     

    To repair the .NET Framework

    Obtain the original installation source. For example, if you installed the .NET Framework from CD or DVD, insert the disk. Or, if you downloaded the .NET Framework, download again and choose to save to disk. If you installed from a network share, reconnect.

    On the Start menu, choose Run.

    For Windows 98 and Windows Me type:

    command

    For Windows NT, Windows 2000, Windows XP or later, type:

    cmd

    In the command window, type the following:

    n:\<Installation Source>\dotnetfx.exe /t:%temp% /c:"msiexec.exe /fvecms %temp%\netfx.msi"

     

    For example:

    d:\dotNetFramework\dotnetfx.exe /t:%temp% /c:"msiexec.exe /fvecms %temp%\netfx.msi"

    To repair a .NET Framework Language Pack

    Obtain the original installation source. For example, if you installed the .NET Framework Language Pack from CD or DVD, insert the disk. Or, if you downloaded the .NET Framework Language Pack, download again and choose to save to disk. If you installed from a network share, reconnect.

    On the Start menu, choose Run.

    For Windows 98 and Windows Me type:

    command

    For Windows NT, Windows 2000, Windows XP or later, type:

    cmd

    In the command window, type the following:

    n:\<Installation Source>\langpack.exe /t:%temp% /c:"msiexec.exe /fvecms %temp%\langpack.msi"

     

    For example:

    d:\dotNetFramework\langpack.exe /t:%temp% /c:"msiexec.exe /fvecms %temp%\langpack.msi"

     

    Info 9002: .NET Framework 1.1 Service Pack 1 (SP1) cannot be installed

     

    The dialog “Info 9002: .NET Framework 1.1 Service Pack 1 (SP1) cannot be installed because you have one or more hot fixes installed.  Remove them and try again” is displayed when a blocking hot fix is already installed on the computer. 

     

    The 2003 October SDK Documentation Update (KB 827821) as well as two other .NET Framework 1.1 SDK patches (KB 841510 and KB 823641) can block the installation of .NET Framework 1.1 SP1.  A workaround for this issue is to remove all of the following registry keys:

     

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M827821

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211028

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278212052

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211042

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211036

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211031

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M8278211041

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M841510

    ·         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1\M823641

     

    Removing the registry keys can be done by using the registry editor:

     

    1.       Click Start -> Run, type “regedit.exe” and click OK

    2.       Inside the Registry Editor, navigate the registry structure until you are in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\.NETFramework\1.1

    3.       Expand the registry key list by clicking the plus ‘+’ sign next to the ‘1.1’ registry hive

    4.       Right-click on ‘M827821’ and select ‘Delete’

    5.       Continue right-clicking and selecting ‘Delete’ for M827821028, M827822052, M827821042, M827821036, M827821031, M827821041, M841510 and M823641 if they are present

     

    Windows Installer Error 1325 – ‘XXX’ is not a valid short file name

     

    Windows Installer Error 1325 occurs when the service pack is deployed with the command line argument SHORTFILENAMES=1.  A transform file (.MST) is needed to update the short filename in the file table of the .NET Framework netfx.msi to fix this issue if it is necessary to use the SHORTFILENAMES parameter to deploy the service pack.

     

    Windows Installer Error 1642 – The installer cannot install the upgrade patch

     

     The installer cannot install the upgrade patch because the program being upgraded may be missing or the upgrade patch updates a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.

     

    This dialog means that the wrong patch is being run.  This happens when the wrong version of the patch is accidentally downloaded.  For instance, .NET Framework 1.0 English (ENU) is installed but the .NET Framework 1.0 SP3 German (DEU) patch is being double-clicked.

     

    Verify that the correct patch is being used.  The patch file name ends with the 3-letter language identifier (for instance –enu or –deu).

     

    How to get help

     

    Collect installation log data

     

    Gather the following log files when none of the above items solves your problem and further investigation is required:

     

    1.       %temp%\netfxsl.log

    2.       %temp%\netfxupdate.log

    3.       %temp%\MSI*.LOG

     

    To get to the %temp% directory click Start, click Run, type “%temp%” and click OK.

     

    The MSI*.LOG file(s) may not be created by default.  If an MSI*.LOG file does not exist please enable Windows Installer verbose logging and then re-run the installation so that an MSI*.LOG file is created.

     

    The following steps can be used to enable Windows Installer verbose logging:

     

    1.       Use the registry editor (regedit.exe) to navigate the registry hive HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.

    2.       Right-click in the right window pane, select New

    3.       click DWORD Value

    4.       Type “Debug” and hit enter

    5.       Right-click the new registry value Debug and select Modify

    6.       Set the Value Data field to “7”.

    7.       Next, Right-click in the right window pane, select New

    8.       click String Value

    9.       Type “Logging” and hit enter

    10.   Right-click the new registry value Logging and select Modify

    11.   Set the Value Data field to “voicewarmup!”.

     

    Note: After gathering MSI*.LOG, it is recommended that you disable verbose logging by deleting the Debug and Logging values under HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer in your registry.  If these values are left behind, they will cause Windows Installer to create a verbose log for every MSI-based setup that is run on your computer, which can significantly impact the speed of installation.

     

    <update date="10/9/2008"> Fixed a broken link to the Windows Update download troubleshooting knowledge base article. </update>

     

  • Aaron Stebner's WebLog

    How to repair Media Center files and registry entries on Windows Vista and Windows 7

    • 63 Comments

    Note - this post was originally written for Windows Vista, but it also applies to Windows 7.

    Since the Windows Vista public launch in January 2007, I have been receiving questions more frequently about how to repair Windows Media Center to try to resolve various bugs.  Many of the customers I have heard from have tried some of the repair steps I have previously posted for Windows XP Media Center Edition (such as this, this or this), but ran into problems getting them to work.

    I want to emphasize that OS repair techniques that I have previously documented for Windows XP Media Center Edition will not work on Windows Vista or Windows 7 and should not be used on these versions of Windows.  The underlying installation technology for OS components is completely new in Windows Vista, so install/repair techniques for Windows XP OS components will not continue to work on Windows Vista and higher.  Also, some of the registration utilities that shipped with previous versions of Media Center are not included in Windows Vista or higher because they are no longer needed.

    Windows Vista and Windows 7 Media Center files and registry information 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 while using Windows Vista or Windows 7 Media Center and you suspect that files or registry entries that are a part of the Media Center feature are corrupt, you can use the instructions listed below to attempt to repair them.

    Repairing Windows Vista and Windows 7 Media Center files

    You can use the following steps to repair the files that are a part of Windows Vista Media Center:

    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 attempt to 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 
    8. After fixing any errors that are found, try to use Windows Vista Media Center again

    Disabling and re-enabling Windows 7 Media Center

    You can use the following steps to disable and re-enable Windows Media Center on Windows 7.  These steps do not apply to Windows Vista.

    1. Click on the Start menu, type optionalfeatures.exe and press Enter to launch the Windows Features control panel
    2. In the Windows Features control panel, expand the item named Media Features
    3. Uncheck the items named Windows Media Center and Windows Media Player
    4. Click OK, wait for the process to finish, and reboot your computer
    5. Click on the Start menu, type optionalfeatures.exe and press Enter to launch the Windows Features control panel
    6. In the Windows Features control panel, expand the item named Media Features
    7. Check the items named Windows Media Center and Windows Media Player
    8. Click OK, wait for the process to finish, and reboot your computer

    Repairing Windows Vista and Windows 7 Media Center registry entries

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

    <update date="10/7/2008"> Added a link to a knowledge base article about SFC and how to find errors that it reports during its repair process. </update>

    <update date="8/17/2009"> Fixed broken link to knowledge base article. </update>

    <update date="2/24/2011"> Added a note about how to disable and re-enable Windows Media Center on Windows 7. </update>

    <update date="2/25/2011"> Updated the note I added yesterday to also include Windows Media Player. </update>

     

  • Aaron Stebner's WebLog

    Silent install, repair and uninstall command lines for the .NET Framework 4

    • 102 Comments

    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

    .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>

     

  • Aaron Stebner's WebLog

    Possible cause of 1935 error with HRESULT 0x80070002

    • 68 Comments

    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.

  • Aaron Stebner's WebLog

    Help me help you if you have setup bugs

    • 74 Comments

    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>

     

  • Aaron Stebner's WebLog

    How to work around a possible XNA Game Studio or Windows Phone SDK install failure on Windows 8

    • 117 Comments

    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>

     

  • Aaron Stebner's WebLog

    Unofficial download location for msizap.exe

    • 11 Comments

    Hey all,

    I received an email this morning asking about how to manually uninstall the .NET Framework (due to some issues that happened after installing Windows XP SP2 - this is another issue that I'll tackle in a future blog after I do some more investigation to figure out why we're seeing so many problems installing .NET Framework service packs after installing XPSP2, so stay tuned for that).  There are a couple of KB articles that describe manual removal techniques:

    Unfortunately, those articles reference a tool called msizap.exe that ships as part of the Windows Installer SDK.  Due to numerous functional and design issues with the Platform SDK installer, it is way more pain than it should be to install, not to mention that you have to install hundreds of megs of stuff to your machine even if you want only one tool that is shipped with it like msizap.  The person who emailed me with this problem found a location to download just the msizap tool.  I can't officially endorse it because it is on a 3rd party company's site, and I can't be sure which version they have on their server, etc.  But it appears to have worked fine in the cases that I tried, so if you are in need and have a slow network connection and can't take the time to download all the Platform SDK stuff, you can find it here.

    Hope this helps....

     

  • Aaron Stebner's WebLog

    Problems installing the new ASP.NET hotfix (KB886903 or KB887219)

    • 42 Comments

    I got a question from a customer this week who could not get an ASP.NET hotfix installed by launching it from Windows Update (due to an error like some folks have seen with other .NET Framework service packs that I described here).  As a result, he was trying to download the package directly, extract it and install manually, but he was having trouble trying to locate the underlying package and download it.  So I decided to try to do this myself to see how the process really works for an IT admin in the field, and I'm surprised by how complicated this process is.  Here are the specific steps I had to follow to locate and download this ASP.NET hotfix:

    1. I retrieved the KB article number from the Windows Update site
    2. I went to the Microsoft support site and found a link here that announces the security bulletin
    3. From there I followed the link for IT professionals since those links typically contain direct links to download packages to stage for installation in corporate networks or other scenarios where Windows Update is not an ideal option
    4. From there I followed the link to the Microsoft download center and used the suggestion to search for the keyword security_patch and filtered based on the .NET product family.  This gave me this results page
    5. From there I could choose what version(s) of the .NET Framework I wanted to patch and download the appropriate hotfix.  For example, this link leads to the hotfix that applies to .NET Framework 1.1 with SP1
    6. Now that I have downloaded the hotfix package, I can go back to the link for IT professionals and drill down to the details of the version of the hotfix I downloaded to figure out what command line switches to use to extract the contents of the package

    It really seems like there should be an easier way to locate, download and extract a hotfix package from Microsoft.  If there is a simpler way that I have missed, please post a comment and let me know.

    As a side note, this and any other .NET Framework or ASP.NET hotfixes are packaged using the same self-extracting wrapper as the .NET Framework 1.0 SP3 and 1.1 SP1, and therefore are all susceptible to the same set of issues as those service packs.  There is one big issue (that I consider to be a flaw) in the design for the packaging of the .NET Framework service packs and hotfixes.  The self-extracting wrapper EXE is written in managed code, so that means that if the .NET Framework is broken in any way and needs to be repaired, then the patch package will not even extract and launch correctly, and it cannot even give a useful error message.

     

  • Aaron Stebner's WebLog

    Silent install, repair and uninstall command lines for each version of the .NET Framework

    • 44 Comments

    I often get asked about how to perform silent and unattended installs for various versions of the .NET Framework.  In order to hopefully make things easier to find going forward, I decided to create a single blog post with information about silent and unattended installs, repairs and uninstalls for each shipping version of the .NET Framework.

    The command lines listed in this blog post do not apply to versions of the .NET Framework installed as a part of the OS.  You can refer to this blog post for a list of which version of the .NET Framework ships with which version of Windows.

    Note - if you try to repair or uninstall the .NET Framework and setup fails, you can try to use the .NET Framework Repair Tool to solve the problem.

    .NET Framework 1.0 product family

    .NET Framework 1.0 - silent repair

    dotnetfx.exe /q:a /c:"msiexec.exe /fpecmsu netfx.msi REBOOT=ReallySuppress /l*v %temp%\netfx10_repair_log.txt /qn"

    Note – repairing the .NET Framework 1.0 requires re-downloading the dotnetfx.exe installer and running the command line using this installer.

    .NET Framework 1.0 - unattended repair

    dotnetfx.exe /q:a /c:"msiexec.exe /fpecmsu netfx.msi REBOOT=ReallySuppress /l*v %temp%\netfx10_repair_log.txt /qb"

    Note – repairing the .NET Framework 1.0 requires re-downloading the dotnetfx.exe installer and running the command line using this installer.

    .NET Framework 1.0 - silent uninstall

    msiexec /x {B43357AA-3A6D-4D94-B56E-43C44D09E548} REBOOT=ReallySuppress /qn /l*v %temp%\netfx10_uninstall_log.txt

    Note - this command line varies depending on what language version of the .NET Framework 1.0 you have installed.  The product code listed above corresponds to the English version of the .NET Framework 1.0, so you will need to use the appropriate non-English product code in order to uninstall non-English versions of the .NET Framework 1.0.

    .NET Framework 1.0 - unattended uninstall

    msiexec /x {B43357AA-3A6D-4D94-B56E-43C44D09E548} REBOOT=ReallySuppress /qb /l*v %temp%\netfx10_uninstall_log.txt

    Note - this command line varies depending on what language version of the .NET Framework 1.0 you have installed.  The product code listed above corresponds to the English version of the .NET Framework 1.0, so you will need to use the appropriate non-English product code in order to uninstall non-English versions of the .NET Framework 1.0.

    .NET Framework 1.1 product family

    .NET Framework 1.1 - silent repair

    dotnetfx.exe /q:a /c:"msiexec.exe /fpecmsu netfx.msi REBOOT=ReallySuppress /l*v %temp%\netfx11_repair_log.txt /qn"

    Note – repairing the .NET Framework 1.1 requires re-downloading the dotnetfx.exe installer and running the command line using this installer.

    .NET Framework 1.1 - unattended repair

    dotnetfx.exe /q:a /c:"msiexec.exe /fpecmsu netfx.msi REBOOT=ReallySuppress /l*v %temp%\netfx11_repair_log.txt /qb"

    Note – repairing the .NET Framework 1.1 requires re-downloading the dotnetfx.exe installer and running the command line using this installer.

    .NET Framework 1.1 - silent uninstall

    msiexec /x {CB2F7EDD-9D1F-43C1-90FC-4F52EAE172A1} REBOOT=ReallySuppress /qn /l*v %temp%\netfx11_uninstall_log.txt

    .NET Framework 1.1 - unattended uninstall

    msiexec /x {CB2F7EDD-9D1F-43C1-90FC-4F52EAE172A1} REBOOT=ReallySuppress /qb /l*v %temp%\netfx11_uninstall_log.txt

    .NET Framework 2.0 product family

    .NET Framework 2.0 - silent repair

    %windir%\Microsoft.NET\Framework\v2.0.50727\install.exe /q

    .NET Framework 2.0 - unattended repair

    %windir%\Microsoft.NET\Framework\v2.0.50727\install.exe /qb

    .NET Framework 2.0 - silent uninstall

    %windir%\Microsoft.NET\Framework\v2.0.50727\install.exe /u /q

    .NET Framework 2.0 - unattended uninstall

    %windir%\Microsoft.NET\Framework\v2.0.50727\install.exe /u /qb

    .NET Framework 2.0 SP1 - silent repair

    msiexec /i {B508B3F1-A24A-32C0-B310-85786919EF28} REBOOT=ReallySuppress /l*v %temp%\netfx20sp1_repair_log.txt /qn

    .NET Framework 2.0 SP1 - silent uninstall

    msiexec /x {B508B3F1-A24A-32C0-B310-85786919EF28} REBOOT=ReallySuppress /l*v %temp%\netfx20sp1_uninstall_log.txt /qn

    .NET Framework 2.0 SP2 - silent repair

    msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REBOOT=ReallySuppress REINSTALL=ALL /l*v %temp%\netfx20sp2_repair_log.txt /qn

    .NET Framework 2.0 SP2 - unattended repair

    msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REBOOT=ReallySuppress REINSTALL=ALL /l*v %temp%\netfx20sp2_repair_log.txt /qb

    .NET Framework 2.0 SP2 - silent uninstall

    msiexec /x {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REBOOT=ReallySuppress /l*v %temp%\netfx20sp2_uninstall_log.txt /qn

    .NET Framework 2.0 SP2 - unattended uninstall

    msiexec /x {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REBOOT=ReallySuppress /l*v %temp%\netfx20sp2_uninstall_log.txt /qb

    .NET Framework 3.0 product family

    .NET Framework 3.0 - silent repair

    “%windir%\Microsoft.NET\Framework\v3.0\Microsoft .NET Framework 3.0\setup.exe” /q /f /norestart

    .NET Framework 3.0 - unattended repair

    “%windir%\Microsoft.NET\Framework\v3.0\Microsoft .NET Framework 3.0\setup.exe” /qb /f /norestart

    .NET Framework 3.0 - silent uninstall

    “%windir%\Microsoft.NET\Framework\v3.0\Microsoft .NET Framework 3.0\setup.exe” /q /remove /norestart

    .NET Framework 3.0 - unattended uninstall

    “%windir%\Microsoft.NET\Framework\v3.0\Microsoft .NET Framework 3.0\setup.exe” /qb /remove /norestart

    .NET Framework 3.0 SP1 - silent repair

    msiexec /i {2BA00471-0328-3743-93BD-FA813353A783} REBOOT=ReallySuppress /l*v %temp%\netfx30sp1_repair_log.txt /qn

    .NET Framework 3.0 SP1 - unattended repair

    msiexec /i {2BA00471-0328-3743-93BD-FA813353A783} REBOOT=ReallySuppress /l*v %temp%\netfx30sp1_repair_log.txt /qb

    .NET Framework 3.0 SP1 - silent uninstall

    msiexec /x {2BA00471-0328-3743-93BD-FA813353A783} REBOOT=ReallySuppress /l*v %temp%\netfx30sp1_uninstall_log.txt /qn

    .NET Framework 3.0 SP1 - unattended uninstall

    msiexec /x {2BA00471-0328-3743-93BD-FA813353A783} REBOOT=ReallySuppress /l*v %temp%\netfx30sp1_uninstall_log.txt /qb

    .NET Framework 3.0 SP2 - silent repair

    msiexec /fpecmsu {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REBOOT=ReallySuppress REINSTALL=ALL /l*v %temp%\netfx30sp2_repair_log.txt /qn

    .NET Framework 3.0 SP2 - unattended repair

    msiexec /fpecmsu {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REBOOT=ReallySuppress REINSTALL=ALL /l*v %temp%\netfx30sp2_repair_log.txt /qb

    .NET Framework 3.0 SP2 - silent uninstall

    msiexec /x {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REBOOT=ReallySuppress /l*v %temp%\netfx30sp2_uninstall_log.txt /qn

    .NET Framework 3.0 SP2 - unattended uninstall

    msiexec /x {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REBOOT=ReallySuppress /l*v %temp%\netfx30sp2_uninstall_log.txt /qb

    .NET Framework 3.5 product family

    .NET Framework 3.5 - silent repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5\setup.exe" /q /norestart

    .NET Framework 3.5 - unattended repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5\setup.exe" /qb /norestart

    .NET Framework 3.5 - silent uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5\setup.exe" /q /uninstall /norestart

    .NET Framework 3.5 - unattended uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5\setup.exe" /qb /uninstall /norestart

    .NET Framework 3.5 SP1 - silent repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /norestart

    .NET Framework 3.5 SP1 - unattended repair

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /norestart

    .NET Framework 3.5 SP1 - silent uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /uninstall /norestart

    .NET Framework 3.5 SP1 - unattended uninstall

    "%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /uninstall /norestart

     .NET Framework 4 product family

    .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 /norestart

    .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

     .NET Framework 4.5 product family

    .NET Framework 4.5 (32-bit) – silent repair

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

    .NET Framework 4.5 (32-bit) – unattended repair

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

    .NET Framework 4.5 (32-bit) – silent uninstall

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

    .NET Framework 4.5 (32-bit) – unattended uninstall

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

    .NET Framework 4.5 (64-bit) – silent repair

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

    .NET Framework 4.5 (64-bit) – unattended repair

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

    .NET Framework 4.5 (64-bit) – silent uninstall

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

    .NET Framework 4.5 (64-bit) – unattended uninstall

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

    .NET Framework 4.5.1 (32-bit) – silent repair

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

    .NET Framework 4.5.1 (32-bit) – unattended repair

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

    .NET Framework 4.5.1 (32-bit) – silent uninstall

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

    .NET Framework 4.5.1 (32-bit) – unattended uninstall

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

    .NET Framework 4.5.1 (64-bit) – silent repair

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

    .NET Framework 4.5.1 (64-bit) – unattended repair

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

    .NET Framework 4.5.1 (64-bit) – silent uninstall

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

    .NET Framework 4.5.1 (64-bit) – unattended uninstall

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

    <update date="5/13/2010"> Added information about .NET Framework 4 install, repair and uninstall. </update>

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

    <update date="5/26/2011"> Added a missing /norestart parameter to the .NET Framework 4 Full (64-bit) - silent uninstall command line. </update>

    <update date="4/22/2014"> Added information about .NET Framework 4.5 and 4.5.1 install, repair and uninstall. </update>

    <update date="4/30/2014"> Added a link to the .NET Framework Repair Tool. </update> 

  • Aaron Stebner's WebLog

    What to do if other .NET Framework setup troubleshooting steps do not help

    • 73 Comments

    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>

     

  • Aaron Stebner's WebLog

    Updated version of the .NET Framework cleanup tool that can remove the .NET Framework 3.5 RTM

    • 22 Comments

    I've posted an updated version of the .NET Framework cleanup tool that contains the following changes:

    • It is now able to remove the .NET Framework 2.0 SP1 beta and final release MSIs; it does not remove the .NET Framework 2.0 SP1 OS hotfix package on Windows Vista however
    • It is now able to remove the .NET Framework 3.0 SP1 beta and final release MSIs; it does not remove the .NET Framework 2.0 SP1 OS hotfix package on Windows Vista however
    • It is now able to remove the .NET Framework 3.5 final release (previously it only removed the beta versions)
    • It includes some additional removal options to allow removing all versions of the .NET Framework that are not OS components on Windows XP Tablet PC Edition, Windows XP Media Center Edition, Windows Server 2003, Windows Vista and Windows Server 2008

    In addition, thanks to a suggestion from a customer, I have added the readme and a change history text file to the zip file that contains the cleanup tool to make it easier to understand what the tool does, what changes were made, and whether or not you have the most recent version of the tool.

    Please refer to the .NET Framework cleanup tool user's guide to find more information about the .NET Framework cleanup tool and download it if you need it on your system.

    <update date="6/7/2010"> Fixed broken link to the cleanup tool. </update>

     

  • Aaron Stebner's WebLog

    How to install Media Center from CDs

    • 27 Comments

    I have seen questions from fellow Microsoft employees regarding how to install Windows XP Media Center edition on a brand new computer using the OS installation CDs.  This question has very rarely been asked by customers outside of Microsoft because Media Center is typically only available via an OEM reseller and comes pre-installed on the computer.  There are some cases where customers can buy machines with the installation CDs but do not have the OS installed, or the OEM provides recovery media on CD instead of on DVD.  This process is a little bit tricky so I decided to list the steps to install Media Center on a clean partition from CD.

    The process to install Media Center is different from the process to install XP Home/Pro because Media Center spans 2 CDs whereas the standard Windows XP Home/Pro product fits on a single CD.  It requires the following 2 steps that are different from standard XP Home/Pro OS setup:

    Launch OS setup with a special command line switch

    The following command lines can be used to launch Media Center setup from CD:

    • If you are launching OS setup from within Windows: <cd drive>\i386\winnt32.exe /makelocalsource:all
    • If you are launching OS setup from a boot floppy: <cd drive>\i386\winnt.exe /2

    The /makelocalsource:all and /2 command line parameters cause winnt32.exe and winnt.exe to copy the contents of CD1 and CD2 to the local hard drive at the beginning of OS setup.  If you fail to do this you will receive disk swap prompts during Media Center (or Tablet PC) OS installation.

    Enter a valid product key that matches the OS type you want to install

    After launching setup with one of the above command line parameters, the other step required to install Media Center instead of the standard XP Home/Pro OS is to enter a valid Media Center product key when prompted during OS setup.  Doing so will cause OS setup to install the .NET Framework 1.0 and Media Center components in addition to the standard XP Home/Pro components.  It will also cause your OS to be branded appropriately (for example - the left side of the start menu if you have your desktop configured for Windows Classic view will display "Media Center" instead of "Windows XP").

    Also, if you enter a Home/Pro product key, OS setup will not end up installing the .NET Framework 1.0 or the Media Center components, and you cannot use Media Center on the Home/Pro OS that you have just installed.

    Why the extra steps?!?

    Media Center setup ships with the core OS components on CD1 and the Media Center-specific OS components on CD2.  If you take a look at Media Center CD1 and compare it to XP Home/Pro CD1, you will see that the contents are nearly identical (with the exception of the EULA file and a couple other small things).  CD2 contains Media Center, Tablet PC and .NET Framework bits.  The decision about which bits to actually install happens at OS setup time and is controlled by the product key that you enter during OS setup.

    Note that even though I only mentioned Media Center, the above OS setup behaviors apply equally to Tablet PC.  Both Media Center and Tablet PC share the same underlying OS setup design and both require the extra command line switches and specific product key to be entered during setup to install the correct bits.

     

  • Aaron Stebner's WebLog

    How to clean up a SQL 2005 instance name left behind by a previous uninstall

    • 29 Comments

    I have heard from a few customers who have tried to uninstall and re-install SQL 2005 and have run into errors with both the uninstall and the re-install.  I have already described the most common uninstall error and a suggested workaround in this previous blog post (an error reading property "Installids" from the cache and/or an error writing property "flagCommit" to the cache).

    I wanted to address one of the most common SQL Express install errors I have seen - a duplicate instance name error that causes SQL setup to fail and rollback.  It is pretty easy to tell if you are running into this error if you launch SQL setup directly and step through the SQL setup UI.  However, if you are installing SQL Express as a part of Visual Studio 2005, setup runs in silent mode and you will only see a generic error bubbled up from Visual Studio setup indicating that SQL Express failed to install.

    VS 2005 configures SQL Express with an instance name of SQLEXPRESS when it runs SQL setup in silent mode.  If you previously had SQL Express installed and try to uninstall it but something goes wrong with uninstall, you may end up with an orphaned instance name on your system, and then re-installing SQL Express can fail.  In this case, the verbose setup log file for SQL Express will show an error that looks like the following:

    MSI (s) (AC!38) [00:01:41:056]: Product: Microsoft SQL Server 2005 Express Edition -- Error 28086. An instance with the same name is already installed on this computer. To proceed with SQL Server Setup, provide a unique instance name.

    Error 28086. An instance with the same name is already installed on this computer. To proceed with SQL Server Setup, provide a unique instance name.

    If you are running into an error installing SQL Express as a part of Visual Studio 2005 setup, you can check in the SQL Express log files (located at %ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG).  If you are receiving an error about the instance name not being unique, you can manually clean off the orphaned instance name by doing the following:

    1. Click on the Start menu, choose Run and type regedit
    2. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server
    3. Remove SQLEXPRESS from the REG_MULTI_SZ value named InstalledInstances
    4. Delete the subhive named MSSQL.1
    5. Delete the subhive named SQLEXPRESS
    6. Go to HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\Instance Names\SQL
    7. Delete the value named SQLEXPRESS
    8. Delete the folder %ProgramFiles%\Microsoft SQL Server\MSSQL.1

    Note - the above steps apply to the instance name that is created when SQL Express is installed as a part of Visual Studio 2005.  The actual instance name on your system may vary if you have had any other beta version of SQL 2005 (such as the developer edition).  Please make sure to adjust the steps accordingly based on what instance name information is in your registry and file system.

    <update date="7/24/2009"> Updated this post to not be beta-specific.  The same type of error can occur if you uninstall and re-install the final release of SQL Express or SQL Express service packs. </update>

     

Page 1 of 48 (1,186 items) 12345»