I take a hard look at a driver code when...
On This Page
 | Don Burn: ...I encounter practices or code that fails to take advantage of the driver environment Microsoft provides. |
| Tim Roberts: ...I see mismatched tab styles in the source code. |
Don Burn: ...I encounter practices or code that fails to take advantage of the driver environment Microsoft provides.
Two notable practices that reflect the above are: not using the standard build environment, or doing work where Windows will do it for you. Why is the standard build environment so important? The DDK build environment does many things for you. With a non-standard environment just getting the settings right is a battle. Remember that Microsoft can change compilers and settings with each DDK release. Do you really want to have to customize things every time a new DDK comes along? Worse yet, if you do not use the standard build environment, it is extremely hard to use tools such as PREfast and Call Usage Verifier. These tools are there to help you find problems in your code. Creating an environment that ignores these, or not having run the tools will cause a hard look. Once I have checked the build environment, it is time to look at the code. Many things can cause me to question the quality of a piece of code, but the biggest is not taking advantage of the environment. There are developers who believe they can do a better job than Windows for a given function. Why bother? Developing a driver is hard enough without coding things you do not have to. One of the great things about Windows kernel programming is the rich set of functions available to the developer.
A not so obvious example of the above is the use of METHOD_NEITHER or pointers in a data structure passed into a driver. There is a lot of work needed to ensure that a buffer is valid and locked down for a driver. Is the driver in the right process context? Is the buffer valid for it entire length? Is a malicious user trying to pass a buffer to cause your driver to crash? It is very rare that a little redesign of the application and the driver cannot eliminate the need for the driver to validate a buffer.
The real trick for writing code that does not require a hard look is to create code that you would feel good about seeing for the first time, or showing to others. Driver code should be clean logical and modularized to be easy to understand and update. You need to apply this to all your code, since one other flag for a hard look is, did I previously encounter lousy code from the author listed at the top of the module?
Tim Roberts: ...I see mismatched tab styles in the source code.
Although it seems trivial, mismatched indentation styles are an indication that the code has been touched by several people. It is a red flag to examine the code to make sure the subsequent modifiers actually understood what they were looking at.