Event Viewer Troubleshooting Guide (2026) |

Why Every Helpdesk Tech Needs to Master Event Viewer

When a user calls in saying their PC crashed, an app stopped working, or they can't log in, your first instinct should be: "What does the Event Viewer say?" Honestly, Windows Event Viewer is probably the single most underused diagnostic tool on any helpdesk. It records every crash, every failed login, every driver failure, and every service hiccup — all with timestamps and error codes that point you straight to the root cause.

The problem? Most helpdesk guides either stop at "here's how to open Event Viewer" or jump straight into deep security forensics. This guide bridges that gap.

We're covering the exact Event IDs you'll run into on a typical helpdesk shift, the PowerShell commands that let you pull logs remotely without bugging the user, and the filtering techniques that separate actionable errors from background noise. So, let's dive in.

How to Open Event Viewer

There are a few ways to launch Event Viewer on Windows 10 and Windows 11. Use whichever fits your workflow best:

Run dialog: Press Win + R, type eventvwr.msc, press Enter.
Start menu search: Type "Event Viewer" and click the result.
Power User menu: Press Win + X and select Event Viewer.
Command Prompt or PowerShell: Run eventvwr from any terminal window.
Computer Management: Right-click This PC → Manage → expand System Tools → Event Viewer.

For remote access — which, let's be honest, is what helpdesk teams actually need 90% of the time — right-click Event Viewer (Local) in the left pane and select Connect to Another Computer. Enter the hostname or IP address of the remote machine. You'll need admin privileges and the Remote Event Log Management firewall rule enabled on the target.

Understanding the Event Viewer Interface

The Event Viewer window is split into three panes:

Left pane (Console Tree): A folder hierarchy of log categories. The ones you'll use 90% of the time live under Windows Logs.
Center pane (Event List + Detail): The top half shows events as rows; click one and the details show up in the bottom half.
Right pane (Actions): Context-sensitive actions like filtering, exporting, and attaching tasks to events.

The Five Core Windows Logs

Log	What It Records	When You Need It
Application	Events from installed software — crashes, errors, warnings from apps like Office, SQL Server, and third-party tools	User reports an application crash or freeze
Security	Login attempts (success and failure), privilege escalation, audit policy changes	Account lockouts, unauthorized access attempts, failed logins
System	OS-level events — driver failures, service start/stop, hardware errors, unexpected shutdowns	Blue screens, slow boots, service failures, hardware issues
Setup	Windows Update installations, feature upgrades, component changes	Issues after a Windows update or feature upgrade
Forwarded Events	Events collected from remote machines via subscriptions	Centralized monitoring in larger environments

Event Severity Levels

Every event has a severity level. Here's what each means and how you should prioritize them:

Level	Icon	Meaning	Helpdesk Priority
Critical	Red circle with X	A fatal failure occurred — a component stopped working entirely	Investigate immediately
Error	Red circle with X	A significant problem occurred, but the system kept running	Investigate within your SLA
Warning	Yellow triangle	Not a failure yet, but something that needs attention before it becomes one	Monitor and address proactively
Information	Blue circle with i	Normal operation — a task completed successfully	Ignore unless you're correlating with other events
Audit Success/Failure	Key icon	Security audit results (login success, login failure, etc.)	Check during account lockout investigations

The 20 Event IDs Every Helpdesk Tech Should Know

You don't need to memorize thousands of Event IDs. Seriously, don't even try. These 20 cover the vast majority of tickets that land on a typical helpdesk queue, and they're organized by the scenario you're troubleshooting.

System Crashes and Unexpected Shutdowns

