Event logging for Microsoft Windows provides a standard, centralized way for applications and the operating system to record important software and hardware events. The event-logging service (eventlog) stores events from various sources in a single collection called an event log. The system administrator can use the event log to help determine what conditions caused the error and the context in which it occurred. TechTarget have an excellent overview of Windows event logs available.

The Windows event log is a detailed record of system, security and application notifications stored by the Windows operating system that is used by administrators to diagnose system problems and predict future issues. Applications and the operating system (OS) use these event logs to record important hardware and software actions that the administrator can use to troubleshoot issues with the operating system. The Windows operating system tracks specific events in its log files, such as application installations, security management, system setup operations on initial startup, and problems or errors.

The event log contains the following standard logs as well as application and services log:

Log Description
Application Contains events logged by applications. For example, a database application might record a file error. The application developer decides which events to record.
Security Contains events such as valid and invalid logon attempts, as well as events related to resource use such as creating, opening, or deleting files or other objects. An administrator can start auditing to record events in the security log.
System Contains events logged by system components, such as the failure of a driver or other system component to load during startup.
CustomLog Contains events logged by applications that create a custom log. Using a custom log enables an application to control the size of the log or attach ACLs for security purposes without affecting other applications. Custom Logs can be created using the Event Viewer tool.
Application and Services Logs eG Enterprise does not track or monitor all these logs by default. However, a customer can use our “eG Custom Event log” functionality to monitor and track any of these logs or Windows CustomLogs as they desire.

Figure 1: As viewed via the Microsoft Event Viewer. There are a very large number of Application and Services logs.

How can I use the information in a Windows Event Log?

The most common usage of the Windows Event Log is for retrospective debug and analysis in scenarios where a problem has arisen, and a Windows system suffers a failure or performance issues resulting in negative impacts on end-users. The logs are examined or parsed, often manually or with user-instigated tools to search for events that correlate to the issue and may indicate the possible cause

By periodically viewing the event log, the system administrator may be able to identify problems (such as a failing disk, unauthenticated logon attempts, etc) before they affect end user but of course as a manual process it would be hit and miss as to whether issues were detected.

Modern enterprise IT organizations are more likely to automatically and proactively monitor the information in the Windows Event Log either by scheduling their own scripts or using out-of-the-box software such as eG Enterprise. New events written to the logs are proactively and continuously examined and in the event of an event that indicates an issue an alarm or alert is automatically triggered to notify the administrator.

Organizations adopting a Security Information and Event Management (SIEM) strategy are increasingly taking a proactive approach to event log monitoring. For more information on the benefits and ROI of investing effort in proactive monitoring, see: What is Proactive Monitoring and Why it is Important.

The Windows Event Log Service (eventlog) is available to third parties to log events. ISVs can ensure issues in their own applications are recorded within the Windows Event Logs – if they choose to do so. In practice the level of logging implemented varies significantly between applications.

Event Types, Levels and Keywords

In many log viewing tools you will see a “Type” column/field although the Windows Event Viewer doesn’t have this column. Historically there were five types of events that can be logged. All of these 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 displays a different icon for each type in the list view of the event log.

The following table describes the five original event types used in event logging.

Event type Description
Error An event that indicates a significant problem such as loss of data or loss of functionality. For example, if a service fails to load during startup, an Error event is logged.
Warning An event that is not necessarily significant but may indicate a possible future problem. For example, when disk space is low, a Warning event is logged. If an application can recover from an event without loss of functionality or data, it can generally classify the event as a Warning event.
Information An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, it may be appropriate to log an Information event. Note that it is generally inappropriate for a desktop application to log an event each time it starts.
Success Audit An event that records an audited security access attempt that is successful. For example, a user’s successful attempt to log on to the system is logged as a Success Audit event.
Failure Audit An event that records an audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt is logged as a Failure Audit event.

Selected activities of users can be tracked by auditing security events and then placing entries in a computer’s security log.

Starting with Windows Vista (Windows Server 2008), Microsoft removed “Type” from the event schema and replaced it with “Level”. Recent versions of Windows now use the following levels: Critical, Error, Warning, Information, Verbose (software developers are free to extend this set and add their own customized levels). These levels define event severity, but they do not define audit status (i.e. success or failure). There is now a new event attribute called keywords. Keywords are a 64-bit mask, 2 bits of this mask represent Audit Success and Audit Failure events.

These changes means many viewers and parsers are inconsistent in how data is exposed and in particular vary in how security logs are handled. When a modern version of the Windows Event Viewer tool displays the Security event log, it shows Keywords column and hides Level column by default.

