Event Viewer is Windows’ diagnostic log — a record of system events, application errors, warnings, and informational notices that Windows and installed applications write continuously in the background. When something goes wrong (a crash, a service failure, a driver error), the logs often contain the exact cause and timestamp. When something is slow or behaving oddly, the logs frequently show what changed before the problem appeared. If you want the full context, see our Windows 11 How-To Guides.
Most users only discover Event Viewer after calling tech support and being asked “what does Event Viewer show?” This guide shortens that learning curve.
Opening Event Viewer
Win+X → Event Viewer. Or: Win+S → “Event Viewer” → open. Or: Win+R → eventvwr.msc. The interface has three panels: the source tree on the left, log content in the centre, and actions on the right.
Log structure — where to look
The left panel has two main sections under “Windows Logs”:
- Application: events from applications and software running on Windows. Application crashes, errors from services, failures from installed software.
- System: events from Windows system components — driver failures, service starts and stops, hardware errors, disk errors. This is usually the most useful log for Windows problems.
- Security: audit events — successful and failed logins, privilege use, policy changes. Administrator access only. Useful for security investigations.
- Setup: Windows setup and installation events.
Under “Applications and Services Logs”: more specialised logs organised by application and Windows component. Windows Defender, Task Scheduler, Windows Update, Bluetooth, and dozens of others each have their own dedicated logs here. These are more focused than the general Application and System logs.
Reading an event
Each log entry has:
- Level: Critical (worst), Error, Warning, Information, Verbose. Red icons = Critical/Error, yellow = Warning, white = Information.
- Date and Time: exactly when the event occurred.
- Source: which system component or application generated the event.
- Event ID: a numeric code specific to the event type within that source. The same Event ID means the same type of event occurred.
- Description: the actual message. Can range from clear (“Windows Update successfully downloaded”) to cryptic (“Faulting application name: chrome.exe, exception code: 0xc0000005”).
Clicking any event in the centre panel shows the full details below. The “Details” tab (XML view) shows the raw structured data — useful when the general description is vague but the specific data contains more information.
Finding relevant events quickly
The System or Application log may contain thousands of entries. Filtering immediately makes it manageable:
Right-click the log (System or Application) → “Filter Current Log” → filter by:
- Event level: check “Critical” and “Error” only to show only serious events
- Event sources: filter to a specific application or system component
- Event ID: filter to a specific ID if you know what you’re looking for
- Time range: “Logged” dropdown → custom range → enter start and end times
The practical approach when something went wrong: open System log → Filter → select only Critical and Error → narrow the time range to within an hour of when the problem occurred. The relevant events are typically visible immediately.
Our guide on Windows 11 troubleshooters covers the automated tools that address the most common issues Event Viewer helps identify, and our guide on Windows 11 Task Manager covers the real-time process view that pairs with Event Viewer’s historical record. For decoding specific Windows Event IDs and understanding their causes, Microsoft’s security event documentation covers security-related events in detail, with the general System events documented in Windows developer documentation.
Useful Event IDs to know
| Event ID | Log | What it means |
| 41 | System | Unexpected shutdown (power loss, crash) |
| 1001 | System | Windows Error Reporting — application crash details |
| 1074 | System | System restart or shutdown (who initiated it) |
| 6006 | System | Clean Windows shutdown |
| 6008 | System | Previous shutdown was unexpected |
| 7034 | System | A service terminated unexpectedly |
| 7036 | System | A service entered running or stopped state |
| 1000 | Application | Application crash (with faulting module name) |
| 4625 | Security | Failed login attempt |
| 4624 | Security | Successful login (with user, source, logon type) |
Event ID 41 (unexpected shutdown) followed by finding no clean shutdown event (6006) in the preceding hours: the machine crashed or lost power. The 41 event description often includes a “BugcheckCode” — a hexadecimal number that maps to a specific type of crash. Searching “Windows BugcheckCode 0x[number]” surfaces documentation and community reports about that specific crash type.
Creating custom views
Action panel → “Create Custom View” → define a filter using multiple criteria — Event IDs, sources, log types, time ranges, keywords — all combined. The custom view appears in the left panel under “Custom Views” and can be clicked at any time to re-run the same filter across current log data.
Useful custom views to create:
- All Critical and Error events from Application and System logs combined (cross-log filter)
- Events from a specific application you’re troubleshooting
- All service start/stop events (Event IDs 7036, 7034)
- All unexpected shutdown events (Event ID 41)
Event subscriptions — centralised logging
For IT administrators managing multiple machines: Event Viewer supports Event Subscriptions — the ability to forward events from remote machines to a central collector. The collector machine’s Event Viewer shows events from all subscribed machines in one place. This is Windows’ built-in centralised log management, without third-party tools.
Setup requires: Windows Event Collector service running on the collector, WinRM enabled on source machines, and subscription configuration. This is an enterprise IT feature rather than a home user one, but knowing it exists prevents purchasing third-party log aggregation tools for scenarios where the built-in capability is sufficient.
Exporting and sharing events
Right-click any log → “Save All Events As” → saves the log as .evtx (Windows event log format) or .txt/.csv. The .evtx format preserves all event structure and can be opened in Event Viewer on another machine. This is useful for: sharing crash logs with support, preserving log state before making changes that would clear old events, or archiving log data for compliance.
Exporting a filtered view: after filtering → Action → “Save Filtered Log File As” → saves only the filtered events. Much more manageable for sharing or review than exporting the entire unfiltered log.
Event Viewer is the answer to “what exactly happened on this machine at that time.” The information is there if you know where to look. For common problems: the filter approach (Critical and Error only, narrow time range) surfaces the relevant events within seconds. For security investigations: the Security log’s authentication events tell you who logged in, from where, and when — the kind of information that’s unavailable through any other Windows interface. Understanding Event Viewer’s structure turns a confusing wall of log entries into a navigable diagnostic tool.
Clearing event logs
Right-click any log → “Clear Log” → clears all events from that log. This shouldn’t be done routinely — the logs don’t grow indefinitely (Event Viewer manages log size automatically, overwriting oldest events when limits are reached). Clearing is appropriate when you want a clean baseline before testing: clear the relevant log → reproduce the problem → check what events appeared. This eliminates historical noise and makes new events immediately visible.
The maximum log size and overwrite behaviour per log: right-click the log → Properties → shows maximum log size (KB) and the overwrite policy. “Overwrite events as needed” is the default — when the log fills, oldest events are replaced by newest. “Do not overwrite events” stops logging when full and requires manual clearing. “Archive the log when full” saves a dated copy before overwriting. For personal use: the default overwrite behaviour is correct. For compliance and security auditing: archive mode ensures no events are lost.
Using Event Viewer to diagnose startup crashes
If Windows crashes during or shortly after startup, and the machine reboots before you can see the error: Event Viewer’s logs persist across reboots and show what happened before the crash. After the restart: open Event Viewer → System log → filter for Critical and Error events from the time of the crash → the crash events are there with timing and cause data.
Event ID 41 (unexpected restart) with a specific BugcheckCode in the description data identifies the crash type. The BugcheckCode translates to a Stop Code that appears on Blue Screen errors — they’re the same crash, just logged in Event Viewer with the numeric code rather than the text description. Having both the Event Viewer log and the minidump file (C:WindowsMinidump) gives the most complete picture of what crashed.
Third-party Event Viewer alternatives
Windows’ built-in Event Viewer is functional but dated in UI design. Alternatives that provide better readability:
- FullEventLogView (free, NirSoft): shows all events from all logs in a single flat view with better filtering and column sorting than the native viewer. Particularly good for cross-log analysis.
- Event Log Explorer (free for basic use): more powerful search and filtering with a better UI than the native viewer. Network log access and subscription features in the paid version.
- WinLogView: lightweight viewer that presents events in a more readable table format without the native viewer’s three-panel complexity.
These tools use the same underlying Windows event data — they’re different interfaces to the same logs, not different logging systems. The native Event Viewer is adequate for occasional use; if you regularly work with Windows logs for IT support or security review, a dedicated viewer pays back the familiarity investment quickly.
Reliability Monitor as a companion tool
Win+S → “reliability history” → Reliability Monitor presents the same underlying event data in a calendar timeline rather than a flat log. Critical errors, software failures, and Windows failures appear as icons on the dates they occurred. Clicking any date shows the specific events from that day in readable descriptions.
Reliability Monitor is better than Event Viewer for answering “when did this problem start?” — the timeline makes correlations (a crash started happening after a specific update) immediately visual. Event Viewer is better for deep investigation of a specific event. Using both together gives you the overview (Reliability Monitor) and the detail (Event Viewer) without choosing between them.
The combination of Event Viewer and Reliability Monitor covers Windows’ built-in diagnostic log landscape. Understanding when to use each — Reliability Monitor for timeline and correlation, Event Viewer for specific event data and filtering — makes Windows diagnostics more systematic and considerably faster than the alternative of searching through the interface without a clear strategy.
Performance log and alert monitoring
Event Viewer connects to Windows Performance Monitor for advanced scenario-based log collection. Performance Monitor → Data Collector Sets → allows creating collections that combine event logs, performance counters, and system information captures into a single diagnostic package. When a specific performance problem needs investigation: a data collector set captures everything needed — events, CPU/memory/disk metrics, and configuration snapshots — in one coordinated capture.
For most users, this level of monitoring is beyond everyday needs. But for recurring performance problems that can’t be diagnosed from snapshots: a data collector set running during the problematic period provides a continuous record of both system metrics and events, showing exactly what changed at the moment performance degraded. It’s the bridge between Event Viewer (what happened?) and Performance Monitor (how did system metrics look when it happened?).
Event Viewer’s core value is making the invisible visible. Windows is doing hundreds of things in the background at any moment — services starting and stopping, scheduled tasks running, hardware communicating, applications launching and crashing. Event Viewer makes the log of all this activity available and searchable. For most users most of the time: the logs sit unread because everything is working fine. For the moments when something isn’t: the record of exactly what happened and when is invaluable, and it’s been building automatically the entire time the machine has been running.
For anyone learning Windows administration: spending an hour with Event Viewer on a working machine — just browsing what’s in the System and Application logs, recognising the normal background noise, understanding what events look like when services start and stop normally — builds the pattern recognition that makes the abnormal events jump out immediately during actual problems. The contrast between “normal” and “broken” is much easier to see when you know what normal looks like. If this sounds familiar, Windows 11 Quick Settings is worth a look.
