Developing Device Drivers in Studio 11

Another piece of great news delivered at //build/ has to do with device driver development. Coincidentally, a few weeks ago I posted a series of baby-steps with Windows driver development, and if you’ve read some of that you’d notice that the driver dev work is very different from application development – you use a different build environment, you deploy drivers manually, and you debug them with a different debugger.

This story changes, however, with Visual Studio 11. You can now build drivers in Visual Studio, deploy them to test machines automatically, and debug (in kernel-mode!) using the Visual Studio debugger tool windows and source code debugging support.

First things first – you can create driver projects in Visual Studio using the WDK templates. Even if you don’t want the templates, you can create an empty driver, add your files to it, and then compile it:

By the way, if you want to convert an existing driver, there’s a new option File | Convert Sources which will convert your SOURCES file to a Visual Studio solution. I just tried it out with a simple driver, and sure enough Visual Studio created for me a solution, imported my files, and I was able to compile the driver successfully.

Next, you are probably going to debug your driver. Well, you can hit F5 and Visual Studio will ask you how to deploy your driver to a remote machine and how to connect to it for debugging purposes:

For this magic to work, you need several things to snap into place:

1. On the target machine, you need to disable UAC completely – using the EnableLUA registry key is the safest way to go, and you need to use a local user account (not a domain or LiveID account).
2. On the host machine, you need to run Visual Studio elevated during the configuration process.
3. On the host machine, you need to run Visual Studio not elevated when doing the actual debugging.

I hope these are all temporary problems that will be resolved in the final release. At least the elevated-and-then-not-elevated part :-)

But there’s something else you can do even if the automatic deployment doesn’t work out. You can deploy the driver manually and then attach the debugger to the machine. Visual Studio will recognize the symbols and the sources and provide a seamless debugging experience for your kernel-mode code.

So let’s get started. First, in the Tools | Attach to Process dialog we choose the “Windows Kernel Mode Debugger” transport and specify the machine name as a qualifier. In the Find… dialog you can specify the kernel connection details – a simulated serial port in my case connecting to a VMWare virtual machine.

 
(click the screenshot to enlarge)

After attaching, we can break into the debugger and configure breakpoints and whatnot. The Visual Studio call stack window and source code window are fully functional, but there’s also the Debugger Immediate Window where you can use all the kernel debugger commands from a command line interface. Here’s a screenshot of me stepping through the DriverUnload callback in Visual Studio – note the Locals and Call Stack windows, fully functional:

 
(click the screenshot to enlarge)

To top it off, Windows 8 features two new debugging transports – USB 3.0 transport, which isn’t all that exciting if it weren’t for the speed and the fact you can use a standard USB cable; and the network transport, which uses the standard network connection to perform kernel debugging. Unfortunately, you need both the host and the target to run Windows 8 for these new transports to work.

This doesn’t even scratch the surface of what beholds driver developers in Windows 8 and Visual Studio 11. Whether you’re doing kernel dump analysis or active driver development, the next Visual Studio is going to help, a lot. I can finally stop explaining in my Windows Internals courses what Visual Studio cannot do, and start showing what it can do.