Event Viewer has a reputation for being noisy and hard to navigate, but it’s still the first place any real troubleshooting session should start. Learning to filter it properly turns it from an overwhelming wall of text into a genuinely fast diagnostic tool.
The Logs That Matter Most
- System — driver failures, service crashes, hardware errors
- Application — crashes and errors from installed software
- Security — logon events, privilege use, and audit trails (requires audit policy to be enabled)
- Setup — Windows Update and feature installation history
Filtering Instead of Scrolling
Never scroll through raw event logs — use Filter Current Log and narrow by Event ID, source, and time range. Critical and Error level events are almost always what you’re after; Information-level noise can safely be excluded during troubleshooting.
Querying Logs from PowerShell
For anything beyond a one-off look, Get-WinEvent is dramatically faster than the GUI and scriptable across remote machines:
# Get the last 20 error-level events from the System log
Get-WinEvent -LogName System -MaxEvents 20 |
Where-Object LevelDisplayName -eq 'Error' |
Select-Object TimeCreated, Id, Message
# Search for a specific Event ID across a date range
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 41
StartTime = (Get-Date).AddDays(-7)
} | Format-Table TimeCreated, Message -Wrap
A Real Example: Unexpected Reboots
Event ID 41 (“Kernel-Power”) in the System log means the machine rebooted without a clean shutdown — a classic sign of a power supply issue, an overheating CPU, or a driver crash. Cross-referencing its timestamp against Application log errors from the same moment usually points straight at the cause.