How to read Windows Event Viewer logs without the guesswork

Event Viewer is the built-in Windows tool that shows the events Windows, drivers and apps record. To read it well, pick the right log, filter by level and time, then read the source, event ID and description of each event around the time your problem happened.

Opening Event Viewer

Type "Event Viewer" into the Windows search box and open it. Some logs, such as the Security log, may require an administrator account.

The left pane is a tree of logs. The middle pane lists the events in the selected log. When you select an event, the lower middle pane shows its details, and the right pane lists actions such as filtering.

Where the logs live

Microsoft's documentation groups logs into two categories.

Windows Logs

• Application: events logged by applications or programs. Developers decide what to record here, for example a file error in a database program.

• Security: events such as valid and invalid sign-in attempts and, when auditing is enabled, access to files and other resources. Administrators decide what gets audited.

• Setup: events related to application setup.

• System: events logged by Windows components, for example a driver that failed to load during startup.

• Forwarded Events: events collected from other computers through an event subscription. On a home PC this is usually empty.

Applications and Services Logs

These hold events from a single application or component rather than the whole system, such as a printer service or Windows Update. Microsoft describes Admin logs as aimed at users and support staff, with problems that have a well-defined fix, and Operational logs as useful for diagnosis but needing more interpretation. Analytic and Debug logs are hidden and disabled by default and are mainly for developers.

If a specific program crashes, start with the Application log. For startup, shutdown, driver or hardware problems, start with System.

Levels: how serious is it?

Each event has a level shown with an icon in the list.

• Critical: a serious failure. For example, Microsoft lists the unexpected-restart event below at this level.

• Error: a significant problem, such as loss of data or functionality. Microsoft's example is a service that fails to load during startup.

• Warning: not necessarily significant, but it may point to a future problem, such as low disk space.

• Information: a successful operation, such as a driver loading correctly.

• Success Audit and Failure Audit: in the Security log, these record audited access attempts that succeeded or failed, such as sign-ins.

A healthy PC still logs plenty of errors and warnings, so a red icon on its own is not proof that something is wrong. What matters is whether an event lines up with the time and nature of your problem, and whether it repeats.

Reading a single event

Select an event and look at the General tab. The fields that matter most:

• Log Name: which log it came from.

• Source: the component or program that wrote it, for example "Microsoft-Windows-Kernel-Power" or the name of an app.

• Event ID: a number the source uses for that type of event. The same number can mean different things for different sources, so always read the ID together with the source.

• Level: as above.

• Logged: the date and time. Compare it with when your problem happened.

• Description: the message text. Often the most specific clue is a file name, service name, error code or device name inside it.

The Details tab shows the same event as structured data, including fields the General tab summarizes. Error codes and parameters often appear there.

A synthetic sample of how an event might read on the General tab:

Log Name: System

Source: Microsoft-Windows-Kernel-Power

Event ID: 41

Level: Critical

Description: The system has rebooted without cleanly shutting down first.

Filtering so you see only what matters

Large logs can hold tens of thousands of events. Use the filter instead of scrolling.

1. Select a log in the left pane, such as System.

2. In the right pane (or the Action menu), choose Filter Current Log.

3. In Logged, choose a time window, or Custom range to set exact start and end times around your problem.

4. Tick the Event level boxes you want, for example Critical, Error and Warning.

5. Optionally pick an Event source, or type Event IDs. Microsoft's documentation explains that you can separate IDs with commas, give a range such as 4624-4634, and exclude an ID with a minus sign, such as -4630.

6. Select OK. Use Clear Filter to go back to the full log.

A filter applies to one log at a time and is temporary. To search across several logs, or to keep a filter you use often, create a Custom View from the Action menu instead.

A few common event IDs (verified on Microsoft Learn)

These are documented by Microsoft. Each one is tied to a specific source and log.

• 41 (System log, source Kernel-Power, Critical): "The system has rebooted without cleanly shutting down first." Microsoft notes that on its own it may not explain why. A power interruption or a Stop error (blue screen) are possible causes, and the event data may include a bug check code.

• 1074 (System log, source User32): an application or a user started a shutdown or restart. It records who started it and the reason given.

• 6006 (System log): Windows was shut down cleanly.

• 6008 (System log): the previous shutdown was unexpected.

• 4624 (Security log): an account was successfully logged on.

• 4625 (Security log): an account failed to log on. Microsoft's reference explains the Logon Type, Status and Sub Status fields, which help tell a mistyped password from a locked or disabled account.

For anything else, search Microsoft Learn for the source name plus the event ID. Be cautious with forum posts that give an event ID meaning without naming the source.

A simple routine

1. Write down roughly when the problem happened.

2. Open the most likely log (System or Application).

3. Filter to Critical, Error and Warning, within about 15 minutes either side.

4. Read the events closest to the problem time, oldest first. The first one in a burst is often the cause; later ones can be side effects.

5. Note the source, event ID and any error code, then look those up in the vendor's documentation.

If an app's own log shows a stack trace, our guide on how to read a stack trace explains which line to look at first. Before you share an event or an exported log with anyone, check it for account names, computer names and IP addresses; here is how to redact logs before sharing.

Get the events that matter explained

EasyToDecode is launching soon. It will read the events or exported log you share, quote the entries that line up with your problem, flag what's missing to pin down the cause, and suggest the next checks or questions for support. See how it works or join the waitlist to hear when it opens.