Aaron Stebner's WebLog

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

March, 2009

  • Aaron Stebner's WebLog

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

    • 67 Comments

    Question:

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

    Answer:

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

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

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

    Unattended install

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

    <full path>\vcredist_x86.exe /qb

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

    c:\vc2008redist\vcredist_x86.exe /qb

    Unattended install with no cancel button

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

    <full path>\vcredist_x86.exe /qb!

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

    c:\vc2008redist\vcredist_x86.exe /qb!

    Silent install

    This option will suppress all UI during installation.

    <full path>\vcredist_x86.exe /q

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

    c:\vc2008redist\vcredist_x86.exe /q

    Related links:

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

     

  • Aaron Stebner's WebLog

    How to perform a silent repair and uninstall of the .NET Framework 3.5 and 3.5 SP1

    • 5 Comments

    Question:

    I have seen your blog posts that describe how to silently repair and uninstall the following versions of the .NET Framework:

    How can I perform a silent repair and uninstall for the .NET Framework 3.5 SP1?

    Answer:

    The following list provides example command lines that can be used to repair and uninstall the MSI-based .NET Framework 3.5 SP1 package after it has been installed on the system.  The silent option will perform the repair/uninstall with no UI displayed to the user.  The unattended option will perform the repair/uninstall with only a progress dialog, but with no user interaction required.

    .NET Framework 3.5 SP1 - silent repair

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

    .NET Framework 3.5 SP1 - unattended repair

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

    .NET Framework 3.5 SP1 - silent uninstall

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

    .NET Framework 3.5 SP1 - unattended uninstall

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

    Important notes about repair scenarios:

    • The .NET Framework 3.5.1 (an updated version of the .NET Framework 3.5 SP1) is installed as an OS component on Windows 7.  As a result, the MSI-based versions of 3.5 or 3.5 SP1 cannot be installed on these OS's, and the above command lines will not work on these OS's.  If you need to repair the .NET Framework 3.5.1 on Windows 7, you will need to use instructions like the ones in this blog post.
    • On Windows XP and Windows Server 2003, the .NET Framework 3.5 SP1 repair process will chain the repair processes for the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2, so there is no need to use separate steps to repair those products if you are going to repair the .NET Framework 3.5 SP1 on these OS's.
    • On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 are OS components, and the repair of the .NET Framework 3.5 or 3.5 SP1 will not repair these OS components.  If you need to repair the .NET Framework 2.0 and/or 3.0 on Windows Vista or Windows Server 2008, you will need to use instructions like the ones in this blog post.

    Important note about uninstall scenarios:

    • The .NET Framework 3.5 SP1 uninstall process will only uninstall the .NET Framework 3.5 SP1 MSI.  It will not uninstall the .NET Framework 2.0 SP2 or the .NET Framework 3.0 SP2 products because there may be other applications on the system that rely on those versions of the .NET Framework.  If you want to uninstall the .NET Framework 2.0 SP2 and 3.0 SP2, you must uninstall in the following order:  .NET Framework 3.5 SP1, then .NET Framework 3.0 SP2 then .NET Framework 2.0 SP2.

    Other important notes:

    • Log files will be created for the .NET Framework 3.5 SP1 repair and uninstall just like for the initial install.  You can find a list of .NET Framework 3.5 and 3.5 SP1 log files in this blog post.
    • When calling .NET Framework 3.5 SP1 setup in silent or unattended mode, you should check the return code from the setup.exe process in order to determine success or failure.  Return code 0 means that the setup was successful, return code 3010 means that the setup was successful but a reboot is required to complete the setup and any other return code means that there was an error.  If you receive a 3010 return code, the reboot is required before all .NET Framework functionality will be expected to function correctly on the user's system, so it cannot be deferred forever.
    • The above examples only demonstrate the command lines used for repair and uninstall.  For install scenarios, I recommend reviewing the content in the .NET Framework 3.5 deployment guides as well as the steps for creating administrative install points.
  • Aaron Stebner's WebLog

    .NET Framework 3.5 SP1 setup will fail if it is run by a user account that starts with a # character

    • 7 Comments

    I was working with our product support team on an interesting .NET Framework 3.5 SP1 installation failure earlier this week, and I wanted to describe the issue and options for working around it in case anyone else runs into similar issues in the future.

    Description of the issue

    If you run .NET Framework 3.5 SP1 setup with a user account whose name begins with a # character, the installation will fail.

    In this scenario, if you open the verbose MSI log file for the .NET Framework 3.5 SP1 (%temp%\dd_net_framework35*.txt from this list of log files) and search for the string return value 3, you will see an error like the following:

    MSI (s) (1A:BC) [11:11:11:111]: Product: Microsoft .NET Framework 3.5 SP1 -- Error 1406.Could not write value InstalledBy to key \SOFTWARE\Microsoft\Updates\Microsoft .NET Framework 3.5 SP1\KB953595.  System error .  Verify that you have sufficient access to that key, or contact your support personnel.

    The registry key that is causing this failure is new in the .NET Framework 3.5 SP1, so this error will not occur when installing the .NET Framework 3.5 or earlier.

    How to work around the issue

    If you encounter this error when trying to install the .NET Framework 3.5 SP1 with a user account whose name begins with a # character, you can do one of the following to work around this and successfully install:

    1.  Run .NET Framework 3.5 SP1 setup with a different user account

    You can either log off and log on with another user account or use the RunAs command to run .NET Framework 3.5 SP1 setup with a different user account that does not start with a # character to avoid this error.

    2.  Manually set the registry values before running .NET Framework 3.5 SP1 setup

    You can pre-configure the problematic registry key and values on your system before installing the .NET Framework 3.5 SP1 to avoid this error.  This will cause setup to skip setting the values because they are already present.  To do this, you will need to set the following registry values on your system:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Microsoft .NET Framework 3.5 SP1\KB953595]
    "ThisVersionInstalled"="Y"
    "ARPLink"="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CE2CDD62-0124-36CA-84D3-9F4DCF5C5BD9}.KB953595"
    "PackageName"="Hotfix for Microsoft .NET Framework 3.5 SP1 (KB953595)"
    "PackageVersion"="1"
    "Publisher"="Microsoft Corporation"
    "PublishingGroup"="Developer Division"
    "ReleaseType"="Hotfix"
    "InstalledBy"="yourusername"
    "InstalledDate"="2/27/2009"
    "InstallerName"="Windows Installer"
    "InstallerVersion"="4.00"

    All of the above registry values should be set with the REG_SZ data type.  The exact data set for the InstalledBy and InstalledDate values can be set to data of your choosing.

    The InstallerVersion value should be set to the Windows Installer major and minor version on your system.  You can determine the appropriate value on your system by running msiexec.exe /? and looking at the version number listed at the top of the dialog that appears.

    Root cause of the issue

    The entry for the InstalledBy value in the Registry table of the .NET Framework 3.5 SP1 MSI is set to the value [LogonUser].  This will set the registry value to the built-in Windows Installer property named LogonUser.

    If the LogonUser property begins with a # character, Windows Installer will attempt to write the InstalledBy registry value as a REG_DWORD value (because the # character is a special prefix when used in a registry value as described in this MSDN topic).  However, if the LogonUser value is not actually a DWORD, the MSI will fail with a 1406 error like the one listed above.

  • Aaron Stebner's WebLog

    Steps I use to narrow down an OS update installation failure on Windows Vista and higher

    • 33 Comments

    A while back, I wrote a blog post describing a specific error that can occur when trying to install the .NET Framework 3.5 or 3.5 SP1 on Windows Vista and Windows Server 2008.  In that post, I talked at a high level about some of the steps I take to narrow down this type of error.  Those troubleshooting steps are useful in more scenarios than just the one in that blog post, and they are hard to find in a search currently because of the post that they're currently located in.  As a result, I decided to write a standalone post that describes the steps I follow when trying to narrow down an OS update installation failure on Windows Vista and Windows Server 2008.  I am going to write this post from the perspective of troubleshooting a .NET Framework 3.5 and 3.5 SP1 installation failure on Windows Vista, but the same techniques are typically valid for other OS update installation failures on Windows Vista and higher.

    It is important to keep in mind that the .NET Framework 3.5 and 3.5 SP1 both install updates to the .NET Framework 2.0 and 3.0 behind the scenes.  On Windows Vista and higher, the .NET Framework 2.0 and 3.0 are installed as OS components, so that means that the updates to 2.0 and 3.0 are OS update packages.  This means that failures in the .NET Framework 3.5 and 3.5 SP1 setups on Windows Vista and higher can possibly be caused by problems with the OS update engine.

    Find the error in the .NET Framework setup log file

    If I am investigating an error installing the .NET Framework 3.5 or 3.5 SP1, I start by opening the log file named %temp%\dd_dotnetfx35install.txt and searching for the string ***errorlog event***.  If the problem is in an OS update, then the error in the log will indicate a failure installing the component named Microsoft .NET Framework 2.0SP1 (CBS) or Microsoft .NET Framework 3.0SP1 (CBS).

    If one of these components is the cause of the failure, there will be lines in dd_dotnetfx35install.txt directly above the ***errorlog event*** that look like the following:

    [03/03/09,11:11:11] Microsoft .NET Framework 3.0SP1 (CBS): C:\Windows\system32\WUSA.exe exited with return value 2148468760
    [03/03/09,11:11:11] InstallReturnValue: GFN_MID NET Framework 3.0SP1 (CBS), 0x800f0818

    The name of the component and the HRESULT value listed for the InstallReturnValue will vary depending on the root cause of the failure, but the process name will always be WUSA.exe - this is the Windows Update Standalone Installer that is used to install OS updates on Windows Vista and later.

    Find the error in the OS update installation engine log file (cbs.log)

    One I have determined that the root cause of the failure is an OS update, I proceed to look at the log file at %windir%\logs\cbs\cbs.log.  This is the verbose log file for the OS update installation engine on Windows Vista and higher.  This log file is typically very large, and there are a couple of different ways I try to narrow down the error in this log:

    1. Search for the value listed in the InstallReturnValue entry from the dd_dotnetfx35install.txt log file in cbs.log.  For the above example, I would search for 0x800f0818.
    2. Search for the string generating failure report in cbs.log.

    For the above example, text appears in cbs.log that looks like the following:

    2009-03-03 11:11:11, Info                  CBS    WER: Generating failure report for package: Package_for_KB948610~31bf3856ad364e35~x86~~6.0.6001.2123, status: 0x800f0818, failure source: Execute, start state: 4, target state: 7

    Determine the meaning of the error and possible workarounds

    From here, the next step I take depends on what data appears in cbs.log.  Some of the information I look for is the following:

    1. Does the same error code occur for multiple different OS update packages?  If so, that typically means that there is a problem with the OS update engine itself as opposed to with the update that is failing.
    2. Does the error code appear in the System Update Readiness Tool knowledge base article?  If so, I typically try to use the tool available in that knowledge base article and/or the steps in this blog post.
    3. Does the error code appear in the table of common CBS error codes?  If so, I try the workaround suggested there for the error code that I found in cbs.log.
    4. If the error code does not appear in either of the above articles, then I try to use the err.exe tool to determine more detailed information about the cause of the error.

    Sometimes, no error code information will appear in cbs.log.  In those cases, I also look for the error code in %windir%\WindowsUpdate.log.  There is a table of Windows Update Agent error codes that can be useful for error codes that appear in WindowsUpdate.log.

    For additional information

    While researching this blog post, I found a useful link on TechNet - http://technet.microsoft.com/library/cc732334.aspx.  This link contains more details about how to read and interpret the following log files:

    • %windir%\WindowsUpdate.log
    • %windir%\logs\cbs\cbs.log

    It includes a table of common errors that can appear in a cbs.log along with possible resolutions or workarounds.

    <update date="12/2/2009"> Added a link to a table of Windows Update Agent error codes that can appear in %windir%\WindowsUpdate.log and can be helpful in troubleshooting OS update installation issues in some cases. </update>

     

  • Aaron Stebner's WebLog

    My WinISP file server has been retired - please use my SkyDrive site instead

    • 0 Comments

    I have heard from several folks over the past couple of weeks who have had trouble downloading the tools and samples that I have posted on my old file server (http://astebner.sts.winisp.net).  That site has been retired by the group that was hosting it, and so none of those links will work anymore.  I have recovered all of the files that were on that site, and I have moved them all over to my SkyDrive site.  I replicated the same folder structure that used to be on my old site at the following location:

    http://cid-27e6a35d1a492af7.skydrive.live.com/browse.aspx/Blog%7C_Tools

    I don't have any way to automatically re-direct links in my old blog posts to this new site, so I will try to get the old blog posts updated in the future when I get questions about them.

    I'm sorry for the inconvenience this may be causing for anyone looking for information on my blog.  Please let me know if you run into any issues downloading any of the files from my SkyDrive site.

  • Aaron Stebner's WebLog

    Updated VS bootstrapper packages for .NET Framework 2.0 SP2 and 3.0 SP2 with post-SP2 GDR included

    • 5 Comments

    This week, new Visual Studio 2008 bootstrapper packages were released for the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2.  These packages are updated versions of the packages released last fall that I described in this blog post.  They contain the following changes:

    • The updated 2.0 SP2 bootstrapper package includes the installer packages for 2.0 SP2 and the update for 2.0 SP2 (KB958481), and it will chain both of these packages during the install process if they are not yet installed on the target system.
    • The updated 3.0 SP2 bootstrapper package includes the installer packages for 3.0 SP2 and the update for 3.0 SP2 (KB958483), and it will chain both of these packages during the install process if they are not yet installed on the target system.
    • The packages are now available in all Visual Studio languages.
    • The packages now support both x86 and x64 processor architectures.

    Here are some links for the updated .NET Framework 2.0 SP2 and 3.0 SP2 bootstrapper packages for VS 2008:

    There are a few caveats to keep in mind when using the updated .NET Framework 2.0 SP2 and 3.0 SP2 bootstrapper packages:

    • They only support installing on Windows XP and Windows Server 2003.  You cannot use them on Windows Vista or Windows Server 2008.  If you need to install the .NET Framework 2.0 SP2 or 3.0 SP2 on Vista or Windows Server 2008 as a part of your application installer, you should use the .NET Framework 3.5 SP1 bootstrapper package that is included with Visual Studio 2008 SP1 instead.
    • They do not support the "Download components from the component vendor's web site." option.  This means when you build your installer and include one of these bootstrapper packages, you will see build warnings about the HomeSite attribute, and the full contents of the .NET Framework 2.0 SP2 and/or 3.0 SP2 installers will be included next to setup.exe in your build output.  If you would prefer to have download-on-demand functionality for the .NET Framework in your setup, then you should use the .NET Framework 3.5 SP1 bootstrapper package instead.
  • Aaron Stebner's WebLog

    How to extract a .NET Framework 1.0 and 1.1 patch and run it if the patch setup EXE crashes

    • 0 Comments

    Every once in a while, I hear from a customer who is trying to install a hotfix or service pack for the .NET Framework 1.0 or 1.1, but who encounters a crash when double-clicking the setup .exe for the hotfix or service pack.  In some of those cases, the troubleshooting steps in this previous blog post are helpful, but in other cases, none of those steps help either.

    When those other troubleshooting steps don't help, I typically suggest that the customer try to extract the Windows Installer patch package (*.msp) from the setup .exe and then try to install the .msp file directly.

    Here are some sample steps that can be used to extract the .NET Framework 1.1 SP1 .msp file and install it directly:

    1. Download the .NET Framework 1.1 SP1 setup package and save it to your hard drive
    2. Create a folder named c:\dotnetfx11 (or whatever you want to name it on your system)
    3. Run this command:  NDP1.1sp1-KB867460-X86.exe /Xp:c:\dotnetfx11\dotnetfx11sp1.msp

      Note: This step will crash if the folder that you use in the /Xp switch does not already exist, so make sure to use the same folder name in step 3 that you create in step 2, or use a folder in step 3 that already exists on your system.

    4. Go to c:\dotnetfx11 and double-click on dotnetfx11sp1.msp to install the .NET Framework 1.1 SP1.

    Here are some sample steps that can be used to extract the KB928366 hotfix for the .NET Framework 1.1 .msp file and install it directly:

    1. Download the KB928366 setup package and save it to your hard drive
    2. Create a folder named c:\dotnetfx11 (or whatever you want to name it on your system)
    3. Run this command:  NDP1.1sp1-KB928366-X86.exe /Xp:c:\dotnetfx11\kb928366.msp

      Note: This step will crash if the folder that you use in the /Xp switch does not already exist, so make sure to use the same folder name in step 3 that you create in step 2, or use a folder in step 3 that already exists on your system.

    4. Go to c:\dotnetfx11 and double-click on kb928366.msp to install the KB928366 hotfix for the .NET Framework 1.1 SP1.
  • Aaron Stebner's WebLog

    GDC 2009: Announcing XNA Game Studio 3.1 and Dream-Build-Play 2009

    • 1 Comments

    As mentioned on the XNA team blog and this XNA Creators Club forum post, the XNA team made a few announcements today at GDC 2009:

    1.  XNA Game Studio 3.1

    Later this year, an updated version of XNA Game Studio will be released.  It will contain the following features:

    • Support for customized Avatars
    • Support for Xbox LIVE Party features
    • Video playback
    • Updated audio APIs for “fire-and-forget” scenarios
    • Support for XACT3
    • Automatic XNB serialization
    • XNA Framework multi-targeting in the Visual Studio 2008 and/or Visual C# 2008 Express Edition IDE
    • Downloadable content for Xbox LIVE Arcade titles that use XNA Game Studio 3.1
    • Consumer notifications when an Xbox LIVE Community Game that they have purchased has been updated

    2.  Dream-Build-Play 2009 contest

    The 3rd edition of Dream-Build-Play will start on April 6, 2009.  More information will be available at http://www.dreambuildplay.com soon.

    3.  New Xbox 360 Development Kit and Test Kit hardware

    You can check out images of the new Xbox 360 development and test kit hardware in the links at the bottom of the press page at http://creators.xna.com/press/gdc2009.

    Here are a couple of links with additional information about the above announcements:

    <update date="3/26/2009"> Added a link to Shawn Hargreaves' blog post about automatic XNB serialization. </update>

    <update date="4/23/2009"> Added a link to Michael Klucher's blog post about video playback. </update>

     

  • Aaron Stebner's WebLog

    GDC 2009 is coming next week and I hope to see you there

    • 1 Comments

    Most people probably know that the 2009 Game Developers Conference (GDC 2009) is coming up next week in San Francisco, California, USA.  There will be two developer days next Monday and Tuesday (March 23 and 24, 2009), and the main conference will be open next Wednesday through Friday (March 25, 26 and 27, 2009).

    I'll be in San Francisco from Tuesday afternoon, March 24, through Friday afternoon, March 27, for GDC this year.  I hope to see you there to talk about XNA Game Studio and game development.

    Here is some more information about some things to look for if you're attending GDC 2009:

    Overview of Microsoft-sponsored talks at GDC

    The developer day on March 23 will focus on XNA Game Studio technologies.  The developer day on March 24 will focus on DirectX and Xbox 360 game development technologies.  There will also be several talks during the main GDC conference about Microsoft game development technologies.

    My colleague Michael Klucher posted this item on his blog that contains a detailed listing of the developer day tracks and the conference talks, so I encourage you to check out that schedule if you're going to be at GDC this year.

    Information about the XNA Lobby Bar

    In addition, the XNA team will be hosting a lobby bar Wednesday through Friday for conference attendees.  There will be some brief talks with hands-on demos and an "ask the experts" area where you can meet team members and ask questions in a more informal setting.  Michael also posted a schedule for the GDC lobby bar talks in this post on his blog.  Among other talks, there are a couple that are specifically focused on XNA Game Studio and Xbox LIVE Community Games:

    • Best Practices for Xbox LIVE Community Games (Wednesday March 25 at 10am and Friday March 27 at 1pm)
    • XNA Game Studio: Make a Game and Publish It in 30 Minutes or Less (Wednesday March 25 at 1pm and Thursday March 26 at 11am)
  • Aaron Stebner's WebLog

    GDC 2009: Grab a burger and meet some members of the XNA team Wednesday night

    • 0 Comments

    I was talking with Michael Klucher and a few other folks on the XNA team last week about things to do while we’re in San Francisco for GDC 2009 this week.  Most of us like to take advantage of the opportunity to visit In-N-Out Burger while we’re in California since we don’t have those in the Seattle area, so we decided to try to work that into the schedule and meet with folks using XNA and/or playing Xbox LIVE Community Games at the same time.

    A few of us are going to head out to the In-N-Out by Fisherman’s Wharf for dinner on Wednesday night, March 25.  If you’re going to be in the San Francisco area for GDC 2009 or otherwise next week, and you’d like to grab dinner and talk about XNA development technologies (XNA Game Studio, etc) or Xbox LIVE Community Games, we’d love to see you there.

    Here’s the details about when and where we’re going to be eating:

    We hope to see you there!

Page 1 of 1 (10 items)