New VS15.8 Feature Breaks WDK 1803 (with Workaround)

Continual Updates: Love Them or Hate Them?  Either Way, Peter Rants

It is difficult for me to convey how very much I *dislike* having both my tools and my operating system continually updated. It’s not that I don’t like new features. Heck, I’m positively a whore for new features: Whoooaaa! You can do @ mentions in Outlook now?  Sign Me Up!  Some new feature causes Outlook to hang once in a while?  Yeah, well, perhaps annoying, but whatever.  That’s why Task Manager was invented, right?  To allow you to restart stupid hung applications.

So, yeah.  I understand, maybe I even sometimes enjoy, flighted features.  Updates every few days to O365 seem, you know, amusing.  Almost fun.

But my amusement at getting continuous updates is not unbounded.  Stuff that provides infrastructure, like my operating system and the tool chain by which I earn my bread?  I expect, no I *need* that stuff to just work.  I become positively intemperate when Windows Explorer hangs (like it seems to do regularly these days), or… when one of the endless updates to Visual Studio breaks the WDK and causes my work to come to an abrupt halt.

Which is what happened yesterday.  The WDK stopped working.

And as one particularly obnoxious ex-boss of mine used to say “This does not make me happy.”

VS V15.8 Default Setting Breaks the WDK

All right, I’ll get to the point.  Yesterday afternoon (Wednesday 15 August), the team here at OSR started getting the latest in the seemingly daily demands to update Visual Studio.

Heck, I had already read the Visual Studio Blog post from the day before extolling the virtues and new features available in VS 15.8.

One of the devs here happened to be installing a new system, so downloaded the latest VS installer and got V15.8 — I, being a sucker for trying to keep the little illuminated flag in the VS header NOT illuminated at all times, almost simultaneously downloaded the update.  Which required me to reboot my system.  No, I’m not kidding.  But I digress.

The thrill that awaited both of us was the fact that when either of us tried to build the Debug build of a driver, we got an error message from the linker:

error LNK2001: unresolved external symbol __CheckForDebuggerJustMyCode

You can see the same wondrousness in Figure 1.

Apparently, one of the new features in VS 15.8 is that it allows you to single-step in the debugger and automagically jump over calls to library code or RTL stuff.  I’m sure this is a very worthy feature.  To somebody.  Maybe to user-mode devs, or to people who can’t tell the difference between F10 and F11?  Anyhow… I’m sure it’s a good feature that somebody somewhere wants. My simple question is: Why did they turn it on by default?

If the person who did this worked for me, they would be fired.  You don’t enable brand new features such as this, that involve utilizing entirely new linker switches, on by default in their first release.  You ship it, off by default, and let people play with it a while.  You think-through the consequences of the change.  Maybe, then, after a while, you turn it on by default… because you’ve been overwhelmed by all the praise that you’ve gotten for bringing such goodness to the world and by the annoyance that people express with their needing to constantly enable it themselves.

Why do I care if the /JMC parameter, which I don’t even care about, is on by default?

I care because enabling /JMC changes the way a project is linked.  So, on Monday my project was linked one way, and on Tuesday afternoon my project is now linked a different way.  That’s not nice.

Plus… enabling it breaks building drivers.  Fortunately, the fix is simple.

The Simple Fix

Thankfully, fixing the mess and getting back to driver writing is easy.  Just go to the “Tools” menu item and select “Options…”  — In the Options dialog select “Debugging” and then “General” and then UNCHECK “Enable Just My Code”

And now you’ll be able to build drivers again.

Seeing this problem in a released version of Visual Studio (remember, we’re not talking about a preview release here) does beg the question:  Doesn’t anybody test this stuff?  Are we, the Windows third-party driver development community, the first people to use new version of these tools to build drivers?  If so, dude… that’s scary.  Really scary.

How hard would it have been to test this?  And what other changes are lurking in the bowels of the latest VS release that we don’t know about yet?  And what potential incompatibilities might these changes bring, when building a driver and loading it on an OS that was built with an entirely different set of tools?

I don’t know about you… but “this does not make me happy.”