You will see the event level exposed with the eG Enterprise management console, events are marked as being verbose, informational, warning, or critical and shown alongside errors.

What are the elements of a Windows Event Log?

The structure of windows events are defined in an XML schema, see: Event Schema Elements – Win32 apps | Microsoft Learn. Community examples of give a good overview, see: Where to get schemas for log events for windows 10? – Super User.

How does eG Enterprise monitor Windows Event Logs?

eG Enterprise monitors Windows Event Logs using an agent. There are several security issues associated with agentless monitoring of Event Logs and for this reason eG Enterprise only supports secure agented monitoring. The event log record has both single- and double-byte characters in the event description. These characters are identified correctly from the machine where the log record is originally created. This is one additional reason why eG Enterprise monitors the event log records with the help of an agent.

Figure 2: Standard Windows logs such as Application Events, System Events and Security Log are shown in the Service layer of the eG Enterprise layer models alongside Service information.

eG Enterprise will monitor the standard windows Event Logs out-of-the-box, including the:

  • Application Event Log
  • Security Log
  • System Event Log

Certain key application or service logs may be included for certain technologies, for example FSLogix logs are monitored out of the box by eG Enterprise on Microsoft AVD (Azure Virtual Desktop) deployments.

Errors within the Event Logs will automatically trigger alerts within eG Enterprise. Policies can be used to customize the alerting to filter either by inclusion or exclusion to limit the alerting to those errors and warnings of interest and to exclude any noisy logging.

Figure 3: Errors have been found in the System Event Log, an alert has been triggered and sent to the alarm window and the component has turned amber to guide the administrator. The detailed diagnosis icon (magnifying glass) can be clicked to provide details of the errors instantly without having to manually trawl logs.

Figure 4: Diagnosis details provide full details of the Errors.

What is a custom Windows Event Log?

Some administrators choose to create custom event logs, rather than writing to the default Application Event Log they may wish to filter certain events from certain events to a custom log file. This means they can control the retention and verboseness of the custom log. For a particularly problematic application an admin may choose to collect verbose application information events and retain them for a few hours in a custom log rather than fill up the main Application Event logs.

There a few guides available to help implement custom logs, such as Use PowerShell to Create and to Use a New Event Log – Scripting Blog (microsoft.com) and Creating a custom event log under Microsoft Event Viewer to log server events – JasonSamuel.com.

Custom logs follow the standard Windows Event Log format and schema and as such can be monitored within eG Enterprise.

Filter and customize Event Log tests in eG Enterprise

How event logs are monitored can be customized within eG Enterprise via policies. Event logs can be filtered so that events from certain sources are explicitly excluded or included, similar filtering can be performed on specific EventIDs and so on.

Figure 5: From the “Admin” tab, administrators can configure event log monitoring via the menu path Agents-> Tests -> Specific Configuration.

Select Agents-> Tests -> Specific Configuration.

Figure 6: Select the logs you wish to view or reconfigure the default alerting for. In this case the System Event Log for an AVD (Azure Virtual Desktop) deployment.

Select the appropriate Component and Event Log then press the Reconfigure button.

Figure 7: Using the “+” icon next to the “FILTER” to Add/Modify Policy Filters

Use the + icon next to the FILTER field to Add/Modify Policy Filters

Figure 8: Event policies can be now added and customized based on event source, event IDs and event descriptions
In the next section, I’ll work through some examples of working with event log policies.

How to monitor windows custom Event Logs or add additional standard application services event logs with eG Enterprise

Example 1 – Monitor specific events or informational events – Example: Monitoring kerberos encryption via standard logs

Besides monitoring and alarming on warning and error events you might want to monitor specific event IDs and/or informational events. With eG Enterprise it’s very easy to add this to a new or existing component. The easiest approach is to use the Custom Event Log test. You might need to associate this test to the component type that you are monitoring. After that, provide the log type, create a filter to include only the required event(s) and select only this filter in the test configuration. If the events include Informational events, make sure to select the according radio button. In this case the events of interest were:

  • Event ID 4768 – A Kerberos authentication ticket (TGT) was requested
  • Event ID 4769 – A Kerberos service ticket was requested

As the customer wished to alert on and collect detailed diagnostics from these two informational-level event IDs (4768 + 4769) from the security log. This is on Domain Controllers so they can monitor what type of Kerberos encryption is being used.

Figure 9: First we have to associate the Custom Event Log test with the component. This is not usually associated by default.

Figure 10: Giving the policy a helpful name can be useful. Multiple event IDs can be added.

