3390

When I get a new client, I ask for a copy of their driver coding guidelines.   Typically I get one of several responses. ·         We trust our developers to do the right thing. ·         The last time we brought this up there was almost open revolt. ·         They hand me a corporate standard for coding applications, most of which is worthless for drivers. Whether companies recognize it or not, they need a set of coding guidelines for drivers.  There are a lot of ways of doing things in drivers that can cause problems, and a good set of guidelines can … Continue reading Coding Guidelines

I’ve been spending the last couple of days tracking down a bug in a driver I am writing. The effort reminded me of how great tags on memory allocations and frees can be. Also, the work reminded me that there are at least a couple of features Microsoft does not promote and I rarely see. For the uninitiated, tags are a four character value that is passed as an argument in memory allocation calls. The tag gives you a way to identify what the memory was allocated for by having a different tag for each common structure allocated. Here is … Continue reading Tag, you’re it

As a consultant who has more than once taken on projects Microsoft has said are impossible, many people assume I often use undocumented calls in Windows in my work.  In fact, I try to avoid them if at all possible, and am extremely careful in crossing the undocumented line. A developer should ask a set of questions when considering using an undocumented technique; these are: Is it really needed?  Before anything else, ask yourself if there is any other way to do this.  Be sure to not constrain your design when you ask this question.  For instance, requiring something be … Continue reading Crossing the Undocumented Line

I wrote previously that drivers should use the event log.   This time I am going to give some things to consider when using events. The challenge for using the event log is that many components use it poorly.  The two common problems are superfluous messages and lazy definitions.  The event log is commonly configured as a circular log with a limited capacity.  Thus, having a bunch of superfluous messages can cause the important events that lead up to a failure to be lost. If you want to put in things like the driver started or stopped, provide a registry value … Continue reading Using the event log in your driver

Do you use the event log in your driver?  Event logging should be standard in almost every driver, yet few drivers support logging.  Event logging is the place to record anomalous conditions and events that are detected by your code. Specifically, it is the recognized way to report errors that are not related to a particular request to the device.  The event log consists of small records about events of interest.  The record is based on an NTSTATUS code, whether it is a standard code or a custom status code for your software.  Think of the event log as a … Continue reading Why your driver should use the event log