Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS with no warranties, and confer no rights. Additionally, views expressed herein are my own and not those of my employer, Microsoft.
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 /qbFor 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 /qFor 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>
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?
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:
Important note about uninstall scenarios:
Other important notes:
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.
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.
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:
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:
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:
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>
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:
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:
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:
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:
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:
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>
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:
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!