Windows Event Viewer for Developers: Find Application Errors, Service Failures, and Startup Problems

Overview

Event Viewer is a built-in Windows tool for reading event logs generated by the operating system, installed services, drivers, applications, and developer platforms. It is most useful when an application exits unexpectedly, a Windows service will not start, an installer rolls back, a scheduled task stops, or a local development stack behaves differently after a reboot.

Open it by searching for Event Viewer from the Start menu. You can also launch it with eventvwr.msc. The most relevant locations are:

• Windows Logs > Application: application crashes, runtime errors, installer activity, and messages from registered application providers.
• Windows Logs > System: service starts and stops, driver problems, boot-related issues, and operating-system components.
• Applications and Services Logs: more specific channels for Windows components and installed platforms. .NET, IIS-related components, task scheduling, and other products may place useful events here.

Event Viewer is not a replacement for application logging, debugger output, Windows Error Reporting data, or service-specific logs. Treat it as one layer in an investigation. A useful incident record normally combines the Event Viewer entry with the application log, command-line output, configuration, and the exact time the failure occurred.

A quick event-severity guide

What to track

Do not begin by reading every event in a log. Define the failure window and track a small set of fields for each relevant event:

• Time created: record the local time and time zone. Compare it with application logs, CI output, browser requests, or deployment records.
• Log and provider: the channel and component that produced the event often tell you which subsystem to investigate next.
• Event ID and level: these provide a stable way to group repeated failures. An ID is meaningful only with its provider and event text.
• Task category and keywords: when available, these add context about the operation that failed.
• General and Details views: read the human-readable message, then inspect XML when you need exact fields, computer names, process information, or embedded data.
• Frequency: one isolated error may differ from an error repeated every minute or after every service restart.
• Preceding events: the first warning or dependency failure is often more useful than the final generic crash message.

For an application failure, check Application first and then review any custom channel belonging to the runtime or framework. For a Windows service failure, inspect both System and Application; the Service Control Manager may record the state change while the service itself records the underlying exception elsewhere. For startup problems, include events immediately before and after boot or login rather than searching only for the word “error.”

Common provider and event-ID examples can help narrow a search, but they should not be treated as universal diagnoses. Application Error, .NET Runtime, Windows Error Reporting, and Service Control Manager may appear in different combinations depending on the program and Windows configuration. Always confirm the provider, message, timestamp, and affected executable.

Filter the log instead of browsing it

In Event Viewer, right-click a log and choose Filter Current Log. Set a time range first, then add one or more levels, providers, or event IDs. Use Find for a distinctive executable, service name, module, or error phrase. Once a useful filter is established, choose Save Filter to Custom View so the same investigation can be repeated.

PowerShell is more efficient for recurring checks. For example:

Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-4)} |
  Where-Object {$_.LevelDisplayName -in 'Error','Critical'} |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

To examine a specific provider or event ID, add ProviderName or Id to the filter hashtable. To inspect available channels, use Get-WinEvent -ListLog *. Some logs require an elevated PowerShell session, and a channel may be disabled or unavailable on a particular machine.

Export evidence before clearing logs or changing configuration. In Event Viewer, select the log and choose Save All Events As, then retain the resulting .evtx file. From an elevated command prompt, an equivalent approach is:

wevtutil epl Application C:\Temp\Application-before-fix.evtx

Store exports with the incident date, machine name, and failure description. Review them for secrets or personal data before sharing them outside the team.

Cadence and checkpoints

Use Event Viewer reactively during an incident, but also establish a lightweight review cadence for machines that host local services, build agents, test environments, or developer infrastructure.

During an incident

1. Write down what failed, when it failed, and whether the failure is repeatable.
2. Capture the current application and system logs before restarting repeatedly.
3. Filter the relevant time window and note the earliest related warning or error.
4. Compare Event Viewer timestamps with application logs, service output, deployment activity, and recent configuration changes.
5. Export the relevant log and record the exact command, fix, or rollback used.

Monthly or quarterly maintenance review

For a development workstation, a monthly review is usually enough to spot recurring service failures without turning log inspection into a daily task. For a shared build machine, test host, or local server, review more frequently when the machine is business-critical or changes often. Check for repeating providers, identical event IDs, failed starts, unexpected restarts, and a rising number of warnings around the same component.

Keep a small incident table with the date, machine, service or executable, provider, event ID, frequency, suspected cause, and resolution. This turns isolated troubleshooting into a history that can reveal patterns after updates, dependency changes, certificate renewals, or environment resets.

How to interpret changes

An event is evidence, not automatically the root cause. Use a simple decision path:

• The application crashed: compare Application events with the application’s own logs. Look for the executable, faulting module, runtime message, and whether the crash follows a specific input or deployment.
• A service failed to start: check the service-control event, then inspect the service’s executable path, account permissions, dependencies, port usage, configuration, and application log.
• The service starts and then stops: determine whether it is a one-shot worker, a crash, a dependency timeout, or an intentional shutdown. Repeated start-stop cycles are more informative than one stop event.
• The failure occurs after boot: correlate boot timing with startup tasks, network availability, mounted drives, credentials, and dependency services.
• WSL or Docker Desktop is involved: use Event Viewer for Windows-side symptoms, but also inspect the distribution, container, daemon, or platform-specific logs. A Windows event may show that a host component failed without containing the application’s actual error.
• No matching event exists: verify the time zone, channel, provider registration, log size and retention settings, and whether the process writes only to a file, terminal, or centralized logging system.

When investigating a network-related failure, Event Viewer should be paired with a focused connectivity workflow. The guide Debugging Localhost on Windows covers ports, hosts files, DNS, firewall rules, IIS, and WSL. For crashes that need a dump rather than an event summary, see Windows Crash Dump Analysis for Developers.

Format your notes so another person can reproduce the reasoning: “At 14:32, provider X reported event Y; at 14:33, the service stopped; the application log contained Z; after reverting configuration A, no new event appeared.” This is more useful than labeling an event “the cause” without testing the relationship.

When to revisit

Revisit this workflow whenever a Windows release, runtime, IDE, service, container platform, or logging configuration changes. Provider names, available channels, event wording, and the location of product-specific logs can vary between versions. Update saved custom views and PowerShell filters if a provider changes or an event ID no longer appears.

Schedule a monthly or quarterly checkpoint for machines that regularly run development services. At each checkpoint:

1. Review the incident table for repeated providers, IDs, services, and timestamps.
2. Run saved Event Viewer views or PowerShell queries for recent errors and critical events.
3. Confirm that important application and service logs are being retained long enough to investigate failures.
4. Test that an EVTX export can be created and that the team knows where to store it securely.
5. Remove obsolete custom views and update notes after changing runtimes, WSL distributions, IIS sites, Docker components, or service definitions.

Before opening a bug report, collect the smallest useful evidence bundle: a precise timeline, filtered event details, the relevant application log, reproduction steps, recent changes, and an EVTX export when appropriate. If your Windows environment itself needs a broader maintenance pass, use the Windows Developer Setup and Maintenance Checklist. For command automation, the PowerShell reference for developers can help turn recurring checks into repeatable commands.