Event ID	Source	Log	What It Means
41	Kernel-Power	System	The system rebooted without a clean shutdown. This is your go-to event for investigating BSODs, power losses, and hard hangs. Check the `BugcheckCode` field — a value of `0` means a power loss or hard freeze, not a blue screen.
1001	Windows Error Reporting	Application	A detailed crash report was generated. It contains the faulting module name, exception code, and offset. Cross-reference this with Event ID 41 to get the full BSOD picture.
6008	EventLog	System	The previous system shutdown was unexpected. Gets logged when Windows starts up after an unclean shutdown. The timestamp tells you exactly when it happened.
6013	EventLog	System	System uptime in seconds. Super useful for verifying when a machine was last rebooted — especially when users claim "I already restarted it." (We've all been there.)

Application Crashes and Hangs

Event ID	Source	Log	What It Means
1000	Application Error	Application	An application crashed. The details include the faulting application name, version, module name, and exception code. This is the first event to check when someone says "the app just closed on me."
1002	Application Hang	Application	An application stopped responding and was terminated. If this keeps happening for the same app, it probably needs an update, a reinstall, or has a compatibility issue.

Login Failures and Account Lockouts

Event ID	Source	Log	What It Means
4624	Security	Security	Successful logon. The `Logon Type` field tells you how they logged in: Type 2 = interactive (at the keyboard), Type 3 = network, Type 7 = unlock, Type 10 = RDP.
4625	Security	Security	Failed logon. The `Status` and `Sub Status` codes reveal why: `0xC000006D` = bad username or password, `0xC0000234` = account locked, `0xC0000072` = account disabled.
4740	Security	Security	A user account was locked out. This event shows up on the domain controller and includes the `Caller Computer Name` — the machine that triggered the lockout. This is hands-down the most useful event for solving recurring lockout tickets.
4771	Security	Security	Kerberos pre-authentication failed. Often the real culprit behind AD lockouts. The `Client Address` field reveals which device sent the bad password.

Service Failures

Event ID	Source	Log	What It Means
7036	Service Control Manager	System	A service entered the running or stopped state. Handy for confirming that a service restart actually happened.
7031	Service Control Manager	System	A service terminated unexpectedly. The event includes the service name and crash count. Check the recovery actions configured for the service.
7034	Service Control Manager	System	A service terminated unexpectedly and has already done so a specified number of times. This usually means the configured recovery actions have been exhausted — time to dig deeper.

Disk and Storage Issues

Event ID	Source	Log	What It Means
7	Disk	System	A bad block was found on the disk. One or two of these might be tolerable, but a pattern strongly suggests a failing drive. Escalate for hardware replacement.
11	Disk	System	The driver detected a controller error on the device. Often points to a failing SATA cable, a flaky USB connection, or hardware degradation.
51	Disk	System	An error was detected during a paging operation. This can cause data corruption and is a strong indicator the drive needs replacing.

Windows Update Issues

Event ID	Source	Log	What It Means
19	WindowsUpdateClient	System	A Windows update was successfully installed. Confirms that a patch actually got applied.
20	WindowsUpdateClient	System	A Windows update installation failed. The error code in the details tells you why (e.g., insufficient disk space, corrupted component store).

Filtering Events Like a Pro

An unfiltered event log is essentially useless. Thousands of informational events will bury the actual errors you need. Here's how to cut through the noise.

Quick Filter: Errors and Warnings Only

In the left pane, select the log you want (e.g., System).
In the right pane, click Filter Current Log.
Under Event level, check Critical, Error, and Warning.
Under Logged, select Last 24 hours (or whatever timeframe makes sense).
Click OK.

That alone will cut out probably 80% of the noise.

Filter by Event ID

If you know the Event ID you're looking for, type it directly into the Event IDs field in the filter dialog. You can enter multiple IDs separated by commas (e.g., 41, 1001, 6008) or ranges (e.g., 4624-4625). To exclude an ID, prefix it with a minus sign (e.g., -10016 to hide those annoyingly noisy DCOM errors).

Create Saved Custom Views

Custom Views are saved filters that persist across sessions. I'd recommend creating one for each common troubleshooting scenario you deal with regularly:

Right-click Custom Views in the left pane → Create Custom View.
Configure your filter (time range, event levels, event IDs, sources).
Give it a descriptive name like "BSOD Investigation" or "Account Lockouts".
Click OK.

Here are the custom views I'd set up on any helpdesk workstation:

System Crashes: System log, Event IDs 41, 1001, 6008 — Critical and Error level
App Crashes: Application log, Event IDs 1000, 1002 — Error level
Login Failures: Security log, Event IDs 4625, 4740, 4771 — all levels
Service Failures: System log, Event IDs 7031, 7034 — Error level
Disk Health: System log, Event IDs 7, 11, 51 — Warning and Error level

Querying Event Logs Remotely with PowerShell

The Event Viewer GUI is fine for a single machine, but PowerShell is how you scale this stuff. These commands let you pull logs from a remote PC without walking to the desk or interrupting the user. All commands require WinRM to be enabled on the target machine (it's on by default in domain-joined environments, so you're probably good).

Get Recent Errors from a Remote Machine

# Pull the 20 most recent errors from the System log on a remote PC
Get-WinEvent -ComputerName "PC-USERNAME01" -FilterHashtable @{
    LogName   = 'System'
    Level     = 2  # 1=Critical, 2=Error, 3=Warning
    StartTime = (Get-Date).AddHours(-24)
} -MaxEvents 20 | Format-Table TimeCreated, Id, Message -Wrap

Check for BSODs and Unexpected Shutdowns

# Find BSOD and unexpected shutdown events on a remote machine
Get-WinEvent -ComputerName "PC-USERNAME01" -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-Power', 'EventLog'
    Id           = 41, 6008
    StartTime    = (Get-Date).AddDays(-7)
} | Format-List TimeCreated, Id, Message

