I'll give up...
On This Page
 | Don Burn: ...the checked build of Windows when they pry it from my cold dead workstation. |
| Stephan Wolf: ...being a device driver pro. |
Don Burn: ...the checked build of Windows when they pry it from my cold dead workstation.
The checked build of Windows is the Rodney Dangerfield of Redmond, "It don't get no respect," even from many people in Microsoft. To illustrate this, install the checked build on a system and there is a good chance you will assert in a popular Ethernet card's NDIS miniport driver. This bug has been there for many years, but since running clean on a checked build is not required by WHQL, the bug has not been fixed.
Even many people who use it will argue that they do not need all of it, and use tricks to install only the HAL and kernel from the checked build. Yes, using the partial checked build can be a useful technique, but the user is missing much of the power of the system.
Nonetheless, the checked build is one of the most powerful tools available to a developer. First, there are thousands of ASSERT statements in Windows that will only be active with the checked build. The driver verifier does not test most of these assertions so you need the checked build. If a piece of software (be it a driver or an application) cannot run cleanly through all these assertions, then something is wrong. In my last ten years working with Windows, every major vendor I have encountered has shipped system software that fails assertions on the checked build. Imagine how reliable things would be if all these asserts had been fixed before shipment.
Assertions are only one reason to use the checked build. Just as important is the large amount of debug information that the checked build can display. Microsoft has an excellent knowledge base article Howto: Enable Verbose Debug Tracing in Various Drivers and Subsystems that shows how to get debug prints that will help diagnose many problems. Almost all of this information requires the checked build since it uses DbgPrintEx. Even the knowledge base article does not tell the whole story: look up DPFLTR_TYPE in the wdm.h or ntddk.h and you will find that there are 93 different component Id's whose diagnostic prints can be enabled.
So grab a copy of the checked build, and use it fully before you ship a product. Consider complaining the next time you can't get the checked build of a beta drop from Microsoft. Finally, if you hit an assertion in another vendor's product, file a bug. In the end, the system you make more reliable may be your own.
Stephan Wolf: ...being a device driver pro.
All I basically need to develop a device driver is the Windows DDK, any ASCII text editor, and the WinDbg debugger.
Although that works, there are many things that make life much easier and I probably won't actually write any drivers no more without any of the following:
DebugView from SysInternals 
At certain stages of driver development, I don't want to or even cannot use the mighty WinDbg debugger, which needs to run on a separate machine. All I often need is some state information from the driver. DebugView makes all the DbgPrint() calls of my driver visible on the same machine.
Hint: Also take a look at all the other utilities by SysInternals.
More Info in Device Manager
Device Manager lists all present devices. An easy way to start DevMan is via the command line:
start devmgmt.msc
A right-click on a listed device and then on "Properties" shows a lot of information. Even more detailed device information will be available when you enter the following on the command line:
set DEVMGR_SHOW_DETAILS=1 start devmgmt.msc
However, DevMan only lists devices currently present in the system. Here is how you can have DevMan list all devices, including those previously attached but currently not present. On the command line, enter:
set DEVMGR_SHOW_NONPRESENT_DEVICES=1 start devmgmt.msc
Then in DevMan, select "View" - "Show hidden devices." DevMan will now also show non-present devices with their symbols looking pale.
Identifying the INF of a driver
When you install a driver, Windows copies the driver's INF and renames it to OEMxx.INF, where 'xx' is an increasing number.
Now if I want to make sure Windows does not use an already installed version of my driver, I first need to delete its current INF from the system's INF directory (%SystemRoot%\inf).
The following command helps me to easily identify the OEMxx.INF file name of the driver. On the command line, enter:
driverquery /si
The driverquery command lists all drivers along with the name of their respective INF files. Note that the "/si" option is necessary for driverquery to list a driver's signature information along with the INF file name.