Aaron Stebner's WebLog

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

October, 2009

  • Aaron Stebner's WebLog

    Suggestions for resolving installation errors for .NET Framework security update MS09-061

    • 5 Comments

    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:

    • For the .NET Framework 2.0 on operating systems before Windows Vista - KB953300 and KB974417
    • For the .NET Framework 2.0 on Windows Vista and Windows Server 2008 - KB974468, KB974292, KB974467, KB974291, KB974469 and KB974470
    • For the .NET Framework 1.1 - KB953297
    • For the .NET Framework 1.0 - KB953295

    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:

    1. .NET Framework 3.5 SP1 (this version of the .NET Framework will also install the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 for you behind the scenes, so you don’t need to re-install 2.0 or 3.0 using separate steps)
    2. .NET Framework 1.1
    3. .NET Framework 1.1 SP1

    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:

    1. Try to download and install the update yourself instead of letting Windows Update install it for you.

      Windows Update always runs the installers for updates in silent mode, which can hide some useful error messages if the updates fail.  You can find the links to download this .NET Framework security update by going to the page for the security bulletin, scrolling down to the Affected Software table, and locating the link in the Component column of the table that corresponds to the version of the .NET Framework you need to update and the operating system you are running.

    2. Look at the setup log files created by the security update.

      This .NET Framework security update should create log files in a sub-directory under your %temp% directory.  The sub-directory will have the knowledge base article number in the name.  For example, the .NET Framework 1.1 security update (KB953297) will create logs in a folder named %temp%\NDP1.1sp1-KB953297-X86.
  • Aaron Stebner's WebLog

    Link to information about .NET Framework 4 setup and deployment improvements

    • 0 Comments

    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:

    • Size – making the overall download and install size of the .NET Framework 4 smaller
    • Robustness – making the download and installation process more reliable
    • Performance – making the download and install time faster

    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.

  • Aaron Stebner's WebLog

    Important uninstall instructions for migrating from the .NET Framework 4 and VS 2010 beta 1 to beta 2

    • 0 Comments

    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.

  • Aaron Stebner's WebLog

    Diagnosing and resolving 1935 errors for Win32 assemblies that occur on Windows Vista and later

    • 5 Comments

    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>

     

Page 1 of 1 (4 items)