Find the Source of Account Lockouts

# Run this on the PDC Emulator domain controller
$PDC = (Get-ADDomainController -Discover -Service PrimaryDC).HostName
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
} -MaxEvents 50 | ForEach-Object {
    [PSCustomObject]@{
        Time     = $_.TimeCreated
        User     = $_.Properties[0].Value
        Source   = $_.Properties[1].Value
    }
} | Format-Table -AutoSize

Check Application Crashes for a Specific App

# Find all crashes of a specific application (e.g., Outlook)
Get-WinEvent -ComputerName "PC-USERNAME01" -FilterHashtable @{
    LogName = 'Application'
    Id      = 1000
    StartTime = (Get-Date).AddDays(-7)
} | Where-Object { $_.Message -like '*OUTLOOK*' } |
    Select-Object TimeCreated, @{N='FaultingModule';E={$_.Properties[3].Value}},
    @{N='ExceptionCode';E={$_.Properties[6].Value}} |
    Format-Table -AutoSize

Export Events to CSV for Escalation

# Export filtered events to CSV for a ticket attachment
Get-WinEvent -ComputerName "PC-USERNAME01" -FilterHashtable @{
    LogName = 'System'
    Level   = 1, 2  # Critical and Error
    StartTime = (Get-Date).AddDays(-3)
} | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message |
    Export-Csv -Path "C:\Temp\PC-USERNAME01_events.csv" -NoTypeInformation

Real-World Troubleshooting Workflows

Knowing what Event IDs mean is only half the battle. Here's where it all comes together — step-by-step workflows for the most common ticket types where Event Viewer is your primary tool.

Workflow 1: "My PC Keeps Crashing" (BSOD Investigation)

Open the System log and filter for Event IDs 41 and 6008 in the last 7 days.
For each Event ID 41, check the BugcheckCode field. If it's 0, the crash was a power failure or hard hang — not actually a blue screen. If it's a hex value like 0x0000001E, search that code for the specific BSOD cause.
Switch to the Application log and look for Event ID 1001 (Windows Error Reporting) at the same timestamp. This contains the faulting driver or module name.
Check the System log for Event IDs 7, 11, or 51 (disk errors) around the same time. Disk failures often trigger BSODs, and this is one of those things people overlook.
If the faulting module is a driver (.sys file), update or roll back that driver. If it's a system file, run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth.

Workflow 2: "I Keep Getting Locked Out" (Account Lockout)

Account lockouts are probably the most frustrating recurring tickets. Here's how to actually track them down:

Identify the PDC Emulator for the domain: run netdom query fsmo from any domain-joined machine.
On the PDC Emulator, filter the Security log for Event ID 4740 with the affected username.
Read the Caller Computer Name field — that's the machine sending bad credentials.
On that machine, check for Event ID 4625 in the Security log. The Logon Type tells you what's trying to authenticate (Type 3 = mapped drive or service, Type 10 = RDP).
Common culprits: cached credentials in mapped drives, saved RDP connections, scheduled tasks running under the old password, and (this one gets people all the time) mobile devices with stale Exchange ActiveSync profiles.

Workflow 3: "This App Keeps Crashing" (Application Failure)

Filter the Application log for Event ID 1000 with the application name.
Note the Faulting Module — if it's a DLL from the application itself, the app needs a repair or reinstall. If it's a Windows DLL (like ntdll.dll or kernelbase.dll), you're likely dealing with a compatibility problem or corrupt system file.
Check for Event ID 1002 (hang) events for the same app — frequent hangs followed by crashes usually point to a resource contention issue (low memory, disk I/O bottleneck).
Look for Event ID 11707 or 11724 (install/uninstall success) to verify the app was installed correctly.
If the faulting module is a third-party DLL, check whether a recent Windows update might have introduced a compatibility issue.

Workflow 4: "My PC Is Slow After Startup" (Service Failure)

Filter the System log for Event IDs 7031, 7034, and 7036 in the first 5 minutes after boot.
If a critical service crashed at startup (7031), check which service it was. Common offenders include Windows Search, Print Spooler, BITS, and third-party endpoint protection agents.
Verify the service is set to Automatic startup and that its recovery actions are configured to restart it.
Check for Event ID 7023 (service terminated with an error) — the error code in the message reveals why the service failed.

