Aaron Stebner's WebLog

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

  • Aaron Stebner's WebLog

    Sample code to detect .NET Framework 1.0 and 1.1 and service packs

    • 18 Comments

    Hey all,

    In response to some suggestions from folks who read my blog posts describing how to detect the presence of .NET Framework 1.0 service packs and .NET Framework 1.1 service packs, I wrote up a quick sample application that shows how to implement the detection methods I recommended.  You can download the sample code here.

    In this sample, I detect the presence of the .NET Framework core packages for 1.0 and 1.1, and then if I find that they are installed, I detect the service pack level also.  The sample simply pops up a message box for each version, but could be easily updated to perform some conditional action (as part of a 3rd party setup or something like that).

    The code is provided as an example only....I hope it will help better explain how to implement a detection strategy for the .NET Framework and its service packs that will continue to work when future service packs are released.  Let me know if you have any problems or questions.....

    <update date="6/4/2010"> Fixed broken link to the sample code. </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

    How to troubleshoot failure to install Document Explorer 2005 during VS 2005 setup

    • 45 Comments

    I have heard from several customers who have run into problems installing Visual Studio 2005 because the component named Microsoft Document Explorer 2005 fails to install and Visual Studio setup quits when that happens.  I wanted to give a bit more information about what this component is and where logging information can be found to attempt to track down why this installation might fail.

    Document Explorer 2005 is a redistributable package that delivers the 8.0 version of dexplore.exe.  This is the help viewer that is used by Visual Studio 2005, and by other products such as the Windows SDK.  In previous versions of Visual Studio, dexplore.exe was installed as a part of the main Visual Studio MSI or as a part of the MSDN MSI, but in VS 2005, it was separated into its own standalone package, and it is installed as a prerequisite before the main Visual Studio MSI.

    The setup for Document Explorer 2005 uses the same external UI handler as the .NET Framework 2.0 redistributable and SDK (described in more detail in this blog post and in this blog post).

    Visual Studio 2005 setup runs the setup package for Document Explorer 2005 in silent mode.  In cases where this package fails during Visual Studio 2005 setup, you can run dexplore.exe directly from the folder <VS install disc>\wcu\DExplore\ in order to see the error message that is being generated.

    This package creates the following log files in the %temp% directory on a system:

    • dd_dexploreui*.txt
    • dd_dexploremsi*.txt

    In both of these cases, the * in the name of the files is a randomly generated ending to ensure that each time you run setup it will create a unique file and not overwrite existing log files.

    If you do not get any useful error information by running the setup package directly, it can be useful to examine the contents of these log files.  In particular, you can search for the string return value 3 in dd_dexploremsi*.txt and that will usually lead you to the error that causes the setup package to fail.

    If you have trouble locating error information, please contact me or leave a comment on this blog post and I will try to help.

     

  • Aaron Stebner's WebLog

    How to manually install the various pieces of Update Rollup 2 for Media Center 2005

    • 33 Comments

    I have previously written about a couple of instances where Update Rollup 2 for Windows XP Media Center Edition 2005 setup can fail because other Windows hotfixes have been installed in such a way that they interfere with the hotfixes that Update Rollup 2 tries to install.  Those cases and steps to workaround them are described here and here.

    A few customers who have run into one of these issues have been unable to use the recommended workarounds because the conflicting hotfix fails to uninstall correctly.  This can happen due to uninstall bugs in the other hotfixes or in cases where the other hotfixes were installed with a command line switch that intentionally prevents it from being uninstalled.

    If you are unable to install Update Rollup 2 due to a conflicting hotfix that cannot be uninstalled, you can use the following steps to extract the individual pieces of Update Rollup 2 setup and install them individually to workaround this problem. 

    NOTE: These steps should only be used as a last resort, so please make sure to try the other workarounds that I have documented before trying these steps.

    1. Download the setup package for Update Rollup 2 and save it to your local hard drive
    2. Click on the Start menu, choose Run and type cmd
    3. Change directories to the folder that you saved the Update Rollup 2 setup package to in step 1 by typing cd /d <directory> (you will need to replace <directory> in this command with the actual path that you saved the Update Rollup 2 setup package to in step 1, for example - cd /d c:\downloads)
    4. Run WindowsXPMediaCenter2005-KB900325-usa.exe /x:c:\temp to extract the contents to a temporary folder
    5. Type cd /d c:\temp\bin to change to the directory you extracted the Update Rollup 2 setup package to in step 4 above
    6. Run WindowsMedia10-KB895572-x86.exe /norestart (this may fail due to this issue; if it does, ignore the failure and continue on to the next package)
    7. Run WindowsXP-KB891593-x86.exe /norestart (this may fail due to this issue; if it does, ignore the failure and continue on to the next package)
    8. Run WindowsXP-KB895961-x86.exe /norestart
    9. Run WindowsXP-KB899337-v2-x86.exe /norestart (this may fail due to this issue; if it does, ignore the failure and continue on to the next package)
    10. Run WindowsXP-KB899510-x86.exe /norestart
    11. Run WindowsXP-KB888795-x86.exe /norestart
    12. Run WindowsXP-KB902841-x86.exe /norestart
    13. Run KB900325.exe /norestart
    14. Run wmfdist95.exe /Q:A /R:N /c:"wmsetsdk.exe /WMFDIST /Q /R:N /DisallowSystemRestore"
    15. Reboot your system

     

  • Aaron Stebner's WebLog

    Details about setup for the .NET Framework 2.0 configuration tool

    • 40 Comments

    Ever since I posted this blog entry last month about how the Administrative Tools shortcuts were moved from the .NET Framework 2.0 redistributable to the SDK, I have gotten multiple follow-up questions and comments from customers about this scenario.  In most cases, the folks who contacted me are system administrators who manage servers and want to change .NET Framework security settings but do not want to incur the overhead of installing the entire SDK on their server.

    I was on the .NET Framework setup team when the decision was originally made to move the configuration tool to the SDK and remove the wizard tool altogether.  At the time, the setup team and the feature teams decided that these type of graphical user interfaces were advanced features more appropriate to an SDK than to a redistributable that is intended to be installed on end-user machines.  For example, many end users on XP Home found it strange to see administrative tools related to a product called the .NET Framework that they did not know was even installed on their system (because it was pre-installed by their OEM or via some other application).

    However, after hearing so much feedback I decided to dig into this scenario in a bit more detail, especially considering that I hadn't thought through the scenario where a system administrator would have to install a 300+ megabyte SDK in order to manage security policy settings.

    According to the folks I know on various .NET Framework teams, the official way to administer security settings on a system that only has the .NET Framework 2.0 redistributable installed (and not the .NET Framework 2.0 SDK or Visual Studio 2005) is to use the command-line tool named caspol.exe that ships in %windir%\Microsoft.NET\Framework\v2.0.50727 as part of the .NET Framework 2.0 redistributable.  There is some in-depth information about how to do this in this MSDN document.

    That being said, I decided to look into the .NET Framework 2.0 SDK setup to see exactly how the configuration tool is installed and determine whether or not there is an easy way to extract that information and transplant it onto a machine with only the .NET Framework 2.0 redist installed.  I started by downloading the .NET Framework 2.0 SDK, extracting netfxsdk.msi from the setup.exe package and opening it in Orca.  I found the following information:

    • The configuration tool appears to be comprised of 4 files - mscorcfg.dll, mscorcfg.msc, mscormmc11.cfg and mscormmc.dll
    • The file mscorcfg.dll is installed to the GAC and to the local file system
    • There are several registry entries associated with the component that installed mscormmc.dll
    • There is a shortcut to mscorcfg.msc that gets installed to the Administrative Tools folder on the system

    Armed with this data, I decided to experiment a bit and see if I could build an MSI package that would install the configuration tool on a system that already had the .NET Framework 2.0 installed.  I used the WiX toolset and created an MSI with the information described above.  Then I installed it on a system that had only the .NET Framework 2.0 redistributable and it appeared to work correctly, though I haven't used this tool much in the past to truly know how well it was functioning.

    If you are curious, you can see the WiX source (WXS) file that I created for this experiment to get a better idea of how things are structured, and you can compile it into an MSI yourself by downloading the latest build of the WiX toolset.  Alternatively, you can download a compiled version of this MSI from this location.

    Please note that while it appears to work correctly, this method of installing the .NET Framework 2.0 configuration tool is unsupported.  For example, if any security related issues were to be found in any of these files, they would not be serviceable if installed on a system using a means such as this.

    <update date="12/17/2008"> Updated the WiX source code from WiX v2.0 to WiX v3.0 and added a download link for the compiled MSI. </update>

    <update date="3/11/2009"> Updated download links to point to my new file server. </update>

     

  • Aaron Stebner's WebLog

    Mailbag: How to detect the presence of the Visual C++ 2010 redistributable package

    • 57 Comments

    Question:

    I have seen your previous blog posts that describe how to detect the presence of the Visual C++ 2005 redistributable package and the Visual C++ 2008 redistributable package.  I am creating an installer that requires the Visual C++ 2010 runtime files.  How can I detect the presence of the Visual C++ 2010 redistributable package?

    Answer:

    Unlike the Visual C++ 2005 and 2008 redistributable packages, there are registry keys that can be used to detect the presence of the Visual C++ 2010 redistributable package.

    Visual C++ 2010 redistributable package detection registry values




    Alternatively, like in past releases of the Visual C++ redistributable package, you can use an algorithm like the one I described in my previous blog posts to detect the presence of the Visual C++ 2010 redistributable package on a system:

    1. Call the MsiQueryProductState API
    2. Pass in the product code for the package that you want to detect based on the list below
    3. Check the return value of this API.  If it is anything other than INSTALLSTATE_DEFAULT, the package is not yet installed

    Visual C++ 2010 redistributable package product codes

    Visual C++ 2010 SP1 redistributable package product codes

    <update date="4/12/2011"> Added product codes for Visual C++ 2010 SP1 redistributable packages. </update>

     

  • Aaron Stebner's WebLog

    What .NET Framework version numbers go with what service pack

    • 12 Comments

    I got a comment from a customer in response to a previous blog post asking about file versions for the various versions and service packs of the .NET Framework.  I was planning on just navigating to an MSDN site and replying with a link, but I couldn't find anything like that in any MSDN article or any KB article, so I figured I could come up with a quick table listing them.  Keep in mind that not every file is updated by every service pack, so you may not see this exact version for all of the files that are part of the .NET Framework.  Also, because of some of the magic that the Visual Studio and .NET Framework build lab uses to build some of the files that are part of the .NET Framework, you may see a .NET Framework-like version number (one that starts with 1.0, 1.1, or 2.0) or a Visual Studio-like version number (one that starts with 7.0, 7.10, or 8.0).

    .NET Framework product version

    Service pack level

    Version

    .NET Framework 1.0

    Original release

    1.0.3705.0 and 7.0.9466.0

    .NET Framework 1.0

    Service pack 1

    1.0.3705.209

    .NET Framework 1.0

    Service pack 2

    1.0.3705.288 and 7.0.9502.0

    .NET Framework 1.0

    Service pack 3

    1.0.3705.6018 and 7.0.9951.0

    .NET Framework 1.1

    Original release

    1.1.4322.573 and 7.10.3052.4

    .NET Framework 1.1

    Service pack 1

    1.1.4322.2032 (if you have the MSI-based 1.1 SP1 installed) or 1.1.4322.2300 (if you have the OCM-based 1.1 SP1 installed on Windows Server 2003) and 7.10.6001.4

    .NET Framework 2.0

    Beta 1

    2.0.40607.16 and 8.0.40607.16

    .NET Framework 2.0

    Beta 2

    2.0.50215.44 and 8.0.50215.44

    .NET Framework 2.0

    Original release

    2.0.50727.42 and 8.0.50727.42

    .NET Framework 2.0

    Service pack 1

    2.0.50727.1433 and 8.0.50727.1433

    .NET Framework 2.0

    Service pack 2

    2.0.50727.3053 and 8.0.50727.3053

    .NET Framework 3.0

    Original release

    3.0.04506.26 (on Windows Vista) and 3.0.04506.30 (on downlevel operating systems)

    .NET Framework 3.0

    Service pack 1

    3.0.04506.648

    .NET Framework 3.0

    Service pack 2

    3.0.04506.2152

    .NET Framework 3.5

    Original release

    3.5.21022.8 and 9.0.21022.8

    .NET Framework 3.5

    Service pack 1

    3.5.30729.1 and 9.0.30729.1

    .NET Framework 4

    Original release

    4.0.30319.1 and 10.0.30319.1

    Please note that it is definitely not reliable to use the file versions in the above table to detect the installed service pack level.  If you're interested in accurately determining what version of the .NET Framework is installed and what service pack is installed I would recommend checking out the blog post and sample code that I previously posted at this location.

    <update date="1/31/2006"> Added another possible version number for 1.1 SP1.  The files have different versions depending on whether you have the MSI-based .NET Framework 1.1 package installed or the OCM-based .NET Framework 1.1 package that is included as a part of Windows Server 2003 </update>

    <update date="3/3/2006"> Added a column to the table for the final release of the .NET Framework 2.0 now that it has shipped </update>

    <update date="3/20/2007"> Added a column to the table for the final release of the .NET Framework 3.0 now that it has shipped </update>

    <update date="3/6/2008"> Added columns to the table for the .NET Framework 2.0 SP1, the .NET Framework 3.0 SP1 and the .NET Framework 3.5 now that they have shipped </update>

    <update date="8/14/2008"> Added columns to the table for the .NET Framework 2.0 SP2, the .NET Framework 3.0 SP2 and the .NET Framework 3.5 SP1 now that they have shipped </update>

    <update date="4/27/2010"> Added a column to the table for the .NET Framework 4 </update>

     

  • Aaron Stebner's WebLog

    How to manually reset folder and file permissions in Windows Explorer

    • 8 Comments

    As I was typing out an earlier blog entry about resolving access denied (0x80070005) errors that can happen while installing the .NET Framework, I was intending to link to a post that listed the steps you can take to reset permissions (ACLs) for folders, files and registry keys.  Then as I searched through my previous blog posts I couldn't actually find a post where I listed those steps, so I figured I should list them as a standalone post.

    Resetting folder/file permissions

    1. Launch an instance of Windows Explorer
    2. Navigate to the parent of the folder that you want to reset permissions for
    3. Right-click on the folder and choose Sharing and Security...
    4. Click on the Security tab
    5. Click the Advanced button
    6. Set the permissions you want - typically you will want to allow Administrators, System, and Creator Owner to have full control
    7. Check the box labeled Replace permission entries on all child objects with entries shown here that apply to child objects
    8. Click OK
    9. Click Yes in the dialog box that appears asking if you are sure
    10. Wait while Windows recursively applies the specified permissions to all sub-folders and files

    Also note that there is a tool named subinacl.exe that can be used to automate the process of resetting folder, file and registry permissions so that you don't have to use the set of steps listed above.


     

  • Aaron Stebner's WebLog

    Assembly installation error codes in .NET Framework 2.0 setup

    • 47 Comments

    I have written several posts in the past about 1935 errors that can happen during the installation of the .NET Framework and other applications that install managed code to the GAC (most notably, this troubleshooting guide).

    Starting in version 2.0, you will no longer see 1935 errors during .NET Framework redistributable setup.  This is because we created a new custom action to install assemblies to the GAC instead of using the built-in MsiAssembly and MsiAssemblyName tables.  This custom action was created to eliminate the need to carry 2 copies of each assembly in the setup package for the .NET Framework in order to install to both the GAC and the local file system.  More information about why we would otherwise need to carry 2 copies of each assembly can be found in this previous blog post.

    The custom action that installs assemblies to the GAC during .NET Framework setup calls fusion APIs directly and uses information in the custom MSI tables named Assembly and AssemblyName (instead of MsiAssembly and MsiAssemblyName) to determine what assemblies to install to the GAC.  The custom action also logs a new set of error codes in case of any failures.

    The following is a list of all possible assembly installation errors that can occur during .NET Framework 2.0 setup:

    • 25000 = "Unexpected error occurred during assembly configuration. This setup package may be bad."
    • 25001 = "Unexpected error occurred during assembly configuration. Function '[2]()' returned [3]."
    • 25002 = "Error occurred while initializing fusion. Unable to load [2]. System error: [3]"
    • 25003 = "Error occurred while initializing fusion."
    • 25004 = "Failed to execute query '[2]'. Is table AssemblyName missing in the MSI package?"
    • 25005 = "There's no matching record for component '[2]' in AssemblyName table."
    • 25006 = "Error occurred while initializing fusion. Setup could not find function 'LoadLibraryShim' in mscoree.dll. System error: [2]"
    • 25007 = "Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: [2]"
    • 25008 = "Unexpected error occurred during assembly installation."
    • 25010 = "Failed to install assembly '[2]' because the check of the module's hash failed." (the equivalent of fusion error code

      0x80131039 - COR_E_MODULE_HASH_CHECK_FAILED)
      25011 = "Failed to install assembly '[2]' because one or more modules specified in the manifest cannot be found." (the equivalent of fusion error code 0x80131042 - FUSION_E_ASM_MODULE_MISSING)

    • 25012 = "Failed to install assembly '[2]' because one or more modules were streamed in which did not match those specified by the manifest. Invalid file hash in the manifest?" (the equivalent of fusion error code 0x80131043 - FUSION_E_UNEXPECTED_MODULE_FOUND)
    • 25013 = "Failed to install assembly '[2]' because strong name signature could not be verified. Was the assembly built delay-signed?" (the equivalent of fusion error code 0x80131045 - FUSION_E_SIGNATURE_CHECK_FAILED)
    • 25014 = "Failed to install assembly '[2]' because of invalid file or assembly name. The name of the file must be the name of the assembly plus .dll or .exe." (the equivalent of fusion error code 0x80131047 - FUSION_E_INVALID_NAME during install)
    • 25015 = "Failed to install assembly '[2]' because of system error: [3]" (this is a catch-all for all error codes not listed above during installation)
    • 25020 = "Failed to uninstall assembly '[2]' because the strong name is not valid." (the equivalent of fusion error code 0x80131047 - FUSION_E_INVALID_NAME during uninstall)
    • 25021 = "Uninstall of assembly '[2]' is not allowed." (the equivalent of fusion error code 0x80131049 - FUSION_E_UNINSTALL_DISALLOWED)
    • 25022 = "Failed to uninstall assembly '[2]' because of system error: [3]" (this is a catch-all for all error codes not listed above during uninstallation)

     

  • Aaron Stebner's WebLog

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

    • 45 Comments

    Question:

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

    Answer:

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

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

    Silent install

    This option will suppress all UI and perform an install.

    <full path>\vcredist_x86.exe /q /norestart

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

    c:\vc2010redist\vcredist_x86.exe /q /norestart

    Unattended install

    This option will display a progress dialog (but requires no user interaction) and perform an install.

    <full path>\vcredist_x86.exe /passive /norestart

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

    c:\vc2010redist\vcredist_x86.exe /passive /norestart

    Silent repair

    This option will suppress all UI and perform a repair.

    <full path>\vcredist_x86.exe /q /repair /norestart

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

    c:\vc2010redist\vcredist_x86.exe /q /repair /norestart

    Silent uninstall

    This option will suppress all UI and perform an uninstall.

    <full path>\vcredist_x86.exe /q /uninstall /norestart

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

    c:\vc2010redist\vcredist_x86.exe /q /uninstall /norestart

    A note about reboots

    All of the examples above use the /norestart switch to suppress reboots after the setup process completes.  The /norestart switch does not eliminate the need to reboot entirely – it just gives the calling process control over when to schedule the reboot if one is needed due to files being in use during setup.  If you run the Visual C++ 2010 redistributable setup and use the /norestart switch, you must check the exit code returned by the setup process and handle it accordingly in the calling process.  Here are the possible exit codes:

    • Exit code 0 means that setup succeeded and no reboot is needed.
    • Exit code 3010 means that setup succeeded and a reboot is needed to complete installation.
    • Any other exit code means that setup failed.

    Related link

  • Aaron Stebner's WebLog

    What to do if I get package load failures in the final release of VS 2005?

    • 47 Comments

    IMPORTANT UPDATE - I have posted an updated set of steps for working around package load failures.  Please read that blog post instead of this post because it contains additional information not listed here.  I do not want to take this post down because I want to keep the comments so others can read them, but this post is essentially obsolete due to the new blog entry I have posted.

    Since the final release of Visual Studio 2005 and the .NET Framework 2.0, I have heard from several customers who have been using beta versions of VS, SQL and .NET 2.0, and have followed the uninstall steps to the best of their ability (including trying the auto-uninstall tool linked at the top of the uninstall instructions page) but are still encountering Package Load Failure error messages in the VS IDE after installing the final release.

    If you currently have the final release of any version of VS 2005 installed (including the Express Editions), and you are encountering package load failures, here is what I recommend that you do to resolve these issues:

    1.  Try to run the VS 2005 troubleshooting tool

    Before trying the next set of steps, please download and run the VS 2005 troubleshooting tool.  This tool is built on the same code base as the auto-uninstall tool, but it has knowledge of some specific problems that existed in previous beta versions of VS 2005 and knows how to go in and surgically clean them up.

    2.  Try to run the following command line to clear out the native image cache

    Click on the Start menu, choose Run and type cmd, then type rd /s /q %windir%\assembly\NativeImages_v2.0.50727_32\Microsoft.VisualStu# and press enter to remove native images from the cache.

    3.  Manually search for orphaned files in the GAC

    I have found that there are some cases where some additional files are getting orphaned on the machine that my test scenarios haven't caught yet (because we shipped a lot of different beta versions and I don't have the time to test out every uninstall permutation, etc).  If I haven't seen the issue in my testing, it hasn't been added to the troubleshooting tool and therefore that tool won't always be helpful.

    In general, the orphaned files that cause package load failures are located in the GAC (which is located at %windir%\assembly on your machine).  So, if you have already run the troubleshooting tool and are still running into package load failures, here are some additional steps that have proven useful in identifying additional orphaned files:

    1. Download the FSnap tool and extract it to c:\fsnap.exe on your machine
    2. Run c:\fsnap.exe /bs c:\windows\assembly\ > c:\file_list.txt
    3. Look at the contents of c:\file_list.txt for any files with version number 2.0.xxxxx.xx or 8.0.xxxxx.xx where the xxxxx.xx is not equal to 50727.42
    4. Remove the files that fit this criteria using gacutil.exe (which is installed to %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin if you have VS 2005 installed and chose to install the .NET Framework SDK tools, or can be installed by installing the .NET Framework 2.0 SDK) or by using DOS commands in a cmd prompt

    I have found it useful to import the contents of c:\file_list.txt into Excel and then sort alphabetically by column G (which is the file version column).  That makes it easier to zero in on files that have suspicious version information.

    Please note that you will need to change the paths in the steps above if you have your OS installed on a drive other than C.  Also, make sure that you include the trailing \ after the "assembly" folder name or else the FSnap tool will not work correctly. 

    4.  Help me make the troubleshooting tool better

    If you use FSnap and manually delete files and that resolves the package load failures you are seeing, I would appreciate it if you could let me know which files you removed that fixed the issue (either via the contact form or a comment on this post).  If I see common problems that the tool is not yet able to fix, I can add them to the tool and post an updated version to help everyone else out who might hit the same issue.

    Hopefully this will help resolve any lingering package load failure issues that you might be seeing.  If these steps still do not work please contact me and let me know.

    <update date="11/18/2005"> Added an additional step to clear out the native image cache based on findings I posted here </update>

    <update date="12/16/2005"> Added an updated link to a newer set of steps at the top of this blog post </update>

     

  • Aaron Stebner's WebLog

    Update Rollup 2 setup failure while installing KB891593

    • 48 Comments

    I have heard from a couple of customers who have encountered an error during setup for Update Rollup 2 for Media Center 2005, and setup then fails with a generic message (which simply states that setup failed).  In the cases I have seen so far, one of the prereqisite packages for Update Rollup 2 (a DShow hotfix described by KB891593) failed to install because there was another hotfix installed that updates the same file (another DShow hotfix described by KB904706).

    This does not happen on all computers that have KB904706 installed before attempting to install Update Rollup 2, but since it has been seen by multiple people now I wanted to post a workaround here just in case anyone else runs into it.

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

    You can diagnose this issue by looking at a couple of the log files that Update Rollup 2 setup creates.  First, you can open %windir%\mcsetup.log in a text editor such as Notepad.  If KB891593 is the package that fails on your system, you will see the following entry in mcsetup.log:

    Generic Package:   09/20/05. 09:00:44
    Looking for existing install of the generic package
    Creating Process: WindowsXP-KB891593-x86.exe /quiet /norestart
    Process returned 0x00000643

    The 0x00000643 return code (which translates to 1603 in decimal) represents the return code for a generic error in a Windows hotfix package.

    Now, you can look at %windir%\kb891593.log to determine the exact reason why this hotfix failed to install.  In the cases I have seen so far, the error in kb891593.log looks like the following:

    3.437: DoInstallation: Installation was canceled because migration is blocked by following files:
    3.437: Package KB904706, File c:\windows\system32\dllcache\quartz.dll, Version 6.5.2600.2749, Branch SP2GDR
    3.437: Package KB904706, File c:\windows\system32\quartz.dll, Version 6.5.2600.2749, Branch SP2GDR
    3.453: KB891593 Setup encountered an error:  Failed to migrate dependent packages.

    How can I workaround this issue?

    In the cases I have seen so far, uninstalling KB904706 and then attempting to reinstall Update Rollup 2 has proven successful.  The following steps can be used to accomplish this:

    1. Go to the Control Panel and choose Add or Remove Programs
    2. Check the box labeled Show updates in the top middle of the Add or Remove Programs window
    3. Locate the section named Windows XP - Software Updates and choose to uninstall the package named Security Update for Windows XP (KB904706)
    4. Attempt to install Update Rollup 2 again by returning to Windows Update or running the setup package located here

    Note: Once you have successfully installed Update Rollup 2 for Media Center 2005, you can safely reinstall KB904706 on your system if you would like to.

    What is the root cause of this issue?

    We are still trying to identify an exact root cause for this problem.  Both KB891593 and KB904706 try to update the file %windir%\system32\quartz.dll, but there is a mechanism within the Windows hotfix setup wrapper (update.exe) that accounts for overlapping files and migrates copies of the file appropriately.  We have attempted to reproduce this issue in our test lab and in the cases we have tried, Update Rollup 2 setup succeeds, and there is information like the following in kb891593.log:

    30.891: MigrateHotfix: Migrating hotfix KB904706
    30.922: Migrating QFE KB904706 with command line: update.exe -Z -Q -B:sp2qfe
    46.500: MigrateHotfix: Hotfix KB904706 successfully migrated
    46.500: MigrateHotfixes: Return code: 3010

    I will update this post if/when we discover better information about what is causing this problem and why it is not does not reproduce 100% of the time when we try it in our lab.

    <update date="2/21/2006"> Added a note that it is safe to reinstall KB904706 after Update Rollup 2 has been successfully installed if you run into this scenario </update>

     

  • Aaron Stebner's WebLog

    Tool to automatically collect and cab VS 2008 and .NET Framework 3.5 setup log files

    • 31 Comments

    I wrote a post yesterday with a list of the names and locations of all of the log files produced during Visual Studio 2008 and .NET Framework 3.5 setup.  As you can see in that post, the list of possible log files is very long, and that makes it annoying when attempting to gather the logs and send them back to Microsoft so that we can help troubleshoot installation issues.

    Fortunately, Sandhya, a colleague of mine, has written a tool that will automatically gather all of the VS 2008 and .NET Framework 3.5 setup log files it can find from your system and create a cab file containing them so you have a single compressed package that can be sent to Microsoft for troubleshooting purposes.

    How to use the Collect tool

    The tool can be downloaded from http://go.microsoft.com/?LinkId=8967043.  It is a Win32 console application, so you can extract it from the zip file and double-click on it to run it.  It will create a file named %temp%\vslogs.cab on your system after it has gathered all of the log files.

    Note - after the tool finishes running, you can get to your %temp% folder to find the file vslogs.cab by clicking on the Start menu, choosing Run, typing %temp% and clicking OK.

    What to do if the Collect tool does not work correctly on your system

    If the tool encounters any problems, you can do the following to re-run it from a cmd prompt and see more detailed error information:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run collect.exe from the cmd prompt that appears
    3. When doing this, you will see information displayed in the cmd prompt with more details about which actions it is performing, what log files it found, etc

    <update date="5/23/2008"> Updated link to log collection tool to point to the new location </update>

     

  • Aaron Stebner's WebLog

    Repairing the Windows Installer service on a 64-bit OS

    • 33 Comments

    A customer recently contacted me due to a problem they were experiencing while trying to install the .NET Framework 2.0 on the x64 version of Windows Server 2003.  I took a look at the verbose log file for this scenario and saw the following error:

    Action start 9:16:59: CA_InstallAssembly.3643236F_FC70_11D3_A536_0090278A1BB8.
    MSI (s) (B0:F8) [09:17:03:906]: Product: Microsoft .NET Framework 2.0 (x64) -- Error 1719.The Windows Installer Service could not be accessed. This can occur if you are running Windows in safe mode, or if the Windows Installer is not correctly installed. Contact your support personnel for assistance.

    Usually when I see error 1719, I recommend that the user try to repair the Windows Installer service.  However, in this case, that didn't seem to help, and I had to refer this customer to the Microsoft technical support team for further assistance.

    Our technical support team looked at this scenario in more detail and found that there was an additional set of steps needed to repair the Windows Installer service on a 64-bit OS.

    Here is a complete set of steps that should allow you to repair the Windows Installer service on a 64-bit OS:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run %windir%\system32\msiexec.exe /unregister
    3. Run %windir%\syswow64\msiexec.exe /unregister
    4. Run %windir%\system32\msiexec.exe /regserver
    5. Run %windir%\syswow64\msiexec.exe /regserver
    6. Restart the computer

    After executing all of the above steps, you can try to re-run the failing setup and hopefully get better results.

    Note that this workaround is documented in this knowledge base article, but the extra steps that are needed on 64-bit operating systems are somewhat buried in the middle of that article and can be easy to miss.

     

  • Aaron Stebner's WebLog

    Visual Studio 2005 previous beta removal tool

    • 42 Comments

    Hey all, I'm sorry for the delay posting this.  I've got a version of the cleanup tool that I wrote that I specifically tailored to automate that long list of removal steps listed here and here.

    You can download and try out the VS 2005 beta removal tool by going to this link.

    Note that this tool isn't "officially" supported by Microsoft or me.  That being said, please let me know if you have any trouble getting this to work on your computers.  My next step is to create a version of this tool that will automate all of the manual removal steps for the .NET Framework 2.0.  Stay tuned....

    As a side note, I was hoping to have it ready when VS 2005 and .NET Framework 2.0 beta 2 went live on Sunday, but obviously that didn't happen.  I apologize to the folks who have contacted me with broken machines and wasted days cleaning them up (and also those who have gotten burned by the manual uninstall but haven't contacted me).  I know it is not really any consolation now, but we're really working hard to do what we can to fix any broken machines without forcing you to reformat and also to get any of the underlying setup bugs fixed by the time VS 2005 ships.  Thank you for your patience and interest in VS 2005 and .NET Framework 2.0.

     

  • Aaron Stebner's WebLog

    How to workaround errors installing .NET Framework 2.0 that are caused by registry permission problems

    • 17 Comments

    I have had a few customers report problems installing the .NET Framework 2.0 with the following symptoms:

    • .NET Framework 2.0 setup fails and rolls back with no specific error message, just a generic "setup failed" message at the end
    • The action that fails is "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\regtlibv12.exe" "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\mscoree.tlb" or "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\regtlibv12.exe" "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\mscorlib.tlb" (you can find the error by using the steps described here)
    • The error code listed in the log file %temp%\dd_netfx20msi*.txt is 8002801c

    Examples of this problem are the comments located here and here, and the Product Feedback Center bugs located here and here and here.

    The underlying problem is that the Administrators group somehow was only granted read permission to some of the registry keys under HKEY_CLASSES_ROOT on these machines.  When the .NET Framework setup tries to register type libraries, it needs to create some new values under HKCR and it fails because of a lack of permissions (8002801c means "error accessing the OLE registry").  I have been able to confirm that this is the problem by having one of the customers use RegMon, but I haven't been able to figure out how the permissions got modified to be this way.  Up until now I also haven't been able to figure out how to fully reset the permissions so that .NET Framework setup will work.

    Fortunately one of the customers who had this problem contacted us with a solution that worked for them, and I wanted to list it here in case others run into this same problem in the future.  Here are the steps to follow to repair permissions to workaround this issue:

    1. Download the SubInACL tool from this Microsoft site and install it.  By default it will install to c:\Program Files\Windows Resource Kits\Tools
    2. Go to the Start menu, choose Run and type cmd
    3. Type cd /d %ProgramFiles%\Windows Resource Kits\Tools to change directories to the folder that SubInACL is installed to
    4. Type notepad reset.cmd and press yes to create a new file named reset.cmd in c:\Program Files\Windows Resource Kits\Tools
    5. Copy and paste the following contents into reset.cmd and then save and close it (or download it from here and rename it from reset.cmd.txt to reset.cmd):
      subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
      subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
      subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
      subinacl /subdirectories %SystemDrive% /grant=administrators=f
      subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
      subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
      subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
      subinacl /subdirectories %SystemDrive% /grant=system=f
    6. Type reset.cmd and press enter to run the SubInACL tool (you will need to have adminstrator privileges for this to run correctly).  This tool will take several minutes to run
    7. After reset.cmd completes, try to install the .NET Framework 2.0 or VS 2005 again

    Hopefully this will help.  If you try this and still have trouble getting setup to work correctly for the .NET Framework 2.0 or VS 2005, please contact me.

     

  • 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

    Uninstalling previous betas to prepare for VS 2005 and .NET Framework 2.0 RTM

    • 64 Comments

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

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

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

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

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

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

     

  • Aaron Stebner's WebLog

    VS 2005 setup fails with 1935 or 2908 error

    • 32 Comments
    I have heard from a couple of customers who have tried to install the final release of Visual Studio 2005 or one of the Express Editions and have gotten 1935 (or 2908) errors with HRESULT values of 0x8002802F, and then setup failed and rolled back.  The cases I have seen so far have had the same root cause as the problem I described in this previous blog post.

    In the cases I have seen for this problem in the final release of VS 2005, the machines had the .NET Framework 1.1 installed, and the version of %windir%\system32\mscoree.dll was 1.1.4322.573 or 1.1.4322.2032.  When VS setup tried to install assemblies to the GAC, it failed because Windows Installer tried to call into a 2.0-specific API from mscoree.dll (needed because there are new processor architecture attributes on VS 2005 assemblies that only 2.0 knows about).  Since the version of mscoree.dll on the system was 1.1, these API calls failed.  This issue is described in more detail in my 1935 troubleshooting guide if you are interested.

    The underlying problem was that VS setup detected that the .NET Framework 2.0 was already installed and skipped that prerequisite step.  However, the machine did not actually have the .NET Framework 2.0 installed, but instead only had the registry key that VS setup uses to detect whether or not the .NET Framework 2.0 is installed.  I found that the machines had the following orphaned registry key/value that VS setup uses to determine that .NET Framework 2.0 was already installed:

    • Key name: HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727
    • Value name: MSI
    • Data type: REG_DWORD
    • Value data: 1

    Once the customers deleted this key/value and re-ran VS 2005 setup, it detected that it needed to install the .NET Framework 2.0, and after installing that, VS setup worked perfectly.

    As a side note if you're really interested, you could use some of the setup reverse engineering tricks that I describe here to determine the exact location of this registry key.  In this case, the key/value are listed in the [gencomp18] section of the file named baseline.dat in the setup subdirectory of the VS 2005 DVD or in the self-extracting setup package for the Express Editions.

     

  • Aaron Stebner's WebLog

    How to short a Media Center remote control if it stops working correctly

    • 56 Comments

    A couple of months ago, I posted a list of workarounds that have proven useful to resolve problems using the Media Center remote control and IR receiver after installing Update Rollup 2 for Media Center 2005.

    Since I posted that, I have received several comments from customers who were able to solve this issue with a different workaround not previously listed on that post.  I have found that internet searches do not do a great job of indexing blog comments, but they do well for the main body text of blog posts, so I wanted to post this suggestion as a separate blog post in the hope that others will be able to find it more easily.  I can't take any credit for finding this workaround.  It was posted as a comment on my previous blog post by a kind customer who discovered it and found it useful, and I have heard from several additional customers who indicated that it has helped them as well.

    I encourage you to try this workaround if you have already exhausted the list of suggestions located in my previous blog post and still have problems getting your Media Center remote control and/or IR receiver to work correctly.

    Symptoms

    • Media Center only receives the first button press (for example - pressing up, up, up only goes up once, but pressing down, up, down, up will work correctly)
    • The IR receiver light does not blink when pressing a button
    • Pressing buttons on the remote do not have any effect

    Workaround

    Remove the batteries from the remote control and short the battery terminals using a small metal object such as a paper clip.

    There is enough capacitance remote control circuit board to keep it alive for hours even after you remove the batteries. However, you can workaround this and drain the capacitors by shorting two of the adjacent battery terminals on the remote.   Different remotes have different configurations, so it is difficult to know \which two adjacent terminals are the ones wired to the circuit board (the other two are simply a short to connect one battery to the other).  Therefore, you should short both pair of adjacent terminals, which can be achieved by using a paper clip.  After that, re-insert the batteries and try to use the remote control again.

     

  • Aaron Stebner's WebLog

    Media Center crashes when launched after installing KB908250 and KB910393 from Windows Update

    • 36 Comments

    I mentioned yesterday that there is a new Windows Media Player hotfix (KB910393) available that will help reduce instances of digital rights management problems in Update Rollup 2 for Media Center 2005.

    We have found a problem with the way the setup package for this hotfix interacts with Update Rollup KB908250 for Update Rollup 2 that can cause Media Center to crash when you try to launch it after installing KB908250 and KB910393 from Windows Update.

    Problem description

    In this scenario (described in this newsgroup posting), after installing Update Rollup 2 for Media Center 2005 you can visit Windows Update to search for additional updates.  There will be some new critical updates available that are only offered after you install Update Rollup 2.  Included in this list of critical updates are both KB908250 and KB910393.  If you accept the default settings, Windows Update will silently install each of these hotfixes and then reboot at the end.  However, after the reboot, you will get an unhandled exception and Media Center will crash if you try to launch it.

    How to workaround the problem

    In order to repair your system and fix this crash, you can one of the following sets of steps:

    1. Download KB908250 and re-run it
    2. Reboot

    -or-

    1. Click on the Start menu, choose Run and type cmd
    2. Run the command %windir%\system32\spupdsvc.exe /install "Enables Service Pack Installer to complete its scheduled post-reboot tasks"
    3. Reboot the system

    Root cause

    The reason Media Center crashes in this scenario is that the computer is left in a state where critical Media Center services (ehRecvr and ehSched) are not registered on the system.  The setup package for KB908250 runs commands to unregister these services, and then schedules a process to re-register them after the system is rebooted.  However, there is a command in the setup package for KB910393 that un-schedules the process that KB908250 schedules.  Therefore, the command to re-register Media Center services after the reboot never happens.

    You can verify that you are running into this exact problem by checking the following:

    • Run sc query ehrecvr and verify that it reports that ehrecvr is not an installed service on your system
    • Run sc query ehsched and verify that it reports that ehsched is not an installed service on your system
    • Look for a file named %windir%\system32\spupdsvc.inf and verify that it contains a [ProcessesToRunAfterReboot] section with commands to run C:\WINDOWS\ehome\medctrro.exe /p /f C:\WINDOWS\INF\KB908250rg.inf RunOnce, C:\WINDOWS\ehome\EhMCXIns.exe /i and C:\WINDOWS\system32\spupdsvc.exe /delete

    This problem will only occur if you install KB908250, suppress the reboot at the end, and then install KB910393 afterwards.  Unfortunately, this is exactly the way that Windows Update currently installs these 2 hotfixes after Update Rollup 2 is installed.

    We are still working with the Windows Update and Windows Media Player team to identify the best way to fix this issue.  I will post an update when we decide the right course of action.  I apologize for the inconvenience that this issue is causing.

     

  • Aaron Stebner's WebLog

    .NET Framework 3.0 setup log files

    • 31 Comments

    The installer for the .NET Framework 3.0 (formerly named the WinFX runtime components) chains several different MSIs and Windows hotfixes behind the scenes.  If this setup fails, there are numerous possible causes due to the number of packages being chained behind the scenes.

    The following is a complete list of log files that can be produced during .NET Framework 3.0 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.0 setup.

    Logs produced by the .NET Framework 3.0 setup wrapper

    • dd_dotnetfx3install.txt
    • dd_dotnetfx3error.txt
    • dd_depcheckdotnetfx30.txt

    Logs produced by packages chained during .NET Framework 3.0 setup

    • RGB Rasterizer - dd_rgb_retMSI*.txt
    • MSXML 6.0 Parser - dd_msxml_retMSI*.txt
    • WIC - dd_WIC.txt
    • .NET Framework 2.0 - dd_netfx_retMSI*.txt
    • XPS - dd_XPS.txt
    • Windows Communication Foundation - dd_wcf_retMSI*.txt and dd_wcf_retCA*.txt
    • Windows Presentation Foundation - dd_wpf_retMSI*.txt
    • Windows Workflow Foundation - dd_WF_3.0_x86retMSI*.txt
    • Core .NET Framework 3.0 identity package - vsmsilog*.txt

    Logs produced by the .NET Framework 3.0 language pack setup wrapper

    • dd_dotnetfx3lperror.txt
    • dd_dotnetfx3lpinstall.txt 

    Logs produced by packages chained during .NET Framework 3.0 language pack setup

    • Individual .NET Framework 2.0 language pack MSIs - dd_netfx_retMSI_langpack*.txt
    • Individual .NET Framework 3.0 language pack MSIs - vsmsilog*.txt

    Log files will be located in the %temp% directory on the system during installation.  When setup completes successfully, the logs produced by the setup wrapper and the log file named vsmsilog*.txt are moved to a new folder located at %windir%\Microsoft.NET\Framework\v3.0\<product name>\Logs.  The <product name> will be Microsoft .NET Framework 3.0 or one of the language packs (for example - Microsoft .NET Framework 3.0 x64 Language Pack - FRA).

    If you run into any issues while installing the .NET Framework 3.0 and report 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="11/9/2006"> Added a list of log files for .NET Framework 3.0 language packs and a couple of other log files that I missed originally.  Also added locations where the logs can be found. </update>

     

  • Aaron Stebner's WebLog

    How to deploy the .NET Framework 2.0 by using the MSI directly

    • 38 Comments

    If you try to extract the contents of the .NET Framework 2.0 setup package and install it using the MSI directly, you will see a blocking dialog that looks like the following:

    .NET Framework 2.0 block dialog

    This type of blocking dialog does not appear when trying to install the .NET Framework 1.0 or 1.1 using the MSI directly.

    If you look at the .NET Framework 2.0 netfx.msi in Orca, you can see that there is a custom action that starts with the name CA_BlockDirectInstall_GUIH_SKU_URT.  Then, if you look at the InstallExecuteSequence table of the MSI, you will see that this custom action has the following condition: ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1)  ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1)  ).  As you can see from these conditions, this custom action will fire and show this block dialog unless one of those properties is passed on the command line or the product is already installed.

    As I previously described in this blog post, we created a new external UI handler for the .NET Framework 2.0.  Along with this external UI handler, we added this custom action to block the user from installing via the MSI directly as a means of more strongly encouraging people to install using the external UI handler (side note  - this is the technique described in this post on the Windows Installer team blog for using external UI handlers).

    The external UI handler for the .NET Framework 2.0 includes a command line parameter (described in this previous post) to invoke administrator mode - you can enter this mode by running install.exe /a.  This administrator mode is essentially a UI wrapper around the standard msiexec.exe /a command line parameter for creating an administrative install point (AIP) for an MSI.  It requires you to accept a EULA, then allows you to specify a location to stage the files for the administrative install point.  The interesting thing is that if you run install.exe /a and then look at the verbose MSI log file (named %temp%\dd_netfx20_a_msi*.txt), you will see that the property ADDEPLOY=1 is set while creating the AIP.  However, this property is not used at all during creation of the AIP, and it is not saved as a part of the staged MSI.  Therefore, even if you try to install the .NET Framework 2.0 using the AIP created using install.exe /a, you will still run into the block dialog shown above.

    To make a long story short, you can use the following command lines to create an administrative install point and install the .NET Framework 2.0 using the MSI directly:

    1. To extract the contents of the setup package - dotnetfx.exe /t:c:\temp /c (or you can substitute any path of your choosing for c:\temp)
    2. To create an administrative install point - c:\temp\install.exe /a
    3. To install using the MSI directly - msiexec.exe /i netfx.msi ADDEPLOY=1

    If you are interested, you can combine the steps above if you do not care about being able to extract the contents of dotnetfx.exe or create an administrative install point:

    • To combine steps 1 and 2 above to create an administrative install point without extracting dotnetfx.exe first - dotnetfx.exe /c:"install.exe /a"
    • To combine steps 1, 2 and 3 above to directly install the MSI - dotnetfx.exe /q /c:"msiexec.exe /i netfx.msi ADDEPLOY=1 /qn"

    One other item I should point out here - you will also notice when you install the MSI directly with basic UI (using the /qb switch instead of the /qn switch above), the progress dialog has a title bar and a cancel button but is otherwise blank like the following:

    .NET Framework 2.0 blank progress dialog

    The .NET Framework 2.0 MSI has been configured to be language-neutral (described in more detail here if you're interested), and there is a bug in Windows Installer that when a language-neutral MSI with no action text or error text is installed in basic UI mode, it will not display any of the standard messages in the progress dialog.  Unfortunately, this bug is present in all current versions of Windows Installer up to and including version 3.1.  I tried an installation scenario using basic UI mode on a recent Windows Vista build and verified that this bug has been fixed in Windows Installer 4.0 (which is included in Vista).

    One final thing - all of the details in this blog post apply to all .NET Framework 2.0 and VS 2005 products that use the new external UI handler we have created.  This includes the .NET Framework 2.0 SDK, the J# redistributable package, the VS Tools for Office Runtime, Document Explorer, etc.  Essentially, any setup package included as part of Visual Studio that is packaged as a self-extracting executable and contains install.exe, install.ini and install.res.####.dll will behave the same way.

    I realize this topic is a bit involved and confusing and represents a change from previous versions of the .NET Framework, so please let me know if you have any questions or run into any problems getting things to work for you.

     

  • Aaron Stebner's WebLog

    Mailbag: Do I need still need older versions of the .NET Framework on my system after installing .NET Framework 3.5 SP1?

    • 44 Comments

    Question:

    I recently installed the .NET Framework 3.5 SP1 on my system.  Afterwards, I looked in Add/Remove Programs, and it shows that I have all of the following versions of the .NET Framework installed on my system:

    • Microsoft .NET Framework 1.0
    • Microsoft .NET Framework 1.1
    • Microsoft .NET Framework 2.0 SP2
    • Microsoft .NET Framework 3.0 SP2
    • Microsoft .NET Framework 3.5 SP1

    Do I need any of these older versions of the .NET Framework now that I’ve installed the .NET Framework 3.5 SP1, or can I safely uninstall them?

    Answer:

    When you install the .NET Framework 3.5 SP1, it will also install the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 behind the scenes.  You cannot use the .NET Framework 3.5 SP1 unless you also have the .NET Framework 2.0 SP2 and 3.0 SP2 installed.  Therefore, you will not be allowed to uninstall the .NET Framework 2.0 SP2 or 3.0 SP2 if you have the .NET Framework 3.5 SP1 installed.  If you try to uninstall those versions of the .NET Framework, their uninstall processes will block and tell you that they are needed by another application on your system.

    The .NET Framework 1.0 and .NET Framework 1.1 can be installed side-by-side with the .NET Framework 2.0, 3.0 and 3.5.  Most applications that were created for the .NET Framework 1.0 or 1.1 will automatically use the .NET Framework 2.0 instead if it is installed on the system.  In most cases, that means you do not need to keep the .NET Framework 1.0 or 1.1 installed on your system if you already have the .NET Framework 2.0 installed.

    However, there are some applications that are configured to require a specific version of the .NET Framework, even if later versions of the .NET Framework are installed.  If you have any applications like that on your system and try to run them without installing the .NET Framework 1.0 or 1.1, you will get an error message that looks like the following:

    ---------------------------
    MyApplication.exe - .NET Framework Initialization Error
    ---------------------------
    To run this application, you first must install one of the following versions of the .NET Framework:
      v1.1.4322
    Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework.
    ---------------------------
    OK  
    ---------------------------

    In the above error message, the version number will be v1.0.3705 if you need to install the .NET Framework 1.0, and it will be v1.1.4322 if you need to install the .NET Framework 1.1.

    If you end up seeing any error messages like this, you can re-install the .NET Framework 1.0 or 1.1 in order to resolve the errors.  If you don't end up seeing any error messages like this, then you don't need to worry about re-installing the .NET Framework 1.0 or 1.1.

  • Aaron Stebner's WebLog

    How to silently install Visual Studio 2005 Express Editions

    • 38 Comments

    A few folks (both inside and outside of Microsoft) have contacted me asking for instructions for how to install the Visual Studio 2005 Express Editions in silent and/or unattended mode.

    Some of you have found the instructions I previously posted for Visual Studio 2005 unattended installations and tried them with the Express Editions.  However, you will find that running any of the Express Edition setup.exe files with the /createunattend or /unattendfile switches will show an error dialog stating that those switches are not supported with this setup package.

    There is not a built-in automated silent or unattended installation mode for the Express Editions, so the method for performing silent installation is a bit more involved than it is for the higher-level versions of Visual Studio 2005.  You have to download each of the setup packages that is chained as part of the Express Edition setup and then run each of them using their individual silent mode command line switches.

    To accomplish the setup package download, you need to follow the instructions to create a network install point for a VS 2005 Express Edition.

    Once you have downloaded the pieces of the Express Edition setup package, you will need to figure out which pieces are needed for the OS type (Windows XP, Windows Server 2003, etc), OS language (English, etc), processor architecture (x86, x64) and Express Edition type (VB, VWD, etc).

    The following is a list of the Express setup packages, what conditions they are needed for and their silent command line switches:

    Windows Installer 3.1

    Needed on Windows 2000 and Windows XP if not already installed

    WindowsInstaller-KB893803-v2-x86.exe /quiet /norestart

    .NET Framework 2.0 (x86)

    Needed on all x86 operating systems if not already installed

    dotnetfx.exe /q:a /c:"install.exe /q"

    .NET Framework 2.0 (x64)

    Needed on all x64 operating systems if not already installed

    NetFx64.exe /q:a /c:"install.exe /q"

    .NET Framework 2.0 language pack

    Needed for all non-English Express Editions if not already installed

    langpack.exe /q:a /c:"install.exe /q"

    J# Redistributable 2.0

    Needed only for the J# Express Edition on all operating systems if not already installed

    vjredist.exe /q:a /c:"install.exe /q"

    J# Redistributable 2.0 language pack

    Needed for non-English J# Express Edition if not already installed

    vjredist-LP.exe /q:a /c:"install.exe /q"

    Lite Debugger Package (x64)

    Needed on all x64 operating systems if not already installed

    expdbgsetup.exe /q:a /c:"install.exe /q"

    Main Express Edition package

    Needed on all operating systems.  The exact command line depends on which Express Edition you want to install.

    MSDN Express

    Optional on all operating systems if not already installed

    msdnixp.exe /q:a /c:"Install.exe /q"

    SQL Express (x86)

    Optional on all x86 operating systems if not already installed

    SQLEXPR32.EXE -q /norebootchk /qn reboot=ReallySuppress addlocal=all instancename=SQLEXPRESS SCCCHECKLEVEL=IncompatibleComponents:1;MDAC25Version:0 ERRORREPORTING=2 SQLAUTOSTART=1

    SQL Express (x64)

    Optional on all x64 operating systems if not already installed

    SQLEXPR.EXE -q /norebootchk /qn reboot=ReallySuppress addlocal=all instancename=SQLEXPRESS SCCCHECKLEVEL=IncompatibleComponents:1;MDAC25Version:0 ERRORREPORTING=2 SQLAUTOSTART=1

    Additional notes about silent install of the Express Editions:

    • The packages should be chained in the order listed above because this is the order that Express setup will run them if you launch setup in full UI mode
    • All of the command lines listed above can be figured out by downloading the Express web download bootstrapper (for example, this package for Visual WebDev Express 2005), extracting the contents of the package, and reading through the file baseline.dat.  The combination of the Executable value data and the CommandLine value data for each component forms the command line that you want to use for silent installation.
    • If you look at baseline.dat for the Express Editions to form the command lines, you will notice that I removed the /watsongenman switches in the command lines that I listed above.  The /watsongenman switch is used to generate a log file that is sent as part of a Watson report for the Express Edition setup package when it is installed via full UI mode.  That switch is not needed when individually installing the components as I describe above.
    • To change from a silent installation to an unattended installation, change all instances of install.exe /q to install.exe /qb and change /qn to /qb for the main Express Edition and SQL Express command lines

    <update date="4/11/2006"> Updated command lines for Main Express Edition packages - I missed the REBOOT=ReallySuppress and /qn switches from a few of the editions </update>

     

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