Windows NT includes a native facility for the central storage and retrieval of event reporting information. This article explains how this tool works and where the information in it comes from.

Making Sense of NT Events

Windows NT includes a native facility for the central storage and retrieval of event reporting information. This article explains how this tool works and where the information in it comes from.

• By James D Murray
• 03/01/1999

An event is any type of detectable change that occurs within a system. A process starts or stops, a file opens or closes, a print job is paused or deleted. These are all examples of routine system events that may be reported. Exceptions and abnormal behavior are also causes of events. An event is considered significant if its occurrence is of interest to a system or security administrator.

When a process running on a Windows NT system detects a significant event, it may collect information on this event and report its occurrence to the event logging service. This service is a central collection and distribution point for all reported system event information. This service itself doesn’t monitor the NT system and its processes for reportable events. Instead, the event logging service only logs (or persistently stores) events reported it by other processes running on the local system.

Event reporting occurs behind the scenes and goes unnoticed by system users and administrators. It’s only when there’s a hint of a problem with the operation of the system that the event logs become the focal point of attention.

Event Viewer

Event Viewer is a standard NT tool for discovering and diagnosing problems on NT systems. It's a client application that views event logs recorded on both the local and remote NT systems.

You’ll find Event Viewer tucked away under Start | Administrative Tools (Common). Because it’s fairly out of sight, administrators often forget about it when diagnosing a system problem. If you use Event Viewer a lot, I suggest you add a desktop shortcut to EVENTVWR.EXE on your task bar or start it automatically by adding it to your Startup folder.

Figure 1 shows the main window of Event Viewer displaying the system log on my NT server. Each row in the list is a single event report. Each column is a specific piece of information that describes the event.

Figure 1. Event Viewer displaying the system log.

Each event log entry begins with an icon indicating the event type. The type may indicate the severity of the event (error, warning, or informational) or if an audited security event was successful or not. Each entry also contains a timestamp indicating when it was written to the log file. A process reporting an event must identify itself using an event source name registered to use the specific event log. The optional category name allows an event source to group its events into logical categories. Each event reported is identified by an event ID unique to each event source. The user column indicates the user that reported the event based on the SID of the user account under which the process reporting the event was running. The final column contains the name of the computer where the event log resides. It’s also possible to drill down into any event report and see an additional plain-English event description and any associated binary data (Figure 2).

Figure 2. Event Viewer displaying event detail information.

Event Viewer contains an assortment of other features that let you search, filter, clear, and save an event log as a backup file. However, there’s no feature that alerts an administrator that a specific event has just occurred. (You have to use a third-party product for that capability. More on that shortly.) Only through the diligent browsing of the event logs will an administrator become aware of significant events.

Event Log Files

Event Viewer views and maintains three event logs: the security log, the system log, and the application log. There is no provision for the support of additional logs.

The security log records the activity users, printers, and registry keys flagged for auditing by the system administrator. Security applications developed by third-party vendors also report events to this log. Only user accounts belonging to the Administrators group have permission to view, backup, and clear the security log.

Kernel-mode device drivers and low-level user-mode services use the system log for reporting events. These types of processes typically lack a user interface and are unable to interact with the desktop. The system event log is therefore its primary means of communicating error and informational messages.

The application log is used to store event information reported by high-level, user-mode processes. You probably won’t find many different messages in this log, since most applications report error events using message boxes. However, the application log makes a good alternative to writing error events to a log file. Moreover, on a single-user workstation, the application log makes a great place to write time-stamped application debugging information.

The information found in each event log is stored in a separate .EVT file in the %SystemRoot%\SYSTEM32\CONFIG subdirectory of each NT machine. Each event report is written as a separate record to one of these log files. The EVENTLOGRECORD data type definition found in WINNT.H defines the format of an event log file record. (See Figure 2 for an example of event details.)

The Event Logging Service

