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

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….