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.
I have heard from several people over the past week or so who have had problems getting the recently released .NET Framework security update (MS09-061) to install correctly on their system when it is offered to them by Windows Update or Microsoft Update. This blog post will describe what this type of failure typically looks like and will offer some steps you can use to try to resolve this type of error.
For reference, this .NET Framework security update is listed on the Windows Update download page with several different possible knowledge base numbers, depending on what version of the .NET Framework the update applies to and what operating system you are running. Here is a list of knowledge base article numbers for this security update:
Description of the issue
If this .NET Framework security update or any other update fails to install when running it from the Windows Update site, you will normally see Windows Update report back a generic error code of 0x643 or 1603. This is a catch-all error code that means that setup failed, but it doesn’t provide any more detailed information about why it failed or how to fix the failure.
In most cases, when a .NET Framework update fails to install with a 0x643 or 1603 error code, it means that there is something wrong with the version of the .NET Framework that is installed on the system that the update is supposed to be fixing. There are a few different ways to go about resolving this error and getting the update to install successfully.
How to solve the issue by uninstalling and re-installing the .NET Framework
The simplest way to solve this type of issue is to use the steps listed at http://blogs.msdn.com/astebner/archive/2008/03/07/8108332.aspx to remove all versions of the .NET Framework from your system, then re-install them in the following order:
After this, you should be able to go back to the Windows Update site, scan for updates again and install the latest updates for the .NET Framework 1.1 and 2.0 from there.
Note – after removing all versions of the .NET Framework, you do not necessarily have to re-install the .NET Framework 1.0 or 1.1 if you do not have any applications that are using them. Most .NET applications will automatically use the latest version of the .NET Framework that is installed on your system, and those that do not will give an error message indicating that you need to install a different version. There is more information about this scenario in this blog post if you are interested in reading further.
How to solve the issue by finding more information about the root cause
The above steps involve uninstalling, re-downloading and re-installing all of the versions of the .NET Framework on your system, which can be a bit time consuming. Instead, if you prefer, you can try to narrow down the root cause of the .NET Framework security update installation error further and try to solve this issue without performing all of the .NET Framework uninstalls and re-installs listed above.
There are a couple of things I usually do to try to narrow down the root cause of this type of .NET Framework security update installation failure further:
Peter Marcu has posted some detailed information about improvements that have been made to the setup and deployment process for the .NET Framework 4 starting with the recently released .NET Framework 4 beta 2 and Visual Studio 2010 beta 2. The improvements have been made to solve issues that exist in the .NET Framework 3.5 and 3.5 SP1 and to address customer feedback that has been received from previous releases. The improvements that Peter describes are focused on the following areas:
I encourage you to read Peter’s blog post at http://blogs.msdn.com/pmarcu/archive/2009/09/30/net-framework-4-0-beta-2-deployment.aspx to learn more about the specific improvements being made to the .NET Framework setup and deployment process in the .NET Framework 4 product.
As noted on Soma’s blog, the .NET Framework 4 beta 2 and Visual Studio 2010 beta 2 have been released today. If you previously had the .NET Framework 4 beta 1 and/or Visual Studio 2010 beta 1 installed, there are some very important uninstall instructions that you must follow in order to fully uninstall beta 1 so that beta 2 will work correctly.
If you had the .NET Framework 4 beta 1 and/or VS 2010 beta 1 installed, please follow the instructions at http://go.microsoft.com/fwlink/?LinkID=167718 to fully uninstall beta 1 before you install beta 2.
These instructions explain how to fully uninstall VS 2010 beta 1 and then fully uninstall the .NET Framework 4 beta 1. If you do not follow the above instructions, you may see a crash dialog during the installation of VS 2010 beta 2, and you may see package load failures when trying to use VS 2010 beta 2. The instructions linked above also contain steps to repair the .NET Framework 4 beta 2 and VS 2010 beta 2 in order to recover from these errors.
If you run into any issues that are not covered by the above instructions, I encourage you to check out the .NET Framework 4 and VS 2010 pre-release forums for additional troubleshooting suggestions and workarounds.
Introduction
1935 errors can occur during an MSI-based installation while installing .NET assemblies or Win32 assemblies. Most of the workarounds that can be found on blogs and forums (including all of the information in my 1935 error troubleshooting guide) only apply to 1935 errors that happen while installing .NET assemblies.
This blog post will explain how to troubleshoot 1935 errors that occur while attempting to install Win32 assemblies in an MSI-based installer.
The information in this blog post only applies to Windows Vista and later versions of Windows, and it also only applies to Win32 assemblies.
For additional information about troubleshooting 1935 errors that occur on versions of Windows before Windows Vista and that occur for managed (.NET Framework) assemblies, please refer to the 1935 error troubleshooting guide.
How to identify a 1935 error caused by a Win32 assembly on Windows Vista and later
For 1935 errors that occur while installing Win32 assemblies in an MSI-based setup (which I have seen most commonly in the past for Visual C++ runtime files), there are some specific diagnosis and troubleshooting steps that you will need to use that are different than the ones used for managed assemblies.
On Windows Vista and higher, Windows Installer uses the same underlying installation engine as the OS component installation engine (also known as CBS) to install Win32 assemblies. As a result, anything that can cause an OS update or hotfix to fail to install can cause this type of 1935 error. You will typically need to do some more in-depth analysis on the affected system in order to narrow down the root cause and identify possible solutions.
When this type of 1935 error occurs, you will see the following information in a verbose MSI log file:
MSI (s) (54:32) [12:34:56:789]: Assembly Error (sxs): To get more diagnostic information, enable the Component Based Servicing Log.
How to identify a root cause and possible solution
As the above log file entry suggests, there is not enough detailed error information in a verbose MSI log file to determine a root cause of this type of 1935 error. That means you will need to look in the Component Based Servicing (CBS) log file to try to narrow down the root cause further. This log file is enabled and created by default on Windows Vista and higher, and it is located at %windir%\logs\cbs\cbs.log.
You will notice that cbs.log is typically very large and can be difficult to read. What I typically do is look at the time stamps for the 1935 error messages in the verbose MSI log file, then cross-reference those time stamps with the ones listed in cbs.log to try to find the exact error in cbs.log. From there, I use the links listed in the blog post at http://blogs.msdn.com/astebner/archive/2009/03/12/9472695.aspx to find more detailed information about the error code that is listed in cbs.log and to try to come up with workarounds from there.
In some cases, the operating system will lock the file cbs.log so that you cannot open it. In those cases, it usually works to make a copy of cbs.log in a new location and then open the copy of the file instead.
Unfortunately, a 1935 error caused by a Win32 assembly on Windows Vista and later can be a pain to diagnose and solve because of the wide range of possible causes. I have had the most luck in the past by using the System Update Readiness Tool to solve issues related to the OS component installation engine. There are some steps listed at http://blogs.msdn.com/astebner/archive/2009/01/09/9303167.aspx that I recommend trying in a lot of these scenarios.
Note - If you see error code 0x800705aa (which means ERROR_NO_SYSTEM_RESOURCES) in your cbs.log file, then it could be caused by the issue described in this discussion thread.
<update date="1/18/2010"> Added a link to a discussion of error code 0x800705aa in cbs.log. </update>