November 28, 2014
Hot Topics:

Managed C++: Monitoring the Windows Event Log

  • December 31, 2004
  • By Tom Archer
  • Send Email »
  • More Articles »
Due to the increasing danger posed by viruses and mal/ad-ware applications, many people have downloaded, purchased, or written their own file and registry monitors. These monitors typically are written to detect malicious software that has been installed—or is being installed—on a machine by prompting warnings when applications attempt to modify the Windows registry or certain files. However, an oft-overlooked area of security is the Windows event log—specifically the security event log, where the Windows operating system and key system applications log events such as invalid logon attempts, port scans, and many other events related to the security of a system.

This article illustrates how to monitor any event log from a Windows application. You can then take the basics it covers and modify them to your particular environment and needs—such as having the application email you when the security event log records a particular event type.

Monitoring with the .NET EventLog Class

The code in this article uses the .NET 1.0/1.1 Managed C++ syntax. If you're using a newer version of .NET, you'll need to specify the /clr:oldSyntax option in the project's Project Properties dialog box or adjust the code below to conform to the new Managed C++ syntax.
The key .NET type to working with the Windows event log is the Diagnostics::EventLog class.
  1. Define a managed class that implements the event log notification handler.
    The handler (OnNewLogEntry) will be called when the "new event-log entry event" is raised. Also note that the event handler must have the same signature as the EntryWrittenEventHandler delegate. Here's an example class:
    // Example event handler managed class for 
    // monitoring new event log entries
    __gc class NewLogEntryEventHandler
    {
    public:
     NewLogEntryEventHandler() {}
    
    public:
      void OnNewLogEntry(Object* sender,
                         EntryWrittenEventArgs* e)
      {
        // Retrieve and work with the newly created entry...
        EventLogEntry* entry = e->Entry;
      }
    };
    
  2. Instantiate an EventLog object and set its EnableRaisingEvents property to true.
    The EventLog::EnableRaisingEvents property is a boolean type that controls whether or not events are raised after entries are added to the EventLog object's specified log:
    EventLog* log = new EventLog("Application");
    log->EnableRaisingEvents = true;
    
  3. Wire your event handler to the "new event log entry" event.
    First, instantiate the object that defines the event handler (NewLogEntryEventHandler, in this example) and then add its event handler method (OnNewLogEntry) to the list of event handlers for the EventLog::EntryWritten event:
    NewLogEntryEventHandler* handler = new NewLogEntryEventHandler();
    log->EntryWritten += 
      new EntryWrittenEventHandler(
        handler, 
        &NewLogEntryEventHandler::OnNewLogEntry);
    
  4. Code the event handler to your specific needs.
    Looking back at the OnNewLogEntry method, you can see that the EntryWrittenEventArgs object passed to the event handler has a member called EventLogEntry that contains the specifics regarding the recorded event. This includes the following properties:
    • MachineName—The system name of the machine on which the event was created (see the Pitfalls and Caveats section for more information on this.)
    • Source—The event source (or application) that created the event.
    • Message—The user can read this textual value in the Event Viewer that describes the record event.
    • Event Type—This value (represented by the EventLogEntryType) is an enum that represents the type of event that was recorded: Information (the default), Warning, Error, SuccessAudit, and FailureAudit.
    • Event ID—This is an application-specific number for the event.
    • Data—This value is often used to store binary information—such as a memory dump—that is related to the event.

Pitfalls and Caveats

As you can see, .NET makes subscribing to event log events extremely easy. However, you should also know of a few limitations regarding handling event log notifications:
  • You can monitor events only on the local system.
  • The .NET documentation states that there is no guarantee that every single event will be raised if a large number of events are recorded in a short span of time.
  • If you are monitoring an especially busy event log, the event will sometimes not signal immediately, resulting in a lag between the time of the event entries and then a sudden burst of notifications for the events that had been queued.

About the Author

Tom Archer owns his own training company, Archer Consulting Group, which specializes in educating and mentoring .NET programmers and providing project management consulting. If you would like to find out how the Archer Consulting Group can help you reduce development costs, get your software to market faster, and increase product revenue, contact Tom through his Web site.






Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel