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

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>