n the September issue of Visual Studio Magazine, I showed you how to write to an NT event log, which is a general need for almost all 32-bit programs running on NT. Reading from those logs programmatically, as opposed to using the EventLog applet to view them interactively, is a more specialized need usually reserved for administrative-type programs. For example, you might want to check for error messages for a component you've written that's running on three different servers and either raise an alert or log this information to a logging console in the computer room. Or, you might want to do a post-mortem analysis of errors that occurred on a particular application running on one or more machines.

Technology Toolbox: VB6, VB5, Windows NT 4.0, Windows 2000, or Windows XP (beta when written)

You could use the EventLog applet to accomplish these tasks manually, or you could purchase a third-party tool to automate the process. But if you want a simple way to read event log records programmatically from a local or remote computer and optionally filter those records, this project fits the bill. What you do with this information (raising alerts, logging to a console, and so on) is left to your discretion.

In 1996, I wrote an article that allowed you to read the NT event logs programmatically. The VB4 code was slow, unnecessarily convoluted, and needed refactoring. I've solved these problems with this article's code project, which includes an ActiveX DLL (ReadEventLogs2) with the code to retrieve and filter the event log records, and a testframe UI (TestEventLog2.exe) that not only tests the code in the DLL, but also allows you to filter the records once you retrieve them from the event log. (Download the project)

I wrote the filtering code in a BAS file, which is included within both the DLL and EXE. You can filter the records when reading them, which saves time, because you get only enough information to determine whether the record meets the filter requirements, and if it doesn't, it skips the more expensive conversions. Or, you can bring back all the records and filter them for display. Filtering the records in the UI is more flexible because you don't have to re-read the log every time you want to try a new filter. However, it takes longer to return the records, and the system can add new records to the event log while you're filtering. The type of application you're writing will determine the method you need to use. However, it's confusing to filter the records in both places, so I don't allow it in the code.

Unfortunately, the EventLog applet isn't an ActiveX component, so you can't automate it. You can use the NotifyChangeEventLog API call to learn when an event is written to a given event log, but you still must use code similar to this project's code to read the log entry and discover whether you need to take any actions. Note that in NT 4.0, you might not receive event notification for a particular log if the system is writing to the other logs simultaneously (see the Knowledge Base article). If you have Windows 2000 or later, you might want to look at using Windows Management Instrumentation (WMI) to administer and read NT event logs.

?	Open the Event Log

In this Article
Introduction	Deal With the Little Details
Open the Event Log	Merge the Replacement Strings