Figure 11: Now you will see our new policy named “4768-4769” in the “FILTER” field of the test overview

Example 2: Using custom logs to monitor Symantec endpoint protection

Custom Event Log monitoring can be configured by those with appropriate privileges via the admin tab in eG Enterprise.

It is important to ensure that the Custom Event Log test is associated with the system and component where the event logs are generated, by default this test may not be enabled. You can do this via the Admin tab and Agents -> Tests -> Associate / Disassociate. After this you will need to Enable the test via Agents -> Tests -> Enable / Disable menu.

Once the test is enabled, eG allows us to add custom logs to configure how the monitoring will occur.

Below is the procedure for adding a custom event log monitoring with eG. As a user/admin we can find the event ID, event sources or event description from the event viewer. Once this information is captured, we can provide the details in the test description.

Figure 12: Use the Windows EventViewer tool to view and capture the details you need to add monitoring of the custom Symantec logs.

eG Enterprise allows multiple filters to trigger an alert for a custom event log. In this case, we are creating a custom event log monitoring for the Symantec Endpoint protection of a particular Windows operating system.

Figure 13: The test overview, again, allows you to add policies using the “+” icon next to the “FILTER” field

Figure 14: Here we have chosen to monitor all events from the “Symantec Endpoint Protection Client” logs that Symantec as a vendor choose to implement.

Once the test configuration is defined for the monitoring like above, eG will start capturing the measures. If there are any red flags observed, eG will show us an alert.

Whilst we demonstrated configuring the custom event log monitoring for one particular event only above, eG Enterprise also allows the administrator to configure the tests for multiple events with different custom event IDs, Event descriptions and so on.

Windows Event Log reporting: Consolidated Event Log reports for your organization

Beyond live monitoring and reporting, historical reporting of events is increasingly important, particularly within larger organizations. Comprehensive reporting of Windows provides useful data to quantify system performance against SLAs and KPIs and input into work and resource planning. Moreover, in larger organizations where multiple teams or individuals may have responsibilities or work to shift patterns – recurrent and intermittent issues can be tracked across shifts and teams.

Many Windows Event Log records are ephemeral and not indicative alone of a serious issue. The ability eG Enterprise gives to administrators to review those events with the context of the last day, week, month or longer provides deep insights into intermittent or recurrent issues.

eG Enterprise provides a set of reports out-of-the-box that provide live and historical reports on Windows Event Logs. These reports can be scheduled and published as needed, or generated on-the-fly. A large number of configuration options and filters are available within the ready-to-go reports, allowing administrators to parse and view data swiftly. The results of reports can be exported to standard formats such as .csv and .pdf for further analysis or for audit purposes.

Three out-of-the-box reports are supplied within eG Enterprise to assist with troubleshooting, these can be found under the Reporter tab via Reports by FUNCTION -> Analytical Reports -> Event Log Reports:

  • Analysis of Event Report: This is particularly powerful for administrators to determine patterns of events
  • Application Crashes / Hangs Report: This is often very useful for determining the cause of service failures and for determining the extent of application issues across multiple machines
  • Logon Failures Report

Figure 15: Event Log Reports – Analysis of Events. A large number of configuration parameters and filters can be applied to assist troubleshooting and rapidly explore large numbers of events. Events within time intervals of interest can be rapidly isolated.

Figure 16: Here filters have been used to review recent security events on Windows OSs captured from the windows events security log. Although only “Informational” events have occurred this report highlights there is a potential security issue on a firewall. Admins can schedule regular reports to audit events.

Figure 17: The “Application Crashes / Hangs” event log reports give an overview for administrators to track problematic applications and intermittent / recurrent issues to target resources – in this case Chrome seems to be an application with repeated widespread issues worth investigating further.

Figure 18: The Logon Failures report uses event log information to give administrators an overview of any pattern of recent logon failures

Reports can be further customized or custom reports built via the easy-to-use GUI eG Enterprise report builder editor if need.

Monitoring Windows service availability beyond Event Logs

Any Windows Services you leverage will use the event log service to record events and notifications from those services. Of course, if any of those services are unavailable and not running no information will be recorded. eG Enterprise includes “Windows Service Monitoring” to continuously monitor the availability of Windows Services alongside event log monitoring, to ensure you have full observability. If services have failed and are unavailable alerts will be raised. Failures in services can be easily correlated with any events such as warnings or errors recorded immediately prior to the failure.

Monitoring Windows Service availability alone is only sufficient to know that a service has failed or is unavailable. Event logs will often reveal the root cause of service failure. In particular, if services have crashed or failed the event log report Application Crashes/Hangs will be of particular use, and can be found under the Reporter tab via Reports by FUNCTION -> Analytical Reports -> Event Log Reports -> Application Crashes/ Hangs.

