One of possible solutions to: Visual C++ 2008 Redistributable installation error 1935 with HRESULT 0x8007005

Hi,

this post is slightly offtopic, but I'd like to share this experience because this might be a reason why Visual Studio or any other application that needs Visual C++ redistributable libraries fail during installation.  

Background:

I've used DriverCleaner on a PC with this issue to clean ATI drivers on my TouchSmart, later I tried installing Windows 7 SP1 which was failing with famous: Windows 7 SP1 Installation error 0x800f0826. This was solved by copying missing files from another Windows 7 PC (forums have instructions about that), but *main* point here is to be able to copy those files you need to take ownership of Windows\winsxs folder from TrustedInstaller and then restore for TrustedInstaller (I can hardly recall now, but most likely I also did replace permissions defined for window\winsxs to all it child items). Also I installed System Update Readiness Tool for Windows 7 at that time,  anyways, I managed to install SP1.

Time has passed, updates were being installed automatically, but one day in summer I've noticed that Security Update for Visual C++ 2008 Redistributable is failing to install. I tried to download it separately and install but was getting installation error for Microsoft.VC90.ATL assembly with error code 1935 and HRESULT 0x8007005.

I figured out that HRESULT 0x8007005 stands for "Access denied" and whole installation process was obviously related to Windows\winsxs folder. As soon as I knew I've touched it, I decided to check out how to properly restore permissions to that folder.

Note that uninstalling .NET 3.5.1, no sfc /scannow, no System Update Readiness Tool, no built in to Windows troubleshooter for update related problems could solve it. I also had some .NET installation verifier application, which found no errors.

Solution:

http://blogs.msdn.com/b/astebner/archive/2005/11/10/491653.aspx?PageIndex=2

has following post from user muuzzi dated: 2 Jun 2008 8:48 PM

Hi V!ctor and Astebner, I encountered the same problem while installing VS 2008 in my Vista.

I noticed there was a folder InstallTemp inside Winsxs. Do you ever changed the owner and permissions of Winsxs folder? (Weeks ago I changed the permissions to compress the Winsxs folder.) If so, you may not set the permission correctly. The most important thing is: The two folders - winsxs and winsxs\installtemp - have different permissions! InstallTemp should be granted Full Control to System and Administrators. If not, the setup program could not write vc80 dlls or vc90 dlls into the folder.
 
After I re-set the correct permissions, and run SFC.EXE /scannow to repair the consistency of system files, the setup of VS 2008 succeeded.

I've highlighted most inportant part. As soon as I knew that I was messing around with permissions I decided to check out, indeed that have different permissions and owners.To be able to modify Windows\winsxs folder I assigned ownership to Administators group (set check box to replace ownership to all child items also, otherwise you will not be able to modify permission settings for InstallTemp folder). Now edit permissions for InstallTemp (it will be inheriting from parent, uncheck that setting, dialog will popup about what to do with current parent permissions, choose "Add", that will explicitly define these permissions for that folder), define:

1)Full control to SYSTEM

2)Read & execute, List folder contents, Read, Write for Administrators group

3)Read for Users group

Save and verify that indeed this folder now has it's own set of permissions. Next step is to revert ownership to Trusted installer: open security settings for Windows\winsxs folder and change ownership from current Administrators group to TrustedInstaller (NETWORK SERVICE\TrustedInstaller), don't forget to check setting to replace ownership also for all child elements. When this all done Windows\winsxs and all child folders (except InstallTemp) would have same permissions and InstallTemp would have it's own set.

You can always refer to another Windows 7 PC for detailed comparison of permissions.

I ran sfc /scannow just in case, tried to install vcredist and success, in Windows Update I clicked "Check for updates" and it suggested me to install Security update again but this time file size was different (I feel like my vcredist was newer), tried it said: failed to install, I clicked "Try again" and it was successful. Reboot, "Check for updates" - you Windows is up to date message, nice :)

That's it :)