 |
Search
IT Courses |
|
|
|
|
|
|
|
|
|
|
|
IT
dart News Letter
|
Get
ITdart.com weekly headlines before it's published on our site! Subscribe
and receive the articles delivered to your inbox!
|
|
|
Logging events to the Windows NT event log from Visual Basic
Why log events to the event log?
Each application needs to handle errors and abnormal conditions. Information about these events is typically written to a log file that is specific to the application. This method provides the developer with a summary of abnormal conditions that occur at runtime. This information can be used for troubleshooting or for debugging the application.
The problem arises when there are many applications to manage. Each application writes its own log, making troubleshooting more difficult. In addition, if there is a chain of abnormal events across applications where one application's failure led to another, it is almost impossible to correlate the chronology of error occurrence if you have separate log files.
Another problem is that of standardising the information stored in the event log. As a different developer may have written each application, the information that the developers have chosen to keep in the log is quite unpredictable. Thus even if you have an event log, it is still difficult to find uniform content.
To solve all these problems, the Event Viewer was included in Windows NT. The idea is to use a standard method of logging application-specific information, warnings and errors to a central storage with well-documented content. In order to provide this functionality, a set of API calls was included in the Windows SDK for logging events and event details.
VB4 required you to use complicated API calls for event logging. From VB5 onwards, there are a set of functions available for logging events directly from your application into the Event Viewer of Windows NT.
Types of events
Windows NT defines five types of events that can be logged. All event classifications have well-defined common data and can optionally include event-specific data. The application indicates the event type when it reports an event. Each event must be of a single type. The Event Viewer uses this type to determine which icon to display in the list view of the log.
Event type & description:
Information: Information events indicate infrequent but significant successful operations. For example, when Microsoft SQL Server successfully loads, it may be appropriate to log an information event stating that "SQL Server has started." Note that while this is appropriate behaviour for major server services, it is generally inappropriate for a desktop application (Excel, for example) to log an event each time it starts.
Warning: Warning events indicate problems that are not immediately significant, but that may indicate conditions that could cause future problems. If an application can recover from an event without loss of functionality or data, it can classify the event as a warning event.
Error: Error events indicate significant problems that the user should know about. Error events usually indicate a loss of functionality or data.
Success audit: Success audit events are security events that occur when an audited access attempt is successful. For example, a successful logon attempt is a success audit event.
Failure audit: Failure audit events are security events that occur when an audited access attempt fails.
When and what to log?
Generally, you should log only information that could be useful in diagnosing a hardware or software problem. Event logging is not intended for use as a tracing tool.
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.
Hardware problems: If a device driver encounters a disk controller time-out, a power failure in a parallel port, or a data error from a network or serial card, logging information about these events can help the system administrator diagnose hardware problems. The device driver logs the error.
Bad sectors: If a disk driver encounters a bad sector, it may be able to read from or write to the sector after retrying the operation, but the sector will go bad eventually. Therefore, if the disk driver can proceed, it should log a warning; otherwise, it should log an error event. If a file system driver finds a large number of bad sectors, fixes them, and logs warning events, logging information of this type might indicate that the disk is about to fail.
Information events: A server 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), a corruption 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. This is why it is important to log only essential information. It is also good to place event logging calls in an error path in the code rather than in the main code path, which would reduce performance.
The event-logging service uses the information stored in the EventLog registry key. The EventLog key contains several sub-keys, called logfiles.
Logfile registry information is used to locate resources that the event logging service needs when an application writes to and reads from the event log. The default logfiles are Application, Security, and System. The structure is as follows:
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
EventLog
Application
Security
System
Applications and services use the Application logfile. Device drivers use the System logfile. Windows NT will generate success and failure audit events in the Security log when auditing is turned on.
Event sources
Each logfile can contain sub-keys called event sources. The event source is the name of the software that logs the event. It is often the name of the application, or the name of a sub-component of the application, if the application is large. Applications and services should add their names to the Application logfile. Device drivers should add their names to the System logfile.
Event identifiers
Event identifiers uniquely identify a particular event. Each event source can define its own numbered events and the description strings to which they are mapped. Event viewers can present these strings to the user. They should help the user understand what went wrong and suggest what actions to take. Direct the description at users solving their own problems, not at administrators or support technicians. Make the description clear and concise and avoid culture-specific phrases.
The string written to the log could be information, a warning or an error.
Logging events in VB5
The APP object in VB has a LogEvent method for this purpose. The syntax is:
App.LogEvent("string to be written to log", )
Logtype can be any of the following:
Constant Value Description
VbLogEventTypeError 1 Error
VbLogEventTypeWarning 2 Warning
VbLogEventTypeInformation 4 Information
Create a new EXE project and add this code to the form load event. Create and run the EXE and exit the form. Check the event viewer for the VBRUNTIME source type of entry.
Sub Form_load()
With App
.LogEvent "Default Logging " & Now,
vbLogEventTypeInformation
.LogEvent .LogPath
.LogEvent .LogMode
End With
End sub
|
|
|
