ADB.exe crashing 0xc000005 on winusb.dll

An issue I've had on my work laptop with adb.exe crashing with 0xc000005 for last couple of months, I finally managed to fix it today after several attempts in various ways.

Monitoring the process with Process Monitor would reveal that is crashes after working with WINUSB.dll (ignore the highlight in blue, that was on the first attempt checking, the file should not be there)

SFC scan shows no problems with the file.

sfc /SCANFILE=C:\Windows\SysWOW64\winusb.dll

Trying the same Android SDK installation in the Windows Sandbox VM shows it working correctly, so it must be something on my physical system. The winusb.dll files on both systems show the same version, although on copying to the phyical system in te mporary location and comparing with FC /B clearly shows differences.

Now with the new version of SysWow64\winusb.dll at hand, I would try to replace the original on the physical system without success as it is owned and protected by Trusted Installer service.

Searching the web for a tool that would allow to run a process (e.g. cmd.exe or explorer.exe) as TrustedInstaller user found ExecTI from WinAero.

This would allow me to rename the old file and copy the new one in from the clean Sandbox image.

cd /D %WINDIR%\SysWow64
rename winusb.dll winusb.dll.BROKEN
copy WHERE_YOU_COPIED_IT_FROM_SANDBOX\winusb.dll winusb.dll

Running ADB again would show it working succesfully now!

adb --version
Android Debug Bridge version 1.0.41
Version 29.0.4-5871666
Installed as D:\Program Files\Android\android-sdk\platform-tools\adb.exe

The case of… breaking the WinSXS folder security rights

Just had this problem the other day when having to re-install Microsoft SQL Server 2008 R2 Express (x64) on a Windows 7  SP1 (x64), the setup was failing with the error message:

Microsoft SQL Server 2008 R2 Setup
----------------------------------
An error occurred during the installation of assembly
'Microsoft.VC80.CRT,version="8.0.50727.42",type="win32",processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b"'.
Please refer to Help and Support for more information. 

Searching the web for similar it appeared to be failing at installing Microsoft Visual C++ 2005 Redistributable package. Downloading and running the package on its own was showing the same error. After spending a lot of time digging through similar problems on the web with suggested solutions ranging from removing the *vc80* files from %WINDIR%\WinSxS and re-installing the affected packages to running the System Update Readiness Tool for Windows 7, nothing seemed to fix it. Trying a few things myself, bringing some of the related files over from a similar working system (ATL, MFC etc) into %WINDIR%\WinSxS, without much luck; taking traces with ProcMon watching for missing files, nothing.

All until almost giving up, I thought it might be a permission issue – I did remember playing with WinSxX folder recently on that system (more about it below) so filtering again with ProcMon for msiexec.exe and ACCESS DENIED results, revealed this:

msiexec.exe running under SYSTEM account was denied access to %WINDIR%\WinSxS\InstallTemp! Comparing the security for that folder to a similar working system showed that SYSTEM requires full rights there. Manually fixing the rights on that folder the installer has worked fine once again, problem solved.

* * *

Now, to the not so pleasant part where it shows that all this was due to my own stupidity, and hopefully a meaningful lesson for others.

This was a VM with a somewhat limited amount of space and was trying to compress a few larger folders found with WinDirStat (tip: hide Treemap and File types from Options menu, you don’t need them), one of them being %WINDIR%\WinSxS. You can find a lot of forum posts where people complain about it growing to take a lot of space, and other people telling you to stay away from it. In my case, the folder was about 12.5 GB and compressing it reduced it down to ~8 GB, saving quite a bit of space.

How did I do it? TrustedInstaller is the owner of the folder and a local Administrator won’t have the rights to compress – trying to compress it will give you a lot of Access Denied errors and if you ignore them all it won't compress anything. So I came up with these steps:

• take ownership of the WinSxS folder in Windows Explorer > Properties > Security tab;
• add my user with full rights and propagate the rights to the child objects;
• compress folder (Windows Explorer > Properties > General > Advanced);
• remove my user from the security list;
• give ownership back to TrustedInstaller (NT Service\TrustedInstaller).

In short this is what happened – normally SYSTEM account has only read/list rights on the WinSxS folder, but on WinSxS\InstallerTemp it has full rights (not inherited). When adding my user and propagating the rights to subfolders, it changed those full rights to read only, making the module installer fail later.

The lesson I guess is, if you are not prepared to pay the price, stay away from that folder. Or maybe otherwise be persistent and experiment to understand what’s going on, but that might take a lot of time and effort, with sometimes very little gain - 4 GB of disk space for almost a day of frustrating trial & error.

CLR Profiler for .NET Framework 4

You read all this documentation saying you should use StringBuilder instead of String.Concat() when doing a lot of string concatenations and you probably say huh, it’s all fine, what do these guys know...

And then I ran my little app processing some application logs through the CLR Profiler - looking through the allocations a huge block of 259 MB allocations jumped at me! Looking at the app from outside with Process Explorer didn’t show much memory usage but that was probably the GC doing a lot of cleanup – the collections report shows it well.

Changing the code to use a StringBuilder was not that complicated and it reduced the amount of GC work and cut the processing time in half from 20 seconds down to 10 seconds! Still more to be done, but we’re on the good track now...

CLR Profiler for .NET Framework 4
http://www.microsoft.com/download/en/details.aspx?id=16273

* * *

CLR Profiler (before)

CLR Profiler (after)

Faulting application httpd.exe, faulting module php5ts.dll

Trying to setup a web development environment on a Vista machine, pretty much the same way I've done it a few time before, although maybe with newer versions - Apache HTTP 2.2.10, PHP5 5.2.8 and MySQL 5.1. When trying to access phpMyAdmin, it was crashing with the following error in Event Viewer:

Faulting application httpd.exe, version 2.2.10.0, time stamp 0x48ef9351, 
faulting module php5ts.dll, version 5.2.8.8, time stamp 0x493d75fc, exception code 0xc0000005, 
fault offset 0x00009fe6, process id 0x18c, application start time 0x01c95d543b01222a.

I thought initially that all these new versions are not working properly together, googling for php5ts.dll I found this used to happen to other people with older versions. While reading a post with few suggestions, I remembered that in previous setups (on XP) PHP wasn't able to connect to MySQL until PHP\libmysql.dll was found somewhere in the PATH - some people were suggesting to copy it in various locations, like %WINDIR%\system32 or Apache\bin. Personally I don't like that, copying files around has the disadvantage that if you update PHP later and it's coming with an updated version of this file, you will have to remember to copy it again, otherwise you may run into problems (yes, I've done it before, but not anymore :-). The best solution is to add C:\Program Files\PHP to the system PATH, so that when you update PHP it will pick up the new dll.

Just to confirm, I ran ProcMon and set it to filter on httpd.exe process and for path libmysql.dll. I noticed that it was finding the libmysql.dll in MySQL\bin folder, which may be newer and incompatible with the PHP mysql extension. Adding the PHP location (C:\Program Files\PHP5 in my case) in the PATH system variable, before the MySQL\bin entry and restarting Apache web server solved the problem.