To complement the article, Five Things to Like About Visual Studio Integration, we decided it would also be good to take a more critical view of the new environment. In doing so, we’ve put together a list of five things that we’re not so excited about with the new WDK.

While putting together this list, we’ve tried to avoid things that are general to VS and not specific to the WDK integration. So, please don’t take this article to mean that we actually like the VS editor or that we couldn’t come up with a zillion things that we didn’t like about it. I mean, is there seriously no way to add a column marker without a crazy registry hack that no longer appears to work?

1. What Works for Drivers and What Doesn’t?

While the WDK integration adds a few new driver-specific menu items to VS, it currently doesn’t remove any menu items that aren’t applicable to drivers. This quickly leads to frustration as you’ll find yourself getting excited for some new tool that’s going to improve your driver but, alas, isn’t supported.

Code Metrics? Not for drivers. Code Coverage? Nope. Error Lookup?? Doesn’t support NTSTATUS values. Right now it doesn’t appear as though we’ll be getting any of VS’ modern development features supported for drivers, though I’m really hoping that changes. If not, why bother having all of this stuff cluttering up my menus?

2. No Support for Building XP Drivers

It’s been argued to death on NTDEV, but it’s worth mentioning again: no support for XP as a target build platform. With XP not at End of Life until 2014, most of us are going to be stuck supporting XP targets for years to come. Without official support for XP, this could possibly mean maintaining two entirely different build environments or holding off on adopting the new build environment.

Here at OSR we’re planning on supporting two different build environments for our kits and drivers. While changes to the build files are typically rare in an existing project, this does increase our test matrix as we’re not going to ship what we don’t test.

3. It’s WinDBG in Visual Studio! Oh, wait…

After running a few of your favorite WinDBG commands, you may be lulled into thinking that you are, in fact, still in WinDBG. You have to remember though that this is VS with a KD plugin, so things don’t exactly map one-to-one.

For example, VS currently doesn’t appear to support the Debugger Markup Language (DML). Hopefully this will be fixed in the future because I’ve gotten quite used to clicking !analyze –v when the system crashes, and we have internal tools here that rely heavily on DML. Another thing that I’m missing already is the ability to right click text to send it to the clipboard and then right click again to paste it to the command line. I never quite realized how often I used this until I started debugging an issue inside VS.

4. Visual Studio is SO a User Mode IDE

As driver writers, we live in a different world than application developers. Take, for example, a case where you’re working on some new code and want to step through it to make sure you have your logic right (please don’t send us flame mail about whether or not “good” developers need to step through code!). If you’re developing a user application, you add some code, hit F5 to run it under the VS debugger, and step through your code until you’re satisfied. You then end the debug session and start working on your next piece of code.

Compare this to what happens when you’re a driver developer. In this case, you already have an instance of WinDBG running and attached to the target machine. In your separate build environment, you build your driver and then copy it over to the target. You then perform some manual action on the target to load the new driver, possibly rebooting or just disabling/enabling a device. When your new driver loads, you set some breakpoints and step through the code. Once you’re satisfied, you leave your debug session intact and move back to your editor so that you can repeat the process.

Given this, what’s the issue? The trouble is that the VS IDE was created for the user application scenario, not the device driver scenario. Thus, while I’m attached to my target machine within the VS IDE, the build options are disabled. In order to build a new copy of the driver, I need to detach from the target machine, build, and then re-attach to the target machine. This is quite annoying, especially in the case where the re-attach doesn’t work, which happened to me several times while network debugging.

Hopefully this is something that’s addressed in the final release. Otherwise, we’ll likely have to have two instances of VS running or revert to using WinDBG as the kernel debugger.

5. What it Means for the Future of WinDBG

While people like to bash it, WinDBG is truly an excellent, lightweight tool for crash dump analysis. I just don’t ever see myself saying that about VS, so I’d really hate to see WinDBG fade into oblivion. Luckily it looks like we’ll have WinDBG support with us at least through this release of Windows, but the future beyond that is not clear at the moment.

What Did We Miss?

We just know that we missed your least favorite thing about the new kit, so let us know what it is!