Aaron Stebner's WebLog

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

May, 2006

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

    How to perform a command line installation of SQL Server 2005

    • 6 Comments

    I was asked by a customer a while back about available options for performing silent installation of SQL Server 2005 Express Edition.  I haven't had a lot of time to research this issue, and the only steps I knew were the ones used by Visual Studio setup to install SQL Express.

    Now that I looked into this scenario a bit more, I found an MSDN document entitled How to: Install SQL Server 2005 from the Command Prompt that provides in-depth instructions regarding supported command line switches for SQL 2005 setup and steps for creating an automated installation answer file.

    The instructions in this document will allow you to perform all of the following configuration tasks, plus several more that I didn't list:

    • Install a standalone SQL instance
    • Install a clustered SQL instance
    • Rebuilding SQL databases
    • Add/remove individual components
    • Add/remove nodes in a cluster
    • Uninstall a standalone SQL instance
    • Uninstall a clustered SQL instance

    Please note that these instructions are generic and apply to all versions of SQL Server 2005.  Some of the advanced configuration options are not supported by SQL Server 2005 Express Edition, so you will need to make sure to only attempt to install the Express Edition using switches and options that it supports.

     

  • Aaron Stebner's WebLog

    Workaround to allow pre-installing the .NET Framework 2.0 during the T13 phase of OS setup using svcpack.inf

    • 8 Comments

    I previously wrote about a scenario where installing the .NET Framework 2.0 fails when launching it from svcpack.inf during the T13 phase of OS setup.  When I originally wrote that post, the only workarounds that I had to offer were to install the .NET Framework 2.0 during the GuiRunOnce phase at the end of OS setup or by using a RunOnce/RunOnceEx registry value to launch .NET Framework 2.0 setup during the first boot of the OS.

    A couple of weeks ago, a customer posted a workaround that they found that allows .NET Framework 2.0 installation to succeed when using svcpack.inf during OS setup.  I have spent some time since then investigating further to make sure I understood this workaround and the root cause better before posting more about it.  Now I want to explain the workaround and root cause in more detail for folks who want to be able to install the .NET Framework 2.0 in this way.

    In order to allow the .NET Framework 2.0 to successfully install during the T13 phase of OS setup, you can include the following commands in svcpack.inf:

    [SetupHotfixesToRun]
    reg delete HKLM\Software\Microsoft\PCHealth\ErrorReporting\DW /f
    reg add HKLM\SYSTEM\Setup /v SystemSetupInProgress /t REG_DWORD /d 0 /f
    dotnetfx.exe /Q /C:"install.exe /Q"
    reg add HKLM\SYSTEM\Setup /v SystemSetupInProgress /t REG_DWORD /d 1 /f

    Deleting the DW registry key is necessary because .NET Framework 2.0 setup tries to write a value under this registry key and does not have the required permissions to write that value during OS setup.

    Setting the SystemSetupInProgress value to 0 is necessary because when that value is set to 1 (which it is by default during OS installation), the action that installs assemblies to the GAC during .NET Framework 2.0 setup will fail with the following error:

    Error 25007.Error occurred while initializing fusion. Setup could not load fusion with LoadLibraryShim(). Error: The handle is invalid.

    I am not sure if setting the SystemSetupInProgress value back to 1 is strictly necessary, but it is safest to do this as well because that value signals to OS and application setup processes that OS setup is in progress.

    When I looked in more detail into why .NET Framework 2.0 setup failed with error code 25007 when SystemSetupInProgress = 1, I found that I was able to produce an error with a simple test application to call LoadLibrary and then trying to call LoadLibrary for the file fusion.dll.  Trying to do this gave me the following error:

    LoadLibrary failed for 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\fusion.dll' with error code 14001 - This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

    This was the root cause of the 25007 error because one of the first things that .NET Framework setup attempts to do when installing assemblies to the GAC is to call LoadLibrary on fusion.dll.

    I could not figure out why LoadLibrary was failing for fusion.dll (because LoadLibrary succeeded when I tried to load other DLLs in system32 on the same machine in the same circumstances).  Eventually, I received the answer from Junfeng Zhang.  The core issue resides in fusion side-by-side loading logic.  An underlying design decision was made in some of the code in sxs.dll that causes side-by-side publisher policy to not be applied when the SystemSetupInProgress registry value is set to 1.  The intention behind this decision is that OS setup should only use a pre-defined set of binaries, and should not be able to use arbitrary 3rd party binaries.  The Visual C++ runtime files that ship with the .NET Framework 2.0 and Visual Studio 2005 (the VC80 versions) are installed to the side-by-side store (%windir%\WinSxS), and fusion.dll is built using these VC80 runtime files.  Attempting to call LoadLibrary on fusion.dll when SystemSetupInProgress = 1 fails because fusion.dll cannot find the VC80 runtime files in the side-by-side store that it needs to load correctly.

    This underlying issue exists for all side-by-side assemblies that any process on the system attempts to load when SystemSetupInProgress = 1.  Junfeng's team is currently evaluating whether or not to change this design.  The fix would have to be made in the file sxs.dll, which is an OS file.  As a result, the fix would have to be delivered via a future service pack for Windows XP and Windows Server 2003.

    In the meantime, however, the workaround described at the beginning of this blog post should work fine if you need to install the .NET Framework 2.0 during the T13 phase of OS setup using svcpack.inf.

     

  • Aaron Stebner's WebLog

    Workaround for possible timing issue that can cause .NET Framework setup failures

    • 4 Comments

    I got an email from the .NET Framework setup technical support team today with some more information about a possible workaround for setup failures that occur while trying to register System.EnterpriseServices.dll or run RegSvcs.exe /bootstrapi.

    I have previously posted instructions to use the MsiBreak environment variable to gather debugging information if the .NET Framework setup fails due to this error.  The technical support team has found a few cases where setting a break point on this custom action, then waiting for a minute or so and then pressing OK to continue .NET Framework setup will allow it to succeed.

    If you would like to try this workaround, you can use the following steps:

    1. Right-click My Computer, and then click Properties
    2. On the Advanced tab, click Environment Variables, and then under System Variables, click New
      Note: You must add MsiBreak to the list of System Variables (and not to the list of User Variables)
    3. In the Variable Name field, enter "MsiBreak" (without the quotation marks).
    4. In the Variable Value field, enter the name of custom action you want to break on.  The name must match the name listed in the Action column of the CustomAction table of the MSI:
      For .NET Framework 1.0 or 1.1 setup: CA_ComregEnterpriseServices.3643236F_FC70_11D3_A536_0090278A1BB8
      For .NET Framework 2.0 setup: DD_CA_ComregEnterpriseServices_X86.3643236F_FC70_11D3_A536_0090278A1BB8
    5. Run .NET Framework setup and start installing
    6. During installation, a break message will appear stating "To debug your custom action, attach your debugger to process XXX (0xZZZ) and press OK".
    7. Wait for a minute or so with this dialog on the screen
    8. Press OK to allow setup to continue and hopefully succeed

    Note that I have written about other possible causes of this type of installation failure in the following blog posts.  If the above workaround does not succeed, these additional articles may be helpful in resolving this issue on your system:

     

  • Aaron Stebner's WebLog

    How to perform an unattended install of Visual Studio 2005 from a DVD-ROM drive

    • 15 Comments

    I recently heard from a customer who was trying to deploy Visual Studio 2005 using an unattended INI file and saw setup fail, but only when launching setup directly from the DVD.  If they shared the DVD-ROM drive and installed from it using a UNC path or a mapped drive letter, it worked fine.

    I took a look at the setup source code and found that due to a really old bug back in the Visual Studio .NET 2002 timeframe, we disabled launching unattended installation directly from removable media.  However, there have been some changes in setup since then that make it possible for an unattended installation to succeed in this scenario.  Namely, we started shipping Visual Studio on a single DVD instead of multiple CDs, so no disk swaps are necessary.

    In order to perform an unattended installation of Visual Studio from a DVD-ROM install location, you will have to take advantage of an undocumented command line switch that exists in setup.exe.  Here are the steps that will allow you to do this:

    1. Locate a test computer that has the same operating system that you want to deploy Visual Studio to in your network, and make sure that it does not already have Visual Studio 2005 installed
    2. Install .NET Framework 2.0 on your test computer (because this is required for creating an unattend file for Visual Studio in the next step)
    3. Launch Visual Studio 2005 in unattended INI creation mode by running <Visual Studio source location>\setup\setup.exe /createunattend <path to INI file to create>
    4. Step through the Visual Studio 2005 setup UI and create an unattended uninstall INI file
    5. Launch Visual Studio 2005 setup in unattended uninstall mode by running <Visual Studio source location>\setup\setup.exe /unattendfile <path to INI file created step 2 above> /PromptForCD

    The /PromptForCD switch in step 5 will cause setup to skip the check to see if setup is running from a DVD-ROM drive.  If you are attempting to perform an unattended install from CD instead of DVD, this switch will also cause a dialog to appear when you need to swap discs, which will make installation not be silent anymore.  However, there is no way to perform a fully silent installation from CD anyways because you have to know to swap the discs in the middle of setup.  This switch will not have any effect for a DVD install because no disc swaps are required for that scenario.

     

  • Aaron Stebner's WebLog

    How to create an installable layout for the WinFX Runtime Components

    • 0 Comments

    I have previously posted instructions that can be used to download the individual pieces of the Visual Studio 2005 Express Editions and create a network install point so that you do not need to use the download functionality in the Express Edition setup.exe each time you want to install on a new system.

    The WinFX Runtime Components uses the same logic as the Express Editions to manage downloads prior to installation.  I have heard from a few customers who received errors from this setup.exe package while trying to download pieces of the WinFX Runtime Components, which prevented them from installing.  Therefore, I decided to post instructions for downloading the individual pieces of the WinFX Runtime Components so that you can stage the installer on a network and remove the automatic download feature from the equation when trying to install it.

    The following steps will allow you to manually assemble an installable layout for the WinFX Runtime Components.  In this example, I will use the latest currently available version (beta 2), but once the final version of the WinFX Runtime Components ships, the steps will be nearly the same.

    1. Download the web download bootstrapper for the WinFX Runtime Components and save it to your local hard drive
    2. Create a new folder named c:\winfx (or one of your own choosing)
    3. Extract the contents of the web download bootstrapper to the folder c:\winfx by running winfxsetup.exe /x:c:\winfx
    4. Make a new folder named c:\winfx\wcu
    5. Go to c:\winfx and open the file baseline.dat in a text editor such as Notepad
    6. For each of the components listed below, follow the set of additional steps listed below to download them and place them in the correct location.

    Note: If you know ahead of time that one or more of the components will already be installed on your target operating system, you can skip the step listed below to download and stage the component(s) that you already have installed.

    Windows Installer 3.0

    1. Make a new folder named c:\winfx\wcu\msi30
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp90] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=38552
    3. Navigate to the URL that you created in step 2 and choose to save the file WindowsInstaller-KB884016-v2-x86.exe to the folder c:\winfx\wcu\msi30

    RGB Rast (x86)

    1. Make a new folder named c:\winfx\wcu\rgbrast
    2. Make a new folder named c:\winfx\wcu\rgbrast\x86
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp136] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=56151
    4. Navigate to the URL that you created in step 2 and choose to save the file RGB9RAST_x86.msi to the folder c:\winfx\wcu\rgbrast\x86

    RGB Rast (x64)

    1. Make a new folder named c:\winfx\wcu\rgbrast
    2. Make a new folder named c:\winfx\wcu\rgbrast\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp137] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=56158
    4. Navigate to the URL that you created in step 2 and choose to save the file RGB9RAST_x64.msi to the folder c:\winfx\wcu\rgbrast\x64

    MSXML 6.0 Parser (x86)

    1. Make a new folder named c:\winfx\wcu\msxml
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp70] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=49593
    3. Navigate to the URL that you created in step 2 and choose to save the file msxml6.msi to the folder c:\winfx\wcu\msxml

    MSXML 6.0 Parser (x64)

    1. Make a new folder named c:\winfx\wcu\msxml
    2. Make a new folder named c:\winfx\wcu\msxml\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp104] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=49601
    4. Navigate to the URL that you created in step 2 and choose to save the file msxml6.msi to the folder c:\winfx\wcu\msxml\x64

    WIC Installer (x86)

    1. Make a new folder named c:\winfx\wcu\wic
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp209] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=62438
    3. Navigate to the URL that you created in step 2 and choose to save the file WIC_X86_ENU.exe to the folder c:\winfx\wcu\wic

    WIC Installer (x64)

    1. Make a new folder named c:\winfx\wcu\wic
    2. Make a new folder named c:\winfx\wcu\wic\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp210] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=62439
    4. Navigate to the URL that you created in step 2 and choose to save the file WIC_X64_ENU.exe to the folder c:\winfx\wcu\wic\x64

    .NET Framework 2.0 (x86)

    1. Make a new folder named c:\winfx\wcu\dotnetframework
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp18] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=51424
    3. Navigate to the URL that you created in step 2 and choose to save the file dotnetfx.exe to the folder c:\winfx\wcu\dotnetframework

    .NET Framework 2.0 (x64)

    1. Make a new folder named c:\winfx\wcu\dotnetframework
    2. Make a new folder named c:\winfx\wcu\dotnetframework\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp27] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=51431
    4. Navigate to the URL that you created in step 2 and choose to save the file netfx64.exe to the folder c:\winfx\wcu\dotnetframework\x64

    Windows Communication Foundation (x86)

    1. Make a new folder named c:\winfx\wcu\wcf
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp98] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65594
    3. Navigate to the URL that you created in step 2 and choose to save the file wcf.exe to the folder c:\winfx\wcu\wcf

    Windows Communication Foundation (ia64)

    1. Make a new folder named c:\winfx\wcu\wcf
    2. Make a new folder named c:\winfx\wcu\wcf\ia64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp99] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65596
    4. Navigate to the URL that you created in step 2 and choose to save the file wcf_x64.exe to the folder c:\winfx\wcu\wcf\ia64

    Windows Communication Foundation (x64)

    1. Make a new folder named c:\winfx\wcu\wcf
    2. Make a new folder named c:\winfx\wcu\wcf\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp100] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65595
    4. Navigate to the URL that you created in step 2 and choose to save the file wcf_x64.exe to the folder c:\winfx\wcu\wcf\x64

    Windows Presentation Foundation (x86)

    1. Make a new folder named c:\winfx\wcu\wpf
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp101] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65592
    3. Navigate to the URL that you created in step 2 and choose to save the file wpf.msi to the folder c:\winfx\wcu\wpf

    Windows Presentation Foundation (x64)

    1. Make a new folder named c:\winfx\wcu\wpf
    2. Make a new folder named c:\winfx\wcu\wpf\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp103] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65593
    4. Navigate to the URL that you created in step 2 and choose to save the file wpf_x64.msi to the folder c:\winfx\wcu\wpf\x64

    Windows Workflow Foundation (x86)

    1. Make a new folder named c:\winfx\wcu\winws
    2. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp109] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65601
    3. Navigate to the URL that you created in step 2 and choose to save the file WF_3.0_x86.msi to the folder c:\winfx\wcu\winws

    Windows Workflow Foundation (ia64)

    1. Make a new folder named c:\winfx\wcu\winws
    2. Make a new folder named c:\winfx\wcu\winws\ia64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp110] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65602
    4. Navigate to the URL that you created in step 2 and choose to save the file WF_3.0_ia64.msi to the folder c:\winfx\wcu\winws\ia64

    Windows Workflow Foundation (x64)

    1. Make a new folder named c:\winfx\wcu\winws
    2. Make a new folder named c:\winfx\wcu\winws\x64
    3. Open a web browser and build a URL by typing http://go.microsoft.com/ and appending the data stored in the URL value in the [gencomp111] section of baseline.dat.  In this example, the desired URL is http://go.microsoft.com/fwlink/?LinkId=65600
    4. Navigate to the URL that you created in step 2 and choose to save the file WF_3.0_x64.msi to the folder c:\winfx\wcu\winws\x64

    Note: In addition to the above components, the WinFX Runtime Components contains a set of language packs that its setup will attempt to install on non-English operating systems.  However, there are a lot of them, and I am going to omit them from this blog post for the sake of brevity.

    If you are planning to install the WinFX Runtime Components on a non-English OS, you will need to follow steps similar to what I have listed above to download and stage the appropriate language pack.  You can find the [gencomp] section and URL that you will need by searching through the contents of baseline.dat and finding the appropriate language.  If you have any trouble figuring out how to do this, please contact me and I will attempt to help out.

     

  • Aaron Stebner's WebLog

    What to do if you receive unsupported OS message when installing Windows Media Player 11 Beta on Windows Media Center 2005

    • 4 Comments

    As many of you have noticed, a beta version of Windows Media Player 11 was released this week.  The WMP 11 beta only allows installation on Update Rollup 2 for Windows XP Media Center Edition 2005 but not on any previous versions of Windows XP Media Center Edition.  I have heard of a few instances where users have tried to install this WMP 11 beta on Windows XP Media Center Edition and received an error message stating that their current OS is not supported.

    Unfortunately, there are some cases where 3rd party applications can change the registry value that indicates what version of Media Center is on the system, and that can cause Windows Media Player 11 setup to block installation when it shouldn't.

    If you receive an unsupported OS message when installing the Windows Media Player 11 beta and you believe that you have Update Rollup 2 for Windows XP Media Center Edition 2005 installed, you can verify whether or not you have Update Rollup 2 installed using one of these alternate methods (listed in order of preference):

    • Go to Add/Remove Programs, check the box labeled Show updates, scroll to the bottom, and verify that Update Rollup 2 for Windows XP Media Center Edition 2005 is listed
    • Launch Media Center, go to Settings | General | About Media Center | Software Version and verify that the version number is greater than or equal to 5.1.2715.2732 and that Update Rollup 2 is listed there
    • Go to %windir%\ehome and verify that the version number of ehshell.exe is greater than or equal to 5.1.2715.2732

    Once you have verified that Update Rollup 2 truly is installed on your system, you can modify the registry key that WMP 11 setup uses to the detect Windows Media Center version by using the following steps:

    • Click on the Start menu, choose Run and type cmd
    • Type reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Media Center" /v Ident /t REG_SZ /d 4.0 /f
    • Re-run WMP 11 setup

    If you're interested, here is the exact logic that WMP 11 beta setup uses to determine whether or not the version of Windows Media Center is supported is the following:

    1. Check the Ident value located in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center
    2. If Ident = 4.0, then allow installation
    3. If Ident = 3.0 or Ident = 3.1, then notify the user that they must install Update Rollup 2 for Windows XP Media Center Edition 2005
    4. If Ident < 3.0, then notify the user that they must be running Windows XP Media Center 2005 or later

     

  • Aaron Stebner's WebLog

    How to fix Visual Studio 2005 beta expiration dialog

    • 0 Comments

    As some of you may have noticed, the beta versions of Visual Studio 2005 expired on May 1, 2006.  When you attempt to launch any beta version of the VS 2005 IDE and your system clock is set to May 1, 2006 or later, you will receive a message box with the following message:

    The Beta period is over.
    Thank you for your participation.
     
    You can now remove Microsoft Visual Studio from your computer.

    If you receive this error message when you launch Visual Studio 2005 on your system, you should uninstall the beta version using the exact order specified in the uninstall instructions or use the automated beta uninstall tool.  After fully removing the beta version of Visual Studio 2005, you can proceed to install the final release and the IDE should work correctly and not display any beta expiration errors like the one listed above.

    I have heard from a couple of people who reported seeing this message in the final release of Visual Studio 2005.  This exact error string was located in one of the VS IDE resource DLLs, and the string was completely removed before the final release.  Also, this resource DLL is a versioned file, so even if it is left behind by the beta uninstall process, it will be replaced when you install the final release of Visual Studio 2005.  Therefore, the only possible way that you can receive this error message is if you still have the beta installed.  If you are receiving this error message and you believe you have the final release installed, please double-check the uninstall instructions and make sure you followed them fully prior to installing the final release.

     

  • Aaron Stebner's WebLog

    WMIDiag - a tool for diagnosing and repairing problems with the WMI service

    • 0 Comments

    Earlier this week, I was looking into an issue reported to me via my blog, and I found a case where problems with the WMI service were causing SQL Server 2005 setup to fail.  When trying to find out more information about this error, I received a set of links for a tool that can be used to diagnose and solve problems with the WMI service on a system.  I wanted to post the links here to try to make it easier for people who have WMI-related issues to find them in the future:

     

  • Aaron Stebner's WebLog

    How to perform an unattended uninstall of Visual Studio 2005

    • 2 Comments

    I have previously posted several items about how to manage deployment of Visual Studio 2005, but a question was sent to me today that I haven't addressed yet - how to perform an unattended uninstall of Visual Studio 2005.

    It is possible to perform an unattended uninstall of Visual Studio 2005 by creating an INI file and running setup with the INI file as a parameter using the following steps:

    1. Install the same edition and language of Visual Studio 2005 on the same OS that you want to perform an unattended uninstall on
    2. Launch Visual Studio 2005 in unattended INI creation mode by running <Visual Studio source location>\setup\setup.exe /createunattend <path to INI file to create>
    3. Click the Uninstall Visual Studio link to create an unattended uninstall INI file
    4. Launch Visual Studio 2005 setup in unattended uninstall mode by running <Visual Studio source location>\setup\setup.exe /unattendfile <path to INI file created step 2 above>

    There are a couple caveats to keep in mind when trying to perform an unattended uninstall of Visual Studio 2005:

    • You have to create the unattended INI file on a machine that has the exact version and language of Visual Studio installed that you want to remove
    • The unattended uninstall will only remove the main Visual Studio product; it will not remove any prerequisites or optional components (the .NET Framework, Document Explorer 2005, SQL Express, etc); you will need to run these setup packages with the relevant silent switches to perform silent uninstalls if necessary

     

  • Aaron Stebner's WebLog

    How WinFX Runtime setup blocks uninstall of the .NET Framework 2.0

    • 10 Comments

    A little while back, I was looking into an odd scenario reported by a fellow Microsoft employee where they tried to install the final release of Visual Studio 2005, but it reported that the beta version of the .NET Framework 2.0 needed to be uninstalled first.  When they tried to uninstall the .NET Framework 2.0 beta, the uninstall was blocked and displayed a dialog that looked like this:

    .NET Framework 2.0 uninstall block dialog

    Based on my previous knowledge working on setup for the .NET Framework 1.0 and 1.1, I knew this error would occur if the following registry value was set on the system:

    • Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \.NETFramework\v2.0.50727\SBSDisabled
    • Value name: Uninstall
    • Data type: REG_DWORD
    • Value data: 1

    However, at the time that I investigated this issue, I had never seen that registry value being set on a system outside of some of the test cases I used to run when I tested .NET Framework setup.  I dug into this issue further and found out that WinFX Runtime setup creates this value in order to prevent users from accidentally uninstalling the .NET Framework 2.0 out from under the rest of the WinFX runtime (because the WinFX runtime will not function properly without the .NET Framework 2.0 installed).

    The interesting thing to me about this "feature" of WinFX runtime setup is that it uses logic that we built into .NET Framework setup back in the late stages of the .NET Framework 1.0 in a way that we never really intended or envisioned that it would be used back when we added it. 

    The .NET Framework has always been designed to support side-by-side installation, usage, and uninstallation.  Towards the end of the .NET Framework 1.0 ship cycle, we started worrying that we may be missing some order-of-installation bugs that could cause install and uninstall of one version of the .NET Framework to break when in the presence of future versions.  This type of scenario was very hard to test for back in the .NET Framework 1.0 timeframe because we did not have any other versions to use for side-by-side testing.  As a result of these fears, we added what we called "hooks" and "blocks" to the .NET Framework 1.0 setup.

    The "hooks" are a set of custom actions that run at the end installation and uninstallation and attempt to run an executable named netfxsbs10.exe.  We did not ship a file with that name in the .NET Framework 1.0, but these custom actions provide us the option to ship a file with that name in future versions in case we find install/uninstall problems that we could not address purely with changes in setup for the later version.  We did end up finding this type of issue later on for .NET Framework 1.0 setup, and if you install the .NET Framework 1.1 or 2.0, you will notice that it installs the file %windir%\Microsoft.NET\Framework\netfxsbs10.exe.  That EXE will run if you install or uninstall the .NET Framework 1.0 after installing 1.1 or 2.0, and it will replace some registry data that will otherwise be deleted or incorrectly updated by 1.0 setup.

    The "blocks" are a set of custom actions that run at the beginning of installation and uninstallation.  They search for specific registry values and block the install or uninstall if the registry value exists on the system.  There are separate registry values so that we could independently block install and/or uninstall if we found it necessary to do so in the future.  These custom actions were intended at the time to be a last resort so that if we (for example) found an issue with .NET Framework 1.0 setup that was so bad that even the "hook" custom actions could not fix it, we could install these registry values in setup for later versions of the .NET Framework and prevent .NET 1.0 from being installed or uninstalled if the later version was already installed on the system.

    We ended up carrying the hooks and blocks forward in setup for the .NET Framework 1.1 and 2.0, partially to retain this type of safety net, and partially because we figured out pretty early in the .NET Framework 1.1 product cycle that we needed to use the hooks that we built into .NET 1.0 setup and that humbled and scared us even more.

    It appears that the WinFX setup team ended up finding out about these hooks and blocks and repurposed the blocks to prevent uninstall of the .NET Framework 2.0.  It is a bit strange that we do not take measures like this to prevent users from uninstalling the .NET Framework out from under Visual Studio (because similar to WinFX, Visual Studio will not function properly without the matching build of the .NET Framework on the system).  The main difference I can see between the WinFX Runtime scenario and the Visual Studio scenario is that WinFX is a runtime product as opposed to a developer tool, and therefore it is much more likely to be on non-developer systems.  This makes it more appealing to add an extra safeguard against unintentional damage to this product.

    All in all, I thought that this investigation was an interesting example of unintended consequences of an initial design.  Although it seems to behave fine in the WinFX scenario that it is being used for, and it has encouraged me to be more conscious of documenting features like this so that they are not misused by future products.

     

  • Aaron Stebner's WebLog

    How to resolve possible errors installing SQL Server 2005 SP1 related to the Setup Support Files

    • 2 Comments

    I heard from a customer recently who had an issue installing SQL Server 2005 SP1 (here for Express Edition or here for non-Express Editions) on a system that had multiple editions of SQL 2005 installed.  They indicated that they were encountering the same issue as the one described in this bug report on the product feedback site.

    The good news is that the bug report provided a workaround that solved this customer's issue, but the bad news is that the workaround steps listed in the bug report proved to be confusing, and they were only able to resolve the issue after I clarified the steps.  As a result, I'm going to try to summarize the workaround in the bug report in more specific detail so that if anyone else runs into this issue, you'll hopefully be able to figure out how to resolve it on your system as well.

    Here are the steps that you should be able to use to resolve SQL Server 2005 SP1 setup issues related to the Setup Support Files:

    1. Click on the Start menu, choose Run and type regedit
    2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\Bootstrap\MSIRefCount
    3. Rename the Uninstall value to Uninstall2
    4. Click on the Start menu, choose Run and type appwiz.cpl
    5. Uninstall the product named Microsoft SQL Server Setup Support Files
    6. Locate and install the MSI named SqlSupport.msi from the original installation media for SQL Server 2005
    7. Click on the Start menu, choose Run and type regedit
    8. Rename the Uninstall2 value back to Uninstall
    9. Try again to install SQL 2005 Service Pack 1

    Hopefully this will make the steps listed in the bug report more clear in case anyone else runs into this SQL 2005 SP1 setup issue.....

     

  • Aaron Stebner's WebLog

    Good reference document for debugging assembly loading errors

    • 1 Comments

    I ran across a blog post from Suzanne Cook this past weekend that has been around for a while, but that has some excellent information about techniques for debugging assembly loading errors.  I'm not sure how I managed to miss such a useful and informative post for so long (it was originally written in May 2003 - 3 years ago!)

    One particularly interesting strategy that she describes is how to use the Assembly Binding Log Viewer (fuslogvw.exe) to pinpoint exact failures.  I have used fuslogvw.exe several times in order to narrow down specific assembly load failures in Visual Studio 2005, and this tool helped me find several of the workarounds that I listed in my assembly load failure troubleshooting instructions.

    If you're interested in learning some advanced techniques for debugging and troubleshooting .NET Framework assembly loading errors, I encourage you to check out this blog post.

     

  • Aaron Stebner's WebLog

    My file server is temporarily down for maintenance

    • 2 Comments

    I'm posting this here in the hopes that everyone who has read one of my blog posts and tried to download one of the tools that I have posted on my SharePoint site will see this.  Currently, the server I use to host all of the tools that I have posted for download is down for maintenance, and it unfortunately has been down for a couple of days now.  I'm trying to find out an exact ETA for when it will be back up and running, but haven't had any luck yet.  If anyone runs into trouble trying to download one of the tools located at http://astebner.sts.winisp.net/Tools/Forms/AllItems.aspx that I list in any of my blog posts, please contact me and I will send you a copy of the tool via email as a workaround.  I apologize for the inconvenience, and I'll post an "all clear" message when the site is back up and running.

     

  • Aaron Stebner's WebLog

    Beta version of Windows Vista Upgrade Advisor now available

    • 2 Comments

    There is now a beta version of the Windows Vista Upgrade Advisor available for download.  This tool can be installed and run on a Windows XP computer to assess how well the computer will run Windows Vista.  There are several categories of Windows Vista functionality that it will evaluate, and you can pick and choose the ones that are important to you.

    One of those functional categories is Watch and Record TV, so you can use this tool to evaluate how well Windows Media Center PVR functionality will work on a system if you decide to upgrade it to Windows Vista.  The Upgrade Advisor also has a link to more details about Windows Media Center features in Windows Vista so you can learn more about some of the specific features in Windows Media Center in the upcoming version.

     

  • Aaron Stebner's WebLog

    Updated version of DUAScriptGen (v1.1.0010) is now available

    • 1 Comments

    I have released an updated version of DUAScriptGen tonight that contains a couple of bug fixes, one that is relatively small and one that is bigger.  I decided to increase the version number by more than 1 to indicate that the change is more substantial than in the last couple of minor releases, so that is why this is v1.1.0010 when the previous version was v1.1.0004.  You can download the latest version of DUAScriptGen from this location.

    The big change in this version is in regards to how DUAScriptGen generates the file copy operations in the DUS file.  Previously, it had some logic to try to handle files in use on the device by setting the flags DAMOVEFILE_REPLACE_EXISTING and DAMOVEFILE_DELAY_UNTIL_REBOOT in the MOVEFILE operations.  However, a customer pointed out to me that this is not a reliable way to cause DUA to delay file renaming until after the reboot because of some permission issues if the DUAgent service is running with certain credentials on the device.

    The v1.1.0010 version of DUAScriptGen now uses the recommendations in this Windows XP Embedded MSDN document and creates a set of steps to rename the current file, copy the new file, reboot and delete the renamed file to accomplish copy operations in case files are in use.  There is one problem though - there is no way to know for sure when creating the DUS file whether or not the file will be in use on the embedded device when the update is applied.  Because of that, I added a checkbox in the file properties dialog that appears when you double-click on a file in the DUAScriptGen file list box.  This checkbox lets you specify whether or not the file is expected to be in use on the device.  If that checkbox is set, DUAScriptGen will use the 4 step process in the MSDN article above to copy the file to the system and if not it will use a single step.  Files in use can only affect copy and delete operations, so the checkbox will be grayed out in the DUAScriptGen UI if one of the other file operations (move or execute) are selected for the file.  When adding new files in DUAScriptGen, the files in use checkbox will default to off, but you can change that setting prior to generating your DUS file if desired.

    The above change was made in such a way that previously generated DUS files can still be loaded correctly in the DUAScriptGen UI.  If you want to quickly update to this new file copy logic for a DUS file that you previously created in DUAScriptGen, all you have to do is get the new version of DUAScriptGen, load the DUS file, check the files in use checkbox for the relevant files, and recreate the DUS file.

    The small bug fix I mentioned above is a logic change when you have local polling selected in the DUAScriptGen options dialog.  Previously, DUAScriptGen only wrote the name of the next file to poll for to the registry entry in the DUS file, but now it will correctly write the full path of the next file to poll for.  Thanks to Lynda for pointing out this problem to me!

    As always, please let me know if you see any additional issues with DUAScriptGen.

     

  • Aaron Stebner's WebLog

    Windows Media Center SDK build 5381.1 now available

    • 1 Comments

    There is a new build of the Windows Media Center SDK available on the Microsoft Connect site for folks in the Windows Vista beta program.  This build is compatible with Windows Vista 5381.1 build, which was released at the end of last week.  You can find some details about this new SDK build, which now includes WinFX Media Center application project templates and a Click-to-record file generation tool along with lots of documentation enhancements, in this post on the Media Center Sandbox site.

    As always, I encourage you to post feedback (positive and negative) about this build of the SDK on the Connect site and/or on the Media Center Sandbox developer forum.

     

  • Aaron Stebner's WebLog

    Information about patching improvements for future Visual Studio and .NET Framework hotfixes

    • 0 Comments

    I found a couple of articles that Heath Stewart wrote a few months ago that I somehow missed at the time that he posted them.  His team has been developing a new wrapper setup.exe that will be used for all future Visual Studio and .NET Framework hotfixes and service packs.

    I have helped several people who ran into issues with installing hotfixes, particularly for the .NET Framework, and I anticipate that the new patch wrapper will eliminate a lot of the issues I've seen in the past, and it will also make it easier to debug failures in case they still happen.  One of the key changes in the new wrapper is that it is written in native code as opposed to managed code.  I have always felt that it is inherently fragile to attempt to install or patch managed code using a setup wrapper that is itself attempting to run using managed code.  If anything is broken with the .NET Framework itself, you basically see the hotfix setup crash and show a stack trace (as opposed to displaying an actionable error message).  This new wrapper should eliminate that nasty error case (though not necessarily the underlying problem that caused the crash to begin with).

    If you're interested in more details about the new patch setup wrapper for Visual Studio and the .NET Framework, check out these posts:

    • Patch wrapper improvements introductory article - this article includes command line switches that can be used for installing hotfixes and service packs that use this new wrapper
    • How logging works in the new patch wrapper - logging will be enabled by default now, which means you do not have to enable verbose logging and reproduce the failure in order to gather setup log files to help debug failures (which is especially painful if you are downloading and installing the patch via Windows Update or Microsoft Update)

     

  • Aaron Stebner's WebLog

    Beta 2 version of Windows Media Center SDK for Windows Vista now available

    • 0 Comments

    I posted an annoucement on the Media Center Sandbox site earlier today, and I want to cross-post it here to make sure that everyone sees it.  I'm really excited to announce that the final beta 2 version of the Windows Media Center SDK (build 5384.4) for Windows Vista beta 2 has been released on the Microsoft Connect site.  We will also be releasing it to the MSDN Subscriber site in the next couple of days.

    If you're interested in developing applications for Windows Media Center, this build of the SDK is a great chance to get started.  As always, make sure to let us know any feedback you have by reporting bugs on the Connect site and posting comments/questions on the Media Center development forum.

     

  • Aaron Stebner's WebLog

    Beta version of Microsoft Locale Builder now available for download

    • 0 Comments

    A friend of mine sent me a link to an interesting tool that has a beta version available for download.  It is called the Microsoft Locale Builder, and it can be installed and used on Windows Vista beta 2.  In a nutshell, it allows users to create customized locales that do not ship as a part of Windows.

    The following description appears on the Microsoft Locale Builder download page:

    The Microsoft Locale Builder provides a way to extend and modify the set of locales that Microsoft ships with your own regional and cultural data. The Microsoft Locale Builder was created to support customers in regions without built-in Windows locales as well as customers seeking to modify locales that they are already using. Customers will be able to add support on their own timeline without having to wait for new releases of Windows. Microsoft Locale Builder will also allow corporations, governments, universities, and special-interest groups to generate and easily share custom locales on Microsoft Windows Vista.

    You can also find more details about custom locale creation in this MSDN article.

     

  • Aaron Stebner's WebLog

    My file server is back up and running

    • 0 Comments

    I posted an item this morning indicating that the server that I use to host my troubleshooting tools has been down for the past couple of days.  I'm happy to report that it is back up and running now, so you will be able to download any of the troubleshooting tools that are linked in my other blog posts with no issues.  Please contact me if you are still seeing any download problems...

     

Page 1 of 1 (22 items)