uuid.lib(unknwn_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module

| 5 Comments

Back in October 2005 some of my clients started to complain that the latest version of the Platform SDK (the April 2005 version) broke their builds. The culprit was uuid.lib which had been built with debugging information that the VC6 linker didn't understand and which caused a link failure. The end result was that the last version of the Platform SDK that worked with VC6 was the February 2003 version. This all seemed quite unnecessary to me at the time; as if the latest Platform SDK was deliberately unusable for VC6 which had (in September 2005) just become unsupported.

Well, it's happening again... With version 7.0 of the Windows SDK, uuid.lib now gives a similar error when used with Visual Studio 2005.

Of course I may be doing something wrong, but...

Either the v7.0 Windows SDK was never tested with Visual Studio 2005 building applications that need to link with (at least) uuid.lib or it's considered OK for this version of the Windows SDK to explicitly not support this compiler; in fact, if this is the case then it's considered OK for this version of the Windows SDK to only support VS2008 (VS2010 isn't in production yet).

This isn't the only way that Platform/Windows SDKs have been made incompatible with versions of the compiler. VS2005 included sal.h in its compiler header directory and versions of the Platform SDK after VS2005 used sal.h but didn't include it themselves. This meant that these versions of the Platform SDK no longer supported VC6, VS.Net (2002) and VS2003. Simply copying sal.h into the old compiler's include directories fixed this... Then there was the _WSPIAPI_COUNTOF macro change. Version 6.0a or later of the Windows SDK use a new version of _WSPIAPI_COUNTOF which is a bit more clever and templatey than the old version. As such it fails on compilers before VS2005. The new version is no more functional than the old as can be seen by the fact that you can test for the compiler version and the SDK version and simply define the old version and everything works fine...

IMHO, this kind of thing doesn't encourage people to move from one version of the compiler to another. There are lots of reasons that people can't always use the latest and greatest version of the compiler. It simply means that some people wont use the latest version of the SDK and therefore, if anything, it slows the move towards using the latest features in the operating system. Of course some people, like me, are too stubborn to let this kind of rubbish put me off and we've been supporting most compilers with most SDKs well past their best before dates; we have to, our clients demand it.

So, if uuid.lib (and, of course, whatever other libs that may have been recompiled with incompatible debug information present) really needed features from the new linker and Visual Studio is supported then I guess a hotfix for the VS2005 linker will become available... Alternatively the Windows SDK could ship a new linker in its bin directory in the same way that it ships new versions of MIDL, etc. Either way there's no reason that I can think of that this problem should exist except for making it harder to build software for Windows 7 with Visual Studio 2005...

Luckily, for now, the fix is pretty easy. You can use the version of uuid.lib that comes with v6.1 of the Windows SDK for Visual 2005 builds and, if you find that you need some new GUIDs that happen to be included in the v7.0 version you can always define them yourself. It will be interesting to see if there are other libs that are incompatible.

Later... interestingly it seems that the linkers supplied with VS.Net (2002) and VS2003 work fine with the new uuid.lib file... It's only VS2005 that seems to have problems...

Later... seems like this http://support.microsoft.com/default.aspx?scid=kb;en-us;969443&sd=rss&spid=3041 hotfix may fix things...

Even later... Thanks to a comment by Soo Wei Tan, it seems that this http://support.microsoft.com/kb/949009 is the hotfix that you need....

5 Comments

Add to that the recent hotfixes to the ATL/MFC/CRT libraries, not to mention Visual Studio Service Packs which come with new CRT versions.

It's almost impossible to maintain multiple releases of software from a single machine.

It'd be nice if they'd allowed a target version, so you could build apps and libraries to a specific library version.

Of course, that would make a veritable maintenance nightmare for Microsoft, but... well... rather them than me :-)

Yes, it's hard.

I have my build machines set to not take updates. At least I then have a chance to work out why tests suddenly break.

Thinking back, I didn't get any build breaks with the beta Win 7 SDK and the lib in that is the same as the RTM SDK. Since then the build machine has had all the latest VS2005 updates as I did a complete upto date windows update run before I upgraded it to Win 7...

I expect I have a pre updates VM somewhere so I could narrow this down a little further if I had the time...

The only way is to have everything under version control; all tools, libs, sdks the lot. It's non trivial though. I expect making it possible to run a VS installation from anywhere on disk with no registry access would be a start. At least I could then pull the whole of the compile environment out of version control before a build... You'd then have to be able to apply all fixes and updates to a specific instance of a VS installation; so they'd affect the installation that was rooted at the directory in which you ran the service pack/update exe...

That would mean that it was at least possible to build on one machine against various service pack levels of a compile environment....

I think the proper hotfix is actually this one:
http://support.microsoft.com/kb/949009/ .

It specifically addresses the issue of libraries built with VS2008 but being built with VS2005 SP1.

Soo Wei Tan,

Thanks for the link! That does indeed appear to fix things!

Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you.

:)

Leave a comment