Aaron Stebner's WebLog

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

  • Aaron Stebner's WebLog

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

    • 309 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

    Removal tool to fix .NET Framework install failures

    • 278 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

    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

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

    • 185 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

    • 169 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

    • 134 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 work around a possible XNA Game Studio or Windows Phone SDK install failure on Windows 8

    • 113 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

    TurboTax 2009 can fail to install because it thinks the .NET Framework is not installed, even when it is

    • 109 Comments

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

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

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

    For Windows XP and Windows Server 2003

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

    For Windows Vista or Windows Server 2008

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

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

    For Windows 7

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

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

    What to do if the above doesn’t help

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

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

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

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

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

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

     

  • Aaron Stebner's WebLog

    Mailbag: How can I customize an MSI in the Visual Studio setup/deployment project?

    • 108 Comments

    Question:

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

    Answer:

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

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

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

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

    1. Download the sample script and extract the contents to the directory that contains the Visual Studio setup project you are working on.

      Note: You should end up with the file EnableLaunchApplication.js in the same directory as the .vdproj file for your setup project.  The rest of these steps will not work correctly if you do not put EnableLaunchApplication.js in the correct location, so be careful about this step.

    2. Open the file EnableLaunchApplication.js in a text editor such as notepad, locate the variable at the top of the file that is set to the value WindowsApplication1.exe, and change it to the name of the EXE that is in your setup that you want to launch when the MSI is done installing
    3. Open the project in Visual Studio
    4. Press F4 to display the Properties window
    5. Click on the name of your setup/deployment project in the Solution Explorer
    6. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
    7. Click on the "..." button to display the Post-build Event Command Line dialog
    8. Copy and paste the following command line into the Post-build event command line text box:

      cscript.exe "$(ProjectDir)EnableLaunchApplication.js" "$(BuiltOuputPath)"


    9. Save your project
    10. Build your project in Visual Studio

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

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

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

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

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

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

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

     

  • Aaron Stebner's WebLog

    Content protection errors in Update Rollup 2 for Media Center 2005

    • 106 Comments

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

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

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

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

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

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

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

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

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

     

  • Aaron Stebner's WebLog

    Possible fixes for IR receiver or remote problems after installing Update Rollup 2 for MCE 2005

    • 102 Comments

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

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

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

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

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

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

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

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

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

    4.  If none of the above suggestions work

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

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

     

  • 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

    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

    How to fix component registration failures after installing Update Rollup 2 for Media Center 2005

    • 87 Comments

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

    What are the symptoms of this issue?

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

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

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

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

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

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

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

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

    How can I workaround this issue?

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

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

    What is the root cause of this issue?

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

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

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

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

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

     

  • 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

    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

    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

    Mailbag: How to set the NoImpersonate flag for a custom action in Visual Studio 2005

    • 69 Comments

    Question:

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

    Answer:

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

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

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

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

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

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

     

  • 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

    Mailbag: How to perform a silent install of the Visual C++ 2008 redistributable packages

    • 67 Comments

    Question:

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

    Answer:

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

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

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

    Unattended install

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

    <full path>\vcredist_x86.exe /qb

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

    c:\vc2008redist\vcredist_x86.exe /qb

    Unattended install with no cancel button

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

    <full path>\vcredist_x86.exe /qb!

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

    c:\vc2008redist\vcredist_x86.exe /qb!

    Silent install

    This option will suppress all UI during installation.

    <full path>\vcredist_x86.exe /q

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

    c:\vc2008redist\vcredist_x86.exe /q

    Related links:

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

     

  • Aaron Stebner's WebLog

    Visual Studio 2008 and .NET Framework 3.5 setup log files

    • 66 Comments

    The installers for the .NET Framework 3.5 and Visual Studio 2008 chain several different prerequisites and optional components behind the scenes.  If one of these setups fails, there are numerous possible causes due to the number of packages being chained behind the scenes.  The following provides a list of log files created by the setup wrappers for each product and the child packages that are chained in during installation. 

    .NET Framework 3.5 setup log files

    The following is a complete list of log files that can be produced during .NET Framework 3.5 setup.  This list may vary depending on what OS you are installing on, what processor architecture, and what prerequisite components were already installed on the system prior to running .NET Framework 3.5 setup.

    Logs produced by the .NET Framework 3.5 setup wrapper:

    • %temp%\dd_dotnetfx35install.txt
    • %temp%\dd_dotnetfx35error.txt
    • %temp%\dd_depcheck_netfx*.txt

    Logs produced by the packages chained during .NET Framework 3.5 setup:

    • RGB Rasterizer - %temp%\dd_RGB9Rast_*.txt
    • MSXML 6.0 - %temp%\dd_msxml6_*.txt
    • WIC - %temp%\dd_wic*.txt
    • .NET Framework 2.0 SP1 - %temp%\dd_net_framework20*.txt
    • .NET Framework 3.0 SP1 - %temp%\dd_net_framework30*.txt
    • .NET Framework 3.0 SP1 WCF custom action - %temp%\dd_wcf_retCA*.txt
    • .NET Framework 3.5 product MSI - %temp%\dd_net_framework35*.txt

    Visual Studio 2008 setup log files

    The following is a complete list of log files that can be produced during Visual Studio 2008 setup.  This list may vary depending on what OS you are installing on, what processor architecture, and what prerequisite components were already installed on the system prior to running Visual Studio 2008 setup.

    In addition to the logs listed below, Visual Studio 2008 setup can produce the logs listed above for the .NET Framework 3.5 because the .NET Framework 3.5 is a prerequisite that is chained in during Visual Studio 2008 setup if it is not already installed on the system.

    Logs produced by the Visual Studio 2008 setup wrapper:

    • %temp%\dd_install*.txt
    • %temp%\dd_error*.txt
    • %temp%\dd_depcheck*.txt
    • VSMsiLog*.txt - located in your %temp% directory during Visual Studio 2008 setup; moved to %ProgramFiles%\Microsoft Visual Studio 9.0\<product name>\Logs after a successful installation; left in %temp% after a failed installation and after uninstallation

    Logs produced by the packages chained during Visual Studio 2008 setup:

    • Windows Installer 3.1 - %windir%\KB893803v2.log
    • .NET Framework 3.5 - see the full list of logs at the top of this post
    • Visual Studio 2008 64bit Prerequisites - %temp%\dd_prereq*.txt
    • Document Explorer 2008 - %temp%\dd_dexplore*90*.txt
    • Web Designer Tools - %temp%\SetupExe(*).txt
    • .NET Compact Framework 2.0 SP2 - %temp%\dd_netcfsetupv2*.txt
    • .NET Compact Framework 3.5 - %temp%\dd_netcfsetupv35*.txt
    • Visual Studio Tools for Office Runtime 3.0 - %temp%\dd_vstor*.txt
    • Visual Studio 2005 Tools for the 2007 Microsoft Office System Runtime - %temp%\dd_vsto_ret20*.txt
    • SQL Server Compact Edition 3.5 - %temp%\dd_SSCERuntime*.txt
    • SQL Server Compact Edition 3.5 Design Tools - %temp%\dd_SQLCEToolsForVS2007*.txt
    • SQL Server Compact Edition 3.5 For Devices - %temp%\dd_SSCEDeviceRuntime*.txt
    • Windows Mobile 5.0 SDK R2 for Pocket PC - %temp%\dd_WMPPC_5_0*.txt
    • Windows Mobile 5.0 SDK R2 for Smartphone - %temp%\dd_WMSP_5_0*.txt
    • Device Emulator version 3.0 - %temp%\dd_64bitEmulator*.txt, %temp%\dd_EmulatorForWinXP*.txt and/or %temp%\dd_Emulator*.txt
    • SQL Server 2005 Express Edition - %programfiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\*.*
    • Visual Studio 2008 Remote Debugger - %temp%\dd_rdbg*.txt
    • Windows SDK - %temp%\dd_winsdk*.txt
    • Visual Studio Performance Collection Tools - %temp%\dd_Performance_Collection_Tools*.txt
    • Crystal Reports - %temp%\dd_CrystalReports2007*.txt

    Logs produced by the packages chained during Visual Studio 2008 Express Edition setups:

    • Windows Installer 3.1 - %windir%\KB893803v2.log
    • .NET Framework 3.5 - see the full list of logs at the top of this post
    • SQL Server Compact Edition 3.5 - %temp%\dd_SSCERuntime*.txt
    • SQL Server Compact Edition 3.5 Design Tools - %temp%\dd_SQLCEToolsForVS2007*.txt
    • Visual Studio 2008 Remote Debugger Light - %temp%\dd_ExpRemoteDbg*.txt
    • Windows SDK - %temp%\dd_winsdk*.txt
    • MSDN for Visual Studio Express Editions - %temp%\dd_MSDNExp*.txt
    • Silverlight 1.0 - %temp%\Silverlight*.txt

    Logs produced by the MSDN for Visual Studio 2008 setup wrapper:

    • %temp%\dd_install_MSDN_VS_90*.txt
    • %temp%\dd_error_MSDN_VS_90*.txt
    • %temp%\dd_depcheck_MSDN_VS_90*.txt
    • VSMsiLog*.txt - located in your %temp% directory during MSDN setup; moved to %ProgramFiles%\MSDN\MSDN9.0\<product name>\Logs after a successful installation; left in %temp% after a failed installation and after uninstallation

    Logs produced by Visual Studio 2008 SP1:

    • %temp%\Microsoft Visual Studio 2008 SP1*.* 

    If you run into any issues while installing the .NET Framework 3.5, Visual Studio 2008 or MSDN for Visual Studio 2008 and plan to report setup issues to Microsoft via the product feedback site or the MSDN Forums, please locate and include any of the above log files if possible because it will make it easier for us to debug the failures and find root causes and workarounds.

    <update date="10/4/2007"> Added a log file to the .NET Framework 3.5 list for the WCF custom action that I missed previously </update>

    <update date="1/11/2008"> Added Silverlight log files to the list for VS 2008 Express Editions since it was added as a chained component between the time I wrote this blog post and the time that VS 2008 shipped. </update>

    <update date="5/23/2008"> Added log file information for Visual Studio 2008 SP1 </update>

    <update date="11/20/2009"> Fixed broken link to the product feedback site. </update>

     

  • Aaron Stebner's WebLog

    Resolving Tuner Not Found errors in Update Rollup 2 for Media Center 2005

    • 66 Comments

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

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

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

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

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

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

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

     

  • Aaron Stebner's WebLog

    Possible .NET Framework 3.5 installation failure caused by broken MSXML registration

    • 65 Comments

    The .NET Framework 3.5 can fail to install on a system where MSXML is not properly registered.  There is a custom action that runs during .NET Framework 3.5 setup that tries to use some APIs in MSXML to modify some information in the web_mediumtrust.config file that is a part of the .NET Framework 2.0.  In the cases that we've seen of this issue so far, one of the MSXML CLSID values was somehow unregistered on the system, and that causes this custom action to fail.

    How to diagnose this issue from the .NET Framework 3.5 setup log file

    This issue will cause the following information to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):

    MSI (s) (58:94) [11:11:11:829]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI35C6.tmp, Entrypoint: ExecXmlConfig
    MSI (s) (58:F0) [11:11:11:829]: Generating random cookie.
    MSI (s) (58:F0) [11:11:11:829]: Created Custom Action Server with PID 4936 (0x1348).
    MSI (s) (58:74) [11:11:11:860]: Running as a service.
    MSI (s) (58:00) [11:11:11:860]: Hello, I'm your 32bit Elevated custom action server.
    ExecXmlConfig:  Error 0x80040154: failed to load XML file: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web_mediumtrust.config
    MSI (s) (58!50) [11:11:11:954]: Product: Microsoft .NET Framework 3.5 -- Error 25541.Failed to open XML file C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web_mediumtrust.config, system error: -2147221164

    How to work around this issue

    You can use one of the following options to work around this issue if you encounter it during .NET Framework 3.5 setup.  Note that these workarounds are only useful for this exact error and HRESULT value.  They will not help fix all possible .NET Framework 3.5 setup failures.

    1. Re-register msxml3.dll by running regsvr32 msxml3.dll
    2. Re-install MSXML3 by downloading and installing the package from http://www.microsoft.com/downloads/details.aspx?familyid=28494391-052b-42ff-9674-f752bdca9582

    More details about the root cause of this issue

    In the example log file above, the HRESULT value is 0x80040154, which means that a class is not registered.  On systems where we have seen this error, the root MSXML CLSID is listed in the registry at the following location:

    [HKEY_CLASSES_ROOT\Msxml2.DOMDocument\CLSID]
    @="{F6D90F11-9C73-11D3-B32E-00C04F990BB4}"

    However, the following sub-key for this CLSID was not present on this system:

    [HKEY_CLASSES_ROOT\CLSID\{F6D90F11-9C73-11D3-B32E-00C04F990BB4}]

    The suggested workarounds listed above will re-register this CLSID, which has fixed this issue in the cases we have seen of this error so far.

  • Aaron Stebner's WebLog

    How to install the Windows Phone Developer Tools on Windows Server 2008

    • 65 Comments

    The Windows Phone Developer Tools are not officially supported on operating systems other than Windows Vista or Windows 7.  In between the CTP and the CTP Refresh, a block was added to setup to prevent installing on Windows Server 2008 to help enforce this support limitation.  I’ve heard from some folks who were using the original CTP on Windows Server 2008 who cannot move forward to the CTP Refresh or the final release because of this block.

    There is a way you can work around the Windows Server 2008 setup block if needed.  Please note that this is not officially supported, so if you try these steps, you are doing so at your own risk.

    1. Download the Windows Phone Developer Tools web bootstrapper and save it to your hard drive
    2. Extract the contents of the setup package by running vm_web.exe /x and choosing a path to extract to
    3. Go to the folder you extracted to in step 2 and open the file baseline.dat in notepad
    4. Look for the section named [gencomp7788]

      Note - you have to change this exact section - this is the one that controls the OS version blocking behavior in Windows Phone Developer Tools setup.
       
    5. Change the value InstallOnLHS from 1 to 0
    6. Change the value InstallOnWin7Server from 1 to 0
    7. Save and close baseline.dat
    8. Run setup.exe /web from the folder you extracted to in step 2

      Note - please make sure that you include the /web command line parameter in step 8.  If you don't, setup will not attempt to download the packages it needs to install, and it will fail to install correctly as a result.

    <update date="9/17/2010"> Added an emphasis on steps 4 and 8 - setup will fail if you don't pass in the /web switch when using these steps.  Also updated the steps for the final RTW build of Windows Phone Developer Tools. </update>

     

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