Partager via

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

  • Article

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 https://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 https://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>

Comments

  • Anonymous
    November 17, 2010
    Aaron, I'm getting the infamous 1935 failure/error with HRESULT of 80070003 (directory not found) when trying to install either the 2005 or 2008 VC++ runtimes on my Win 7 Pro, fully patched (they're not in the Programs & Features list, and nothing strange is seen in Windows Install Clean Up). Happens whether .NET 3.5 is on or off. I uninstalled the .NET 4 profile also, and tried doing installing from a vanilla environment. Do the runtimes require .NET 1.1? I'm not sure if that's on my machine. The odd thing is that Windows Update offers the security update for the 2005 runtime, which fails; and in %windir%winsxs, there seemingly are directories for both 8.0 & 9.0 runtimes. Is there a way to manually remove the runtime files and Registry references to them, so that the packages can be reinstalled? The System Update Readiness Tool and sfc tests return that the system is perfectly healthy. Thanks. -- Helge

  • Anonymous
    November 20, 2010
    The comment has been removed

  • Anonymous
    December 29, 2011
    okay, so I have opened the CBS. which of the three links do you recommend i try? again this is for a computer game and the exact error code is: Microsoft VC++ 2005 redistributable Error 1935. an error occurred during the installation of assembly. 'microsoft. "win32. version"' after i go to the link ill try to figure it out.... again, thank you so much..... been searching for so many days with nothing......

  • Anonymous
    December 30, 2011
    Hi Seth - Here are the things I usually suggest for this type of error:

  1.  Install the latest Windows service pack if you haven't yet
  2.  Try the System Update Readiness Tool from support.microsoft.com/.../947821
  3.  Try to use SFC to repair the files that are a part of your OS by using steps like the ones at blogs.msdn.com/.../how-to-repair-the-net-framework-2-0-and-3-0-on-windows-vista.aspx
  4.  If none of the above help, it might be necessary to repair/re-install Windows to solve this type of problem
  • Anonymous
    September 24, 2012
    I recently was able to fix a similar error. It was very difficult to diagnose, but the symptom was this error or a similar one depending on what I was doing. I also found that windows updates were failing and had several applications giving me a similar error when I was trying to load them. After visiting numerous sites and trying multiple things I finally stumbled on how to fix it. I will attempt to explain it here. First, try running the sfc command. If this works you can avoid some fairly tedious extra steps.
  • From the Windows Start menu, open Accessories, right click on a command prompt and select Run as administrator.
  • From the command prompt, Run the 'sfc /scannow' command.With any luck this will run several minutes. It will produce a fairly detailed report of what it finds and fixes in the WindowsLogsCBSCBS.log file. To view that file you may need to copy and paste. Much may not make must sense if you aren't to computer literate but it will fix a host of issues.
  • In MY case, this command was failing with the following error:  Windows Resource Protection could not perform the requested operation. I looked into why I got that error and that led me to finding out I had a TrustedInstaller issue:
  • Open the Start menu and type services and open the Services application.
  • Look in the list of services for Windows Module Installer. In my case, this application was not there.
  • Look in the WindowsServicing folder. There should be a file called ‘TrustedInstaller’ but in all likelihood there is not.
  • Open Start and search your system for TrustedInstaller. Mine was in
  • Copy the TrustedInstaller to the WindowsServicing folder. Your first attempt will likely fail with ‘Access Denied’ even if you try to do this as administrator. This is because TrustedInstaller user ‘owns’ the WindowsServicing window. In order to copy you will need to view the security properties on the Servicing folder and set the owner to your administrative user:
  • Right click on the Servicing folder select Properties. Select the Security Tab. Select Advanced.
  • Select Owner and set the user to an admin user on your machine. . You can then paste TrustedInstaller into the folder. IMPORTANT: after doing so, set the owner back to Trusted Installer: www.vistax64.com/.../159360-trustedinstaller-restore-owner.html Once you’ve done this, reboot. Open Services again and you will see Windows Module Installer is now in the services list. Open a command prompt using instructions above and again run ‘sfc /scannow’. It’ll take several minutes. Once I did the above, I found that Windows updates now installed and all the applications that I had been trying to install (iTunes, Cyberlink PowerDirector, Visual Studion C++ 2008 Redistributable were some) now installed without issue. I hope this helps someone as I tried all sorts of stuff before stumbling on this combo of things.