reating event log messages is a necessity for any nontrivial application running on the NT platform. Not only is the event log Microsoft's recommended method for capturing warnings and errors, but many vendors have embraced it, and an active tools market helps you capture and analyze the event log information across multiple computers and domains. Unfortunately, working with the event log isn't as easy as it could be. In this article, I'll show you how to make writing to the event log a relatively painless experience.

Technology Toolbox VB5 or VB6, Windows NT 4.0, Windows 2000, or Whistler (beta when written) C++ or the Platform SDK (for MC.exe)

The event logs are operating system repositories that let your applications record event information. You can use these records to do a few things, such as troubleshoot problems and audit your system access. The event logs are a common, centralized repository for this type of information, and you can access them from other machines on the network easily (and just as easily protect them with standard NT security).

In 1996, I wrote two articles for Visual Basic Programmer's Journal on reading and writing to the NT event log with the then-current Visual Basic 4.0 (see Resources). Although the code still works and converts without problems into VB6, it's badly dated and in need of refactoring. In addition, the code doesn't handle multiple logs or categories. Most importantly, I didn't clearly explain the method I presented to create the message files (by the number of e-mails I received) and it required Visual C++ to compile the message files. The code for this article solves all these problems and more.

VB's built-in method to write to the event log (App.LogEvent) is rather lame and suffers from several limitations. App.LogEvent doesn't work from the IDE, the Source entry shown in the NT Event Viewer applet shows "VBRuntime" for all events using App.LogEvent, and you can't specify an EventID or Category. In addition, you can't include binary data (in the bottom section of the detail dialog under "Data"), the user is listed as "N/A," and the "Description" section includes fixed information you might not want to include and can't eliminate. In other words, the App.LogEvent probably isn't sufficient for professional applications.

Actually, writing to the event log is a rather simple, one-API call:

Private Declare Function ReportEvent _
        Lib "advapi32" Alias "ReportEventA" (ByVal _
        hEventLog As Long, ByVal wType As Long, _
        ByVal wCategory As Long, ByVal dwEventID As Long, _
        ByVal lpUserSid As Long, ByVal wNumStrings As Long, _
        ByVal dwDataSize As Long, lpStrings As Any, _
        lpRawData As Any) As Long

The problem is all the setup work you need to do before making this simple call.

?	Take Control of the Event Log

In this Article
Introduction	Categorize Them All
Take Control of the Event Log	Write an Entry Successfully