Figure 19: Note how Event Logs including the FSLogix Application Event Log is monitored alongside the Security Log, Application Event Log and System Events Log for AVD. Whilst all the key Window Services are continually monitored for their Service State and Service Availability, for example the FSLogix Cloud Caching Service.

Note of thanks: Many thanks to my colleague Erik van Veenendaal who provided some of the examples and information in this article.

Monitoring Windows Event Logs – Frequently asked questions (FAQs)

Q: How can I find out what an Event ID in the Event Log means?

There are many online directories of Windows Event IDs such as: Randy’s Windows Security Log Encyclopedia (ultimatewindowssecurity.com)./

Microsoft themselves have a list of Security Log Event IDs they recommend monitoring, see: Appendix L – Events to Monitor | Microsoft Learn.

Q: How can I monitor Windows Event Log with Azure Monitor and Log Analytics?

You can collect Windows event log data sources with Log Analytics agent and access this data via Azure Monitor, see: Collect Windows event log data sources with Log Analytics agent in Azure Monitor – Azure Monitor | Microsoft Learn. You can collect events from standard logs, such as System and Application, and any custom logs created by applications you need to monitor. However, you cannot configure the collection of security events from the workspace by using the Log Analytics agent. If using native Azure functionality, you can only use Microsoft Defender for Cloud or Microsoft Sentinel to collect security events. The Azure Monitor agent can also be used to collect security events.

By default, event log data stored within Log Analytics will only be retained for 30 days. Organizations often wish to retain such data longer for retrospective analysis of incidents and auditing needs. This is where a third-party product such as eG Enterprise can help.

Q: Are there any free tools to parse, view and examine the Windows Event Log?

Microsoft provides a free tool called Event Viewer that provides a simple GUI within which users can manually navigate and examine events and the information within the underlying logs. Information from certain logs such as the Security Log is only accessible to those with appropriate Administrator level privileges. See: What Is the Windows Event Viewer, and How Can I Use It? (howtogeek.com). Given how event logs have evolved users of post-Vista versions of Windows will probably find this guide helpful, see: How to use Event Viewer on Windows 10 | Windows Central.

There are also plenty of proprietary Windows Event Log management tools available.

Q: How do I view Windows event logs as an end user?

On a Windows OS: Press the Windows key + R on your keyboard to open the run window. In the run dialog box, type “eventvwr” and click OK. This will start the Event Viewer tool. In the Event Viewer window you will be able to expand the Windows Logs menu. Under the Windows Logs menu, you will notice the different categories of events such as: application, security, setup, system, and forwarded event.

Q: Can I write a PowerShell script to read the Windows Event Log?

For those looking to write and maintain their own Event Log monitoring scripts, Microsoft provides PowerShell cmdlets. In newer versions of PowerShell cmdlets such as Get-WinEvent are recommended (See: Get-WinEvent (Microsoft.PowerShell.Diagnostics) – PowerShell | Microsoft Learn) whilst for older versions the legacy cmdlets such as Get-EventLog are available (See: Get-EventLog (Microsoft.PowerShell.Management) – PowerShell | Microsoft Learn). Beyond parsing and analyzing the log files, those looking to build their own solution usually have to invest effort in scheduling their scripts to run, integrating results into some sort of alerting system, and ensuring information is preserved and available during failover.

Developers looking to implement Windows Event logging within their applications should refer to the Microsoft Developer’s Guide: Using Windows Event Log – Win32 apps | Microsoft Learn.

Q: What is Security Information and Event Management (SIEM)?

As defined by Gartner: “Security information and event management (SIEM) technology supports threat detection, compliance and security incident management through the collection and analysis (both near real time and historical) of security events, as well as a wide variety of other event and contextual data sources. The core capabilities are a broad scope of log event collection and management, the ability to analyze log events and other data across disparate sources, and operational capabilities (such as incident management, dashboards and reporting).”

eG Enterprise’s rich event log monitoring and visualization capabilities provide organizations with a straightforward way to adopt and implement proactive SIEM methodologies.

eG Enterprise is an Observability solution for Modern IT. Monitor digital workspaces,
web applications, SaaS services, cloud and containers from a single pane of glass.

Free Trial  See the platform

eG Enterprise is an Observability solution for Modern IT. Monitor digital workspaces,
web applications, SaaS services, cloud and containers from a single pane of glass.

Free Trial  See the platform

More information and reference information