Windows Event Viewer Troubleshooting Checklist for IT Support

If you work help desk, Windows Event Viewer is not where you start every ticket. It is where you go when the obvious stuff is lying to you.

The short version: use Event Viewer to confirm when something failed, what Windows called the failure, which service or app was involved, and whether the same error keeps happening. Do not open it and start doom-scrolling through every red icon. That way lies madness, bad ticket notes, and a strong desire to become a goat farmer.

This checklist is for practical support work: app crashes, blue screens, failed logins, weird reboots, disk warnings, service failures, update problems, and tickets where the user says “it just stopped working” with the confidence of someone who has deleted the evidence.

For the bigger troubleshooting process, pair this with the senior IT troubleshooting methodology, the slow computer troubleshooting checklist, and the CompTIA A+ study plan if you are using this as exam practice.

When Event Viewer is actually useful

Event Viewer helps when you need evidence, timing, or repeated patterns.

Ticket symptom	Useful Event Viewer areas
App keeps crashing	Windows Logs → Application
Computer restarted unexpectedly	Windows Logs → System
User cannot sign in	Windows Logs → Security, plus domain controller logs if applicable
Service will not start	Windows Logs → System, Application and Services Logs
Windows Update keeps failing	Setup log, System log, WindowsUpdateClient operational log
Disk or storage weirdness	Windows Logs → System
Group Policy is not applying	GroupPolicy operational log
Blue screen or hard crash	System log, Reliability Monitor, memory dump location

The point is not to memorize every event ID. The point is to use logs to narrow the problem.

Event Viewer quick path

Open Event Viewer with one of these:

• Press Win + X → Event Viewer.
• Run eventvwr.msc.
• Search Start for Event Viewer.

Then start here:

1. Expand Windows Logs.
2. Check Application for app crashes.
3. Check System for drivers, services, disk, power, and update issues.
4. Check Security only when you need logon or audit events and have permission.
5. Use Filter Current Log instead of scrolling manually.
6. Match the event timestamp to the user-reported problem time.

That timestamp step is the difference between troubleshooting and reading Windows’ emotional diary.

Step 1: Get the real timeline first

Before reading logs, ask or confirm:

• When did the problem happen?
• Was the user actively doing something, or was the machine idle?
• Did it happen once or repeatedly?
• Did anything change before it started: update, install, password change, docking station, VPN, new monitor, new printer?
• Is the problem user-specific, device-specific, or app-specific?

Write down the approximate time window. Then filter logs around that window.

In Event Viewer:

1. Right-click the relevant log.
2. Choose Filter Current Log.
3. Set a time range around the issue.
4. Start with Critical, Error, and Warning.
5. Expand the time range only if nothing useful appears.

Do not treat every old error as relevant. Windows machines collect stale errors like junk drawers collect HDMI cables.

Step 2: Check Application for crashes

Use Windows Logs → Application when a program closes, freezes, or throws a vague error.

Look for:

• Application Error events.
• .NET Runtime errors.
• App-specific sources like Outlook, Teams, Chrome, vendor agents, backup tools, or line-of-business software.
• Repeated failures with the same faulting module.

Useful details to capture:

• Faulting application name.
• Faulting module name.
• Exception code.
• Event time.
• Whether it happens for one user or all users.

Example ticket note:

Event Viewer shows repeated Application Error events for outlook.exe at 9:13 AM and 9:16 AM. Faulting module is an add-in DLL. Outlook opens in safe mode without crashing, so next step is disabling the add-in and retesting.

That is much better than “Outlook broken, rebooted PC.”

Step 3: Check System for device, driver, service, and power issues

Use Windows Logs → System when the whole machine is unstable.

Common things worth noticing:

• Service Control Manager errors when a Windows service fails to start.
• Disk, Ntfs, or storahci warnings that point toward storage trouble.
• Kernel-Power events after unexpected shutdowns.
• Display driver resets when monitors blink or the screen goes black.
• WLAN-AutoConfig events for wireless drops.
• Time-Service issues when authentication or domain trust gets weird.

Be careful with Kernel-Power. It usually means Windows noticed an improper shutdown. It does not automatically tell you why. Power loss, forced reboot, blue screen, overheating, firmware, or a user holding the power button can all land there.

If the ticket is about sluggish performance, compare this with the slow computer troubleshooting checklist before blaming the scariest red icon.

Step 4: Check Security only when it fits the ticket

The Security log is useful for logons, lockouts, privilege use, and audit events. It is also noisy and may be restricted by policy.

Use it when investigating:

• Failed logons.
• Account lockouts.
• Suspicious local sign-in attempts.
• Service accounts using stale passwords.
• Permission changes.
• Local admin activity.

