Introduction to the EventLog Component
Event logging in Microsoft Windows provides a standard, centralized way for you to have your applications record important software and hardware events. When an error occurs, the system administrator or support technicians must determine what caused the error, attempt to recover any lost data, and prevent the error from recurring. It is helpful if applications, the operating system, and other system services record important events such as low-memory conditions or failed attempts to access a disk. The system administrator can use the event log to help determine what conditions caused the error and the context in which it occurred.
Windows supplies a standard user interface for viewing these event logs and a programming interface for examining log entries. In Microsoft Visual Basic version 6.0, you could perform limited write operations to some event logs, but you could not easily read or interact with all the logs available to you.
Using the EventLog component, you can easily connect to event logs on both local and remote computers and write entries to these logs. You can also read entries from existing logs and create your own custom event logs
In addition to writing to event logs and reading their entries, you can use Server Explorer to view a list of the event logs for any server to which you have access. You can expand the Event Logs node in Server Explorer to see a list of the logs that currently exist and the events that have been written to them. You can also drag a specific event log from Server Explorer to your designer to create an instance of the EventLog component that automatically has its properties set to point to the log you selected.
Note You can also use the GetEventLogs method to retrieve a list of all event logs on a machine.
Note There are security restrictions that affect your ability to use event logs. For more information, see Security Ramifications of Event Logs.
Key Concepts in Windows Event Logs
An event, as defined in Windows, is any significant occurrence — whether in the operating system or in an application — that requires users to be notified. Critical events are sent to the user in the form of an immediate message on the screen. Other event notifications are written to one of several event logs that record the information for future reference. Every event log entry is classified into one of the following categories: errors, warnings, information, success audits, or failure audits.
There are three event logs available by default on computers running Windows 2000 or Windows NT 4.0:
- a System log, which tracks events that occur on system components (for example, a problem with a driver);
- a Security log, which tracks security changes and possible breaches;
- an Application log, which tracks events that occur in a registered application.
In addition to these logs, other programs such as Active Directory may create their own default logs. You can also create your own custom logs using the language features in the System.Diagnostics namespace.
Choosing Events to Log
The following are examples of cases in which event logging can be helpful:
- Resource problems. If an application gets into a low-memory situation (caused by a code bug or inadequate memory) that degrades performance, logging a warning event when memory allocation fails might provide a clue about what went wrong.
- Information events. A server-based application (such as a database server) records a user logging on, opening a database, or starting a file transfer. The server can also log error events it encounters (cannot access file, host process disconnected, and so on), corruptions in the database, or whether a file transfer was successful.
Event logging consumes resources such as disk space and processor time. The amount of disk space that an event log requires and the overhead for an application that logs events depend on how much information you choose to log. Therefore, it is important to log only essential information. It is also best to place event log calls in an error path in the code rather than in the main code path, so as not to reduce performance.