Windows 11 24H2: Event Viewer Changes Worth Knowing

Windows 11 version 24H2 introduced several changes that affect how events are logged. If you're starting to see 24H2 machines in your fleet, keep an eye out for these:

New DHCP client behavior: The updated DHCP stack in 24H2 generates different event patterns when IP acquisition fails. If you see Event ID 1003 from the Dhcp-Client source after upgrading machines, this is the new client reporting it couldn't obtain a lease. Check DHCP option types on your server — Microsoft changed how certain options (particularly text vs. string types) are parsed.
Secure Boot Event ID 1032: Machines approaching the June 2026 Secure Boot certificate expiration may start logging new warnings under the TPM-WMI source. Worth monitoring so you can catch machines that need certificate rotation before the deadline hits.
Enhanced Credential Guard logging: 24H2 added new Event IDs (13–17) under the Microsoft-Windows-Credential Guard source. These give you much better visibility into Credential Guard status and failures — a nice improvement if you're running Credential Guard in your environment.

Tips for Getting the Most Out of Event Viewer

Always note the timestamp first. Before you even open Event Viewer, ask the user exactly when the problem happened. This narrows your search from thousands of events to a handful.
Look at what happened just before the error. The events in the 30 seconds leading up to a crash often reveal the actual trigger. Scroll up from the error event — the answer is usually sitting right there.
Ignore Event ID 10016 (DistributedCOM). This is the noisiest, most irrelevant error in most environments. Microsoft has acknowledged it as cosmetic in many cases. Don't waste your time on it unless you have a specific DCOM-dependent application that's actually failing.
Use Reliability Monitor for a quick overview. Press Win + R, type perfmon /rel, and press Enter. Reliability Monitor gives you a visual timeline of failures — it's perfect for spotting patterns at a glance before diving into Event Viewer details.
Attach events to tasks for proactive alerting. Right-click any event → Attach Task To This Event. You can set it up to send an email or run a script when a specific Event ID fires. This turns Event Viewer from a reactive tool into a proactive monitoring system (and honestly, more helpdesks should be doing this).
Correlate across logs. A single error in the Application log often has corresponding events in the System log. Always check both when investigating — the full story is rarely in just one log.

Frequently Asked Questions

How do I find out what caused a blue screen using Event Viewer?

Open Event Viewer and head to Windows Logs → System. Filter for Event ID 41 (Kernel-Power) around the time of the crash. The BugcheckCode field contains the BSOD stop code. Then check the Application log for Event ID 1001 at the same timestamp — that's where you'll find the faulting driver or module name. Search the BugcheckCode value (e.g., 0x0000007E) along with the faulting module to find the specific fix.

Can I view Event Viewer logs from another computer remotely?

Absolutely. In the Event Viewer GUI, right-click Event Viewer (Local) and select Connect to Another Computer. Enter the remote machine's hostname. Or, use PowerShell's Get-WinEvent -ComputerName parameter for faster, scriptable remote access. Both methods require admin privileges and that WinRM or the Remote Event Log Management firewall rule is enabled on the target.

Why are there so many errors in Event Viewer — is my PC broken?

Almost certainly not. It's completely normal for Event Viewer to contain hundreds of errors and warnings, and many of them are harmless or cosmetic. Event ID 10016 (DistributedCOM) shows up on virtually every Windows machine and rarely means anything is wrong. Focus only on errors that correlate with the specific issue you're troubleshooting, match the reported timeframe, and recur in a pattern. Isolated, one-time errors can usually be safely ignored.

How long does Windows keep Event Viewer logs?

By default, each Windows log file maxes out at 20 MB, and when it fills up, older events get overwritten. On a busy machine, that might only give you a few days of history. You can bump up the log size by right-clicking a log → Properties → changing the Maximum log size. For helpdesk purposes, setting the System and Application logs to 64–128 MB gives you several weeks of history without any real disk impact.

What's the difference between Get-WinEvent and Get-EventLog in PowerShell?

Get-EventLog is the legacy cmdlet that only works with classic Windows logs (Application, System, Security) and isn't available in PowerShell 7+. Get-WinEvent is the modern replacement — it works with all log types including Applications and Services logs, supports advanced XML queries, runs faster on large log files, and works in both Windows PowerShell 5.1 and PowerShell 7. Always use Get-WinEvent for new scripts.