How Event Viewer Logged Events in Windows XP

In Windows XP, the Event Viewer (eventvwr.msc) served as the primary administrative tool for viewing diagnostics and operational data across the operating system. Logging was handled by the background Windows Event Log service, which captured structured records from drivers, applications, and security components and wrote them into proprietary binary files (.evt). Rather than storing complete text logs, the operating system used an efficient message-table architecture that combined raw insertion data with predefined system resources to display system, application, and security notifications.

The Underlying Event Log Service and File Storage

All logging activities were coordinated by the Eventlog service, which ran within the services.exe process and started automatically during the initial phases of the Windows boot sequence.

The service maintained separate binary files for each primary log category, located in the %SystemRoot%\System32\Config\ directory:

  • SysEvent.Evt for System messages
  • AppEvent.Evt for Application messages
  • SecEvent.Evt for Security audits

Each .evt file functioned as a circular buffer with a predefined maximum size (512 KB by default). Administrators could configure wrap behaviors to either overwrite events as needed, overwrite events older than a specified number of days, or halt logging until cleared manually.

The Win32 Event Logging Architecture

Software and operating system components logged messages using the legacy Win32 Event Logging API, relying primarily on three core functions: RegisterEventSource, ReportEvent, and DeregisterEventSource.

To conserve disk space and optimize write operations, the ReportEvent API did not write full narrative strings into the .evt files. Instead, it recorded compact binary records containing:

  • A timestamp
  • The Event ID
  • The Event Source name
  • The Event Type (Error, Warning, Information, Success Audit, or Failure Audit)
  • Variable substitution strings (insertion strings)
  • Optional binary data

When an administrator opened eventvwr.msc, the MMC snap-in used the Event Source name to query the Windows Registry at HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\[LogName]\[SourceName]. This registry key pointed to a dynamic-link library or executable specified in the EventMessageFile value. Event Viewer read the message definition templates from the designated DLL, injected the stored insertion strings into the placeholders (e.g., %1, %2), and rendered the complete, readable message in the UI. If the required message file was missing or uninstalled, Event Viewer displayed a description-not-found error alongside the raw insertion parameters.

Logging Mechanism by Category

1. System Log

The System log captured events generated by Windows system components, such as device drivers, core kernel modules, hardware subsystems, and native Windows services. Kernel-mode drivers utilized the I/O Manager's IoAllocateErrorLogEntry and IoWriteErrorLogEntry routines to pass event structures up to the Event Log service, documenting device initialization failures, service start/stop timeouts, and file system errors.

2. Application Log

The Application log was dedicated to user-mode software, third-party utilities, and non-core services. Applications registered custom event sources within the registry during installation. Any program running with appropriate local permissions could invoke ReportEvent to write operational milestones, database connections, application crashes, or custom diagnostic warnings into AppEvent.Evt.

3. Security Log

Unlike the System and Application logs, the Security log had restricted access permissions and could not be written to directly by standard applications. Writes to SecEvent.Evt were mediated exclusively by the Local Security Authority Subsystem Service (lsass.exe).

Security events were generated only when specific audit policies were enabled in the Local Security Policy (secpol.msc) or via Group Policy. When policies such as "Audit logon events" or "Audit object access" were active, the security subsystem captured events as Success or Failure audits, logging authentication attempts, privilege usage, and modifications to user accounts. Even local administrators could not directly modify the entries within the Security log; they were only permitted to view or clear the entire log file.