Archive for May, 2010


Thursday, May 27th, 2010

I ran into a problem yesterday that took a few hours to decipher. I thought I’d share it here, in case Google manages to lead someone with a similar problem this way.

I made a minor change to a DLL in a program I’ve been working on and distributed it to the end users. The user that had requested the fix was happy with the result, and everything was fine for a couple of hours. Then I received an email from another user complaining the program was failing to load, reporting the error

System.IO.FileLoadException: Could not load file or assembly 'MyLIB, Version=1.0.3798.19982, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

I’d seen this type of error before; typically it means MyLIB.dll requires another DLL that isn’t present. I checked his program folder, but everything was present – no missing DLLs. Tried re-patching and tried re-installing, and still no luck. I ran the dependency walker to see exactly what it was that it was missing. Turns out to be MSVCR80.DLL, MSVCM80.DLL and MSVCP80.DLL – the MS Visual C++ runtime.

Wait, what?

That didn’t make any sense, as he’d had the program running happily a few hours before. I tried re-installing the runtime, but that didn’t seem to help. Much scratching of heads and gnashing of teeth followed.

It turns out that the new build of MyLIB.DLL that I’d built had tied itself to the specific runtime version I had on my PC – 8.0.50727.4053. These runtime DLLs were installing into C:\Windows\WinSxS, where different versions of the same DLLs live side by side in an uneasy truce. I don’t pretend to fully understand what’s going on in there, but anyway. The different versions of runtimes were in different subfolders, the names of which contained the version number. When we checked the machine that the program was failing to run on, the .4053 version wasn’t there. We had to find that specific C++ redistributable version on as install it, which fixed the problem. The version of the runtime I had tried reinstalling earlier was an older version. It was then I realized that I have a new PC, and this is the first time I’ve rebuilt that particular DLL on this machine. Those with older machines were less likely to have the newer runtime installed.

Many sources on the interwebbings were simply saying “get the dll from here, and stick it in your Windows\System32 directory”. This is exactly wrong in this instance.

It would be nice if I could find an option in the project build configuration that says “Use runtime version X or later”, rather than it requiring the specific version it finds on my machine.