Local and remote processes don’t access the event log files directly. Instead, they must make requests of the event logging service to read from and write to the event logs. User-mode processes use the event logging API (implemented in ADVAPI32.DLL) to report events, query information in the event logs, and monitor the event logs for any changes. Kernel-mode processes must communicate with the event logging service via NT’s I/O Manager and through the use of I/O Error Log Packets.

The event logging service is one of the many services controlled by the NT Service Control Manager (SCM). The SCM runs under the context of the System Account and provides the System security privilege to the event logs. The SCM is also a Remote Procedure Call (RPC) server that allows the event logging service on the local system to communicate with the event logging service running on remote NT systems. Applications, such as Event Viewer, may view and back up the event logs of remote NT systems using the event logging API.

All configuration information for the event logs and the event logging service is stored in the registry under the HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\EventLog key. Three additional subkeys store the configurations for each event log, including the location of the event log file, maximum allowed log file size, the retention (event wrapping) policy setting, and the listing of event sources registered to report to the log. Many of these settings are changeable using Event Viewer.

The ancestor of Event Viewer and the event logging service is the NetWatcher utility included with Windows for Workgroups. NetWatcher is used to monitor, control, and audit the activity of network hosts connected to a Windows for Workgroups server. The occurrence of up to 10 predefined events may be monitored and written to the AUDIT.LOG file by NetWatcher. The utility—similar in appearance to Event Viewer—is used to view the log file.

The modern version of NetWatcher, NetWatch, is available for both Windows 95 and NT and is distributed in the Windows NT Resource Kit—although it doesn’t include an event logging facility. An Event Viewer client application that allows the event logs of remote Windows NT systems to be viewed from a Windows 95 system is included with the Windows NT 4.0 Server Tools. You can find the server tools distributed on the Windows NT Server CD-ROM and the TechNet Client Utilities CD-ROM. Unfortunately, neither Windows 95 nor 98 have any native event logging facility.

Security Auditing

The NT security auditing facility is disabled by default. This explains why the security log on your NT system is currently blank. If you clear the security log, a single event is written to the log indicating that it was cleared, but that’s all. How an administrator enables security auditing depends on the type of events that the system’s security policy requires to be audited. The User Manager enables the auditing of user and system events (logon/logoff, system restart and shutdown, changes to security policy, etc.). Windows NT Explorer controls the auditing of files and folders on NTFS volumes. And the Print Manager is used to enable the auditing of printer and pint spooler events.

But which events should be audited? Is there any harm in auditing all events that occur? Is it necessary to audit any events at all?

The bottom line: The more security-critical a system is, the greater the security auditing should be. An isolated single-user workstation may need little or no auditing, a file server moderate auditing, and NT systems acting as routers, gateways, and authentication servers the most auditing of all. The greater the chance of a system being misused or even coming under direct attack, the greater the need for security auditing.

At minimum, you need to log all successful and unsuccessful logon/logoff attempts made by users on the local system and from remote systems, including NULL session logons. Failed file and object access events are rare, but often significant. Tracking changes made to the system’s security policy configuration and auditing policy should also be enabled.

From the Third Party

Both Event Viewer and the event logging service is often the object of scorn and ridicule. Administrators puzzled and panicked by abnormal system behavior are often frustrated by cryptic event logging messages that neither tell exactly what the problem is nor what a possible solution may be, or what’s worse: an impaired system with no mention of any problems appearing in the event logs at all.

However, you can’t blame Event Viewer. Would you criticize Microsoft Word just because you were using it to view a document whose contents were sparse or unhelpful? Word didn’t create the contents of the document; it’s just displaying the information that the document contains. The same is true for Event Viewer; it only displays the information that other processes have reported to the event logs.

Many system administrators feel that the NT event logging service falls far short of the features they really need to monitor and troubleshoot both stand-alone NT workstations and a network filled with NT hosts. That’s led third-party companies to pick up the slack by creating utilities to augment the capabilities of NT’s event logging service—or replace it entirely.