Automating Win32 Driver Testing

Question

Does anyone know ways of partially or fully automating driver test installation?

I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.

After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?

Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.

Answer 1

Follow the advice I gave here. Basically, test as little as possible with the real system.

In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).

You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).

I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.

Answer 2

You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).

Don't forget to check your driver with DriverVerifier!

Example of my own script :)

sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter

Answer 3

It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.

I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.

One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.

Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.

Answer 4

I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.

It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.

Answer 5

It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.

But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:

... This project brings the simplicity and convenience of Windows application development to the driver development world. No more manual creation of build scripts, copying of driver files, installing drivers from INFs, switching between WinDbg and the source editor or waiting for seconds after each step due to the extra-slow virtual COM port. Just create a driver project using a convenient Driver Wizard, select a virtual machine, and enjoy debugging your driver directly from Visual Studio. Want to test a change? Just normally press Shift-F5, modify your driver, rebuild it and launch again. VisualDDK will unload the old driver, install the new one and load it automatically and quickly. Bored with WinDbg loading symbol files for minutes and looking up symbols for seconds? Just let VisualDDK optimize this for you using its own DIA-based symbol engine. Using C++/STLPort in your drivers? VisualDDK will natively visualize all STL containers and strings, as good as Visual Studio does for user-mode applications. ...