Using the event log in your driver

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 or other control so these can be disabled.


The second problem, lazy definitions, happens because building the message catalog where the event strings are stored and setting up the registry for it require additional steps.  Developers looked around and found that a number of the common Microsoft error codes took a string for the log entry, and decided to use the Microsoft definition instead of their own.  This is a poor approach for two reasons.  First, since all your errors are coded as the same event, this makes it hard for tools to look for problems in the log.  Second, the event log is designed for internationalization but the strings you dump from your driver will all be in one language.


For internationalization, consider making the message catalog where the text of the messages resides a separate file, rather than including it in the device driver.  The advantage of this is that you can provide the components needed for a support organization to add a new language without having to sign the driver again. 


So what should go in the event log?  Some obvious things are:


·         Failures in DriverEntry, AddDevice and Unload – In all these cases, there is no user request to which to report the problem.


·         Resource failures – These include a malfunction in the hardware or supporting software (for instance, a service that supports the driver) that impacts many requests.


·         Anomalous behavior – This is anything that is unexpected, whether it fails a request or not.  If something you really didn’t expect occurs, even if the driver handles it, log it.


My overall message is that you should add the event log to the diagnostic capabilities you provide your support people and your customers. If you already do this, great!  And if you already have working guidelines for event log use, please share them with a comment to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>