For account lockouts, Event Viewer on the user’s workstation may not be enough. You may need domain controller logs, identity provider logs, or your SIEM. The practical help desk move is to identify the likely stale credential source: old phone mail profile, saved mapped drive password, scheduled task, VPN client, remote desktop session, or a forgotten service.

For a dedicated workflow, use the account lockout troubleshooting checklist.

Step 5: Use custom views for repeat tickets

If you troubleshoot the same kind of issue often, make Event Viewer less annoying.

Create a custom view for:

• Critical and Error events from the last 24 hours.
• Application crashes.
• Disk and storage warnings.
• Service Control Manager failures.
• Windows Update failures.

Path:

1. Right-click Custom Views.
2. Choose Create Custom View.
3. Pick the log, event levels, and sources.
4. Save it with a plain name like Recent App Crashes.

This is especially useful on shared support machines or when training newer technicians. You are not making Windows less weird; you are making the weird easier to sort.

Step 6: Know the events that matter more often

You do not need a tattoo of event IDs. But these categories come up a lot:

What you see	What it usually means
Application Error	A program crashed or stopped responding
Service Control Manager	A service failed, timed out, or depended on another failed service
Disk / Ntfs warnings	Possible storage, filesystem, cable, or driver issue
Kernel-Power	Windows recovered from an improper shutdown
WindowsUpdateClient	Update detection, download, install, or failure events
GroupPolicy	Policy processing succeeded, failed, or timed out
WLAN-AutoConfig	Wireless connection attempts and failures
User Profile Service	Profile load, temporary profile, or profile corruption problems

The pattern matters more than one event. One random warning from three weeks ago is trivia. Five matching errors around the exact failure time is evidence.

Step 7: Turn logs into useful ticket notes

Bad ticket note:

Checked Event Viewer. Errors found.

Useful ticket note:

Checked Event Viewer around 10:20 AM when user reported crash. Application log shows three Teams.exe crashes with same faulting module. System log shows no disk or power errors during that window. Cleared Teams cache, updated client, and asked user to retest on next call.

A good Event Viewer note includes:

• Log checked.
• Time window.
• Event source.
• Relevant error or pattern.
• What you ruled out.
• Next action.

This protects the next tech from starting over. It also makes you look like you did actual troubleshooting instead of sacrificing a reboot to the desktop gods.

Common mistakes

Mistake 1: Treating every red icon as the cause

Event Viewer shows normal background failures too. Windows services retry. Apps complain. Drivers whine. Match logs to the symptom and timeline.

Mistake 2: Ignoring Reliability Monitor

For user-facing crashes, Reliability Monitor is often friendlier than Event Viewer. Run perfmon /rel and look at the timeline. It can show app crashes, Windows failures, driver installs, and updates in a cleaner view.

Mistake 3: Forgetting the basics

Logs are not a substitute for simple checks. If the app fails because the user has no network, Event Viewer may show a pile of app errors that are downstream noise. Use logs after confirming power, network, user scope, recent changes, and reproduction steps.

Mistake 4: Not exporting evidence

For escalations, attach useful screenshots or exported events. Right-click the event and use Save Selected Events if your process allows it. Include the event text in the ticket when screenshots are painful or your ticketing system mangles attachments because of course it does.

Mini checklist for the next ticket

Use this quick runbook:

1. Confirm the symptom and time window.
2. Check Application for app-specific crashes.
3. Check System for service, driver, disk, power, and update errors.
4. Check Security only if the ticket involves sign-in, lockout, or audit activity.
5. Filter by time and severity.
6. Look for repeated patterns, not isolated ancient warnings.
7. Compare findings with Reliability Monitor.
8. Document the source, event, timestamp, and next action.
9. Escalate with evidence if the issue points to infrastructure, identity, endpoint management, or vendor software.

FAQ

Should I clear Event Viewer logs after fixing a problem?

Usually no. Clearing logs removes useful history. If your organization has a process for clearing a specific test machine log, follow it. Otherwise, leave logs alone and document what you changed.

Are Event Viewer errors always serious?

No. Some errors are routine background noise. Serious means repeated, current, tied to the symptom, or related to critical systems like disk, authentication, services, drivers, or security.

What should I use with Event Viewer?

Use Reliability Monitor, Task Manager, Resource Monitor, PowerShell, vendor logs, endpoint management tools, and your ticket history. Event Viewer is one source of evidence, not the entire investigation.

Is this useful for CompTIA A+?

Yes. A+ expects you to understand structured troubleshooting, Windows tools, services, logs, startup issues, and operational documentation. You do not need to memorize every event ID, but you should know when logs help and how to explain what you found.

Bottom line

Event Viewer is useful when you treat it like evidence, not a haunted house. Start with the user’s timeline, filter hard, look for repeated patterns, and turn what you find into clear ticket notes.

If you are building support skills, read the troubleshooting interview questions guide next and practice explaining your process out loud. That one habit makes logs, tickets, and interviews all easier.