Why your driver should use the event log
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 series of alerts to inform you of what is happening on the system. If you haven’t looked at it lately, open the event viewer from Administrative Tools, and look at the entries since the last boot of your machine.
There are articles for developers that contend that no one reads the event log. Yes, the normal user does not look at it, but system administrators certainly do. When there is a problem with a system, the event log is the first place admins will look to establish a chronology of what happened and possibly see what failed. The event log is also integrated into many network management tools that administrators use to monitor system health.
So why don’t more drivers use the event log? Part of the reason for this is Microsoft. The DDK used to provide a specific sample to illustrate logging, but this was removed years ago. Worse, some Microsoft developers do not understand the use of the event log. A few years ago a Microsoft talk confused the purpose of Event Logging with the more recent Event Tracing for Windows (ETW). ETW is a great capability, but it is designed to provide detailed diagnostics for the developer, not simple alerts for the administrator.
So if you are not using the event log in your drivers, ask yourself or your developers, why aren’t you? If you are using the event log, there are a number of things to consider, but that needs to wait for another post.