Why is the type library in my dll corrupt (registering returns TYPE_E_CANTLOADLIBRARY)?

Question

We have a mature c++ COM codebase that has been building, registering and running for many years. This includes numerous developer machines and autobuild machines.

The codebase builds several dlls and exes. Some of these are COM servers.

The typical setup is Xp64 using both visual studio 2005 and 2008.

We have both 32 bit and 64bit builds.

Suddenly our xp64 2005 autobuild machine is failing. The only code change was a trivial change within a c++ helper method and an update to some version numbers.

The failure that we see is a failure to register the x64 release version of a dll.

The failure appears to be caused by a corrupt dll. The dll builds successfully but attempts to register it fail with TYPE_E_CANTLOADLIBRARY.

The dll is supposed to have the type library built in (through an include in the rc file).

This has always worked before and still works on our other machines, xp64 VS 2005 and 2008.

When inspecting the binary of the broken dll the typelibrary idl source can be seen - although it is at a different location than in a non broken version of the dll.

The broken dll fails to register on our other machines - the same machines successfully register their own local builds of the same dll.

Oleview also fails with the same error when opening the dll.

I'm looking for any suggestions or similar experiences that might help?

Answer 1

This could be as simple as the disk on the build server going bad. There's nothing in your post that suggests anything more complicated. Although it is pretty weird to see the IDL back in the DLL, type libraries are binary.

Answer 2

Well I think we have nailed this as a visual studio bug.

We found that the path where our autobuild runs had recently been changed - increasing the absolute pathname lengths of any files that the compiler generates.

We also know that 64bit release build's target folder would have the longest pathname of any of our configurations.

We have shortened the path (by renaming our top level directory under which our source tree is checked out) and the problem looks to have gone away - obviously we will repeat this a few times to make sure it isn't a fluke.

I'm thinking that when visual studio inserts absolute paths name in the binary - as it still does - it might be overunning on a buffer...and corrupting the binary.