Careful With Your WDK Updates!

I can never help myself when it comes to updating to the latest WDK. It’s always exciting to diff the old contents with the new and see what’s really going on in the operating system. And not since the XP DDK have I ever had a problem jumping on the bandwagon early (except that one time I installed a Vista Beta WDK on my workstation…shudder…).

This all came a bit crashing down on me yesterday when I decided to install the latest WDK in the middle of a software release. Yes, I know, I get what I deserve. But it’s never been a problem and I needed a distraction from doing real work.

Install went just fine for me, but then I quickly hit the wall because of the new Code Analysis enforcement on NX NonPaged pool. I’m all for the check, but I need Win7 support and the new WDK also breaks the POOL_NX_OPTIN option.

I was, shall we say, a bit annoyed at this point because I could no longer build my code at my desk. Again I accept some responsibility for this, but it didn’t make it hurt any less.

Then I had huge sigh of relief: the WDK supports side by side installs! My project was set to automatically use the latest tools, but my salvation was to simply change back to the 10586 build environment:

Very pleased with myself, I victoriously fired off the build…which failed due to a linker error:

LINK : fatal error LNK1181: cannot open input file 
'C:\Program Files (x86)\Windows Kits\10\lib\10.0.10586.0\km\x64\\cfg_support_v1.lib'

Boo! What was that??

Looking for references to cfg_support_v1.lib, I discovered that the build\WindowsDriver.Common.targets file had been updated to add a dependency on this library.

The WindowsDriver.Common.targets file with the original 10586 WDK did not contain this reference and, of course, cfg_support_v1.lib did not exist in the 10586 WDK. What this means is that the headers and libraries of multiple WDKs may exist side by side, but there is only one copy of the build control files. This opens us up to situations like this where the build control files diverge and bad things happen.

At this point I decided I had wasted too much time already and promptly uninstalled the 14393 WDK. At least this would allow me to postpone the fight to another week that might be, ahem, more appropriate.

Of course, after uninstalling I discovered that the 14393 build control files were not reverted to their previous copies. So, WindowsDriver.Common.Targets still contains a reference to the missing library and my code still does not build. I then tried a repair of the 10586 WDK, which told me that I already had a newer version installed.

I then had my next sigh of relief: I’ll just build in the Enterprise WDK! Nope:

c:\winddk\10586\program files\windows kits\10\include\10.0.10586.0\km\wdm.h(17356): warning C28104: The FloatState that should have been acquired before function exit was not acquired.   
c:\winddk\10586\program files\windows kits\10\include\10.0.10586.0\km\wdm.h(17374): warning C28103: Leaking the FloatState stored in '*FloatSave'. 
c:\winddk\10586\program files\windows kits\10\include\10.0.10586.0\km\wdm.h(17374): warning C28103: Leaking the FloatState stored in '*FloatSave'.

Now I feel cursed.

After spending more time on this, I discovered that as part of configuring Code Analysis on each build Visual Studio set the EnablePREfast item in my vcxproj files in addition to RunCodeAnalysis.

The EWDK doesn’t support Code Analysis, which should be fine, but having the EnablePREfast item set in your vcxproj causes some sort of unfortunate accident in the build settings. This leads to suppressed warnings in wdm.h somehow leaking out as real warnings in the build. This has nothing to do with the new WDK and just something that I happened to stumble upon yesterday. Lucky me!

And this is where I leave you…Floating between three build environments unable to move forward, back, or to the side and get back to a working environment. Stay tuned and I’ll update as necessary if issues are resolved or if we create reliable workarounds.

As I typed this I decided to start the process of updating my workstation to the Windows 10 Anniversary Update. Because, why not? I’m in the middle of a software release and nothing could possibly go wrong…