It is common for applications to write to the Windows Event Log when errors occur or a warning is issued, and with the advent of the .NET Framework, Microsoft has provided developers with built-in functionality to read and write data to or from the event log. In this How do I... blog post, Zach Smith shows you how to use this functionality to send e-mail alerts when errors are written to the event log.
Accessing the event log
The first step to this solution is simply having access to the event log. Event logs are named entities and are accessed based on the name. For instance, your computer probably already has event logs named Application, System, and Security. These are the default logs that are included with Windows; however, custom logs can also be created. We will use the Application log as an example.The .NET Framework contains an object called EventLog in the System.Diagnostics namespace. This object is responsible for our communication to / from a given event log. For example, to instantiate an EventLog object that represents the Application event log, we would simply write the code in Listing A.
EventLog log = new EventLog("Application");At this point, we will have access to read the event log via the Entries property on the EventLog object. To write to the event log, you must set the Source property of the EventLog object. For instance, if your source is the Order application, you would write the code in Listing B.
EventLog log = new EventLog("Application");
log.Source = "Order Application";log.WriteEntry("My event log entry");
That code simply writes an entry to the Application log with the specified source and message text. It is important to set the source. If you don't, you will get an exception stating that no source has been specified. Since this article is specifically about sending e-mails when errors are sent to the event log I won't spend anymore time on the basics of EventLogs — if you need more information, visit the MSDN Library.
Sending e-mails when errors are written
The event log is great, but the information contained in it is useless unless you manually go to the log and look at the entries. It would be nice if you were able to get some kind of notification when entries are written. That's where the EventLog.EntryWritten event comes into play. By subscribing to this event, we can trigger certain actions to occur based on the event type and other variables.We will use the EntryWritten event to trigger an e-mail to be sent when errors are written to the event log. To do this, we must first subscribe to the EntryWritten event as shown in Listing C.
log.EntryWritten += new EntryWrittenEventHandler(log_EntryWritten);This subscribes to the event, but the event will never be raised unless we set EnableRaisingEvents to true on the EventLog object. (Listing D)
log.EnableRaisingEvents = true;Now that the event is subscribed to and enabled, we need to write the event handler. (Listing E) This is where we will examine the entry to determine whether or not it is an error and decide what to do with it.
void log_EntryWritten(object sender, EntryWrittenEventArgs e)
//Get a reference to the entry.
EventLogEntry entry = e.Entry;
//If this entry is an error, send an e-mail.
if (entry.EntryType == EventLogEntryType.Error)
//Setup the mail message.
MailMessage mail = new MailMessage(this.txtE-mailAddress.Text,
//Set the body/subject of the MailMessage
mail.Body = entry.Message;
mail.Subject = "EventLog Error From: " + entry.Source;
//Setup the SMTP client.
SmtpClient mailClient = new SmtpClient(this.txtE-mailServer.Text);
//Send the mail using the SMTP client.
The code above examines the EventLogEntry.EntryType property and, if this EntryType is Error, we continue on and send an e-mail using the MailMessage and SmtpClient classes found in the System.Mail namespace. As you can see, this is all very straightforward code, just simple .NET Framework functionality.
The EntryWritten event can be used for other tasks — for example, you could catch each entry to the event log and send it to a message queue for helpdesk processing. It would even be possible to collect entries from many event logs, determine the severity of the entry, and forward those entries, based on severity, to other event logs. This would effectively be an event log router.
A couple points to keep in mind about event logsSecurity: Different logs can have different security levels. If you plan to run code such as this from a Windows service, you must ensure that the user the service is running under has access to the event log you are monitoring. Duplicate errors: There could be instances where the same application is throwing the same error to the event log on a continuing basis. If you plan to use this code in production, you will need to come up with logic to prevent your e-mail address from getting flooded with alerts. You could accomplish this by sending an alert only if the specified source (EventLogEntry.Source property) hasn't had an error for a specified period of time.
With the .NET Framework, Microsoft has given developers easy access to a wealth of possibilities in regard to custom event log handling — all that's left is for you to start exploiting this potential.