How to Check Windows App Logs: Event Viewer PowerShell and Tools Guide

When an app crashes, refuses to launch, or your system behaves oddly, being able to check application logs in Windows 11 or Windows 10 short‑circuits guesswork and gets you to a fix faster; this feature guide walks through the three practical methods — Event Viewer, command‑line (PowerShell/wevtutil), and trusted third‑party utilities — with step‑by‑step commands, troubleshooting workflows, and enterprise‑grade cautions.

Background / Overview​

Windows records a vast array of runtime activity in its built‑in Event Log system. Think of the Event Log as a structured, timestamped record of what the OS and well‑behaved applications choose to report: errors, warnings, informational messages, and security events. The three classic Windows log channels every troubleshooter should know are Application, System, and Security, and each entry typically includes a source, event ID, severity level, timestamp, and a human‑readable message.
Not every program writes to the Event Log — applications must be coded to do so — but most Windows components and many major third‑party applications do. Treat the Event Log as your first source of truth for crashes and service failures, and combine it with other traces (Reliability Monitor, Process Monitor, or a lightweight process start/stop logger) when normal exits or short‑lived processes aren’t appearing.

---

Understanding the Windows Event Logging System​

What the main logs contain​

• Application Log: Errors, warnings and information from user‑level applications and services that use the Windows logging API. This is where application crashes (for example, Event ID 1000) commonly surface.
• System Log: Messages generated by Windows components and drivers — start/stop service failures, driver crashes, and hardware‑level problems often appear here.
• Security Log: Auditing events such as logon attempts or resource access that are enabled through Group Policy or local audit settings.

Key fields to examine in every event​

• Source / Provider: Which application or component wrote the event.
• Event ID: A numerical identifier you can search for targeted explanations or vendor guidance.
• Level: Information, Warning, Error, or Critical — helps prioritize what to investigate first.
• Message / Details: The human‑readable description and additional XML details often containing stack traces or file/module names.

Note: Some claims you’ll read around the web — for example, that “every major application logs everything to the Event Log” — are not strictly verifiable across the ecosystem. Treat such statements cautiously and confirm by checking each app’s documentation or by monitoring process activity directly.

---

Method 1: Event Viewer (The visual approach)​

Event Viewer is the built‑in, GUI‑based log browser. It’s the simplest place to start for most users and gives you readable messages plus the XML details when you need them.

Opening Event Viewer​

• Press Win + R, type eventvwr.msc, and press Enter.
• Or right‑click Start → Event Viewer, or search “Event Viewer” from Start.

Navigate to the Application log​

• Expand Windows Logs in the left pane.
• Click Application. The center pane shows entries with the newest first.
  You’ll see colored icons indicating severity: blue/information, yellow/warning, and red/error.

Filter and find the events you need​

Event Viewer’s Filter Current Log… dialog is your friend. Use it to:

• Limit by time range (last hour / last 24 hours).
• Select Level (Error, Warning, Critical).
• Enter Event IDs (for crashes, common IDs include 1000, 1001, 1002).
• Filter by Source/Provider (for example, MsiInstaller or a vendor‑specific provider).

Pro tip: When chasing a crash, filter for Error level events in the Application log for the past 12–24 hours — it reduces noise fast.

Read and export event details​

• Double‑click an event to see the General (human‑readable) and Details (XML) tabs.
• For sharing with support, use Save All Events As… to export a .evtx file, or copy the XML details. Exporting preserves the original event metadata and avoids transcription mistakes.

Create Custom Views​

Save a reusable filter via Custom Views → Create Custom View. Include Application and System logs, target Event IDs and levels, and name the view (for example, “App Crashes & Startup Errors”) so you can reopen it later without reconfiguring filters.

---

Method 2: PowerShell and Command Line (The power user way)​

When you need automation, remote queries, or to handle large logs efficiently, turn to PowerShell and its event cmdlets. Use get‑style commands for quick inspection and scheduling.

Get-EventLog vs Get‑WinEvent​

• Get-EventLog is the older cmdlet (works but lacks modern channel support). Example:
  Get-EventLog -LogName Application -Newest 50
  Get-EventLog -LogName Application -EntryType Error -Newest 20
• Get‑WinEvent is modern, faster on big logs, and supports structured filters:
  Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2} -MaxEvents 50

Prefer Get‑WinEvent for Windows 10/11 and for programmatic scenarios.

Practical PowerShell snippets​

• Show the 50 most recent application events:
  Get-WinEvent -LogName Application -MaxEvents 50
• Filter for only errors in the last 24 hours:
  Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2} | Where-Object { $_.TimeCreated -gt (Get-Date).AddHours(-24) }
• Export to CSV:
  Get-WinEvent -LogName Application -MaxEvents 200 | Export-Csv C:\Logs\AppEvents.csv -NoTypeInformation

These commands are ideal for scheduled reporting, remote troubleshooting, and carrying out searches across multiple machines if you remote into them.

wevtutil (legacy command prompt)​

When you’re in a recovery console or prefer a compact command prompt tool, use wevtutil:

• Query recent events in text:
  wevtutil qe Application /c:50 /f:text
• Export an .evtx file:
  wevtutil epl Application C:\Logs\AppLog.evtx
• Clear a log (use with caution):
  wevtutil cl Application

wevtutil is available on all supported Windows versions and is useful when GUI/PowerShell aren’t an option.

---

Method 3: Third‑party and specialized tools​

For targeted views, faster exports, or deep forensic capture, several well‑known tools are helpful. Each trades convenience for different operational considerations.

NirSoft LastActivityView and FullEventLogView​

• LastActivityView consolidates multiple Windows traces into a simple table of recent activity and is portable (no install). It’s useful for quick timelines and CSV exports. fileciteturn0file8turn0file19
• FullEventLogView (NirSoft) shows Application, System and Security logs in a single table and exports to text/XML/HTML. Both are convenient but may trigger antivirus false positives due to their low‑level log access; verify downloads and checksums.

Microsoft Log Parser​

Log Parser treats event logs like database tables and accepts SQL‑style queries. It’s powerful for correlating events across logs or extracting specific columns for analysis. Example:
LogParser.exe "SELECT TimeGenerated, SourceName, Message FROM Application WHERE EventType = 2 ORDER BY TimeGenerated DESC" -i:EVT -o:NAT
This is especially helpful when you need to blend event log data with other structured inputs.

Process Monitor (Procmon) — Sysinternals​

For real‑time, high‑fidelity traces (process create/exit, registry access, file I/O), Procmon is the go‑to tool for IT professionals. Use strict filters (Process Create / Process Exit) and short sessions because Procmon generates very large traces quickly. Combine Procmon captures with Event Viewer entries for a complete picture.

---

Practical troubleshooting workflows​

Below are concrete, repeatable workflows you can apply when an application crashes or fails to start.

Scenario A — An app crashes on launch​

• Open Event Viewer → Application and filter for Error level events around the crash time. Look for Event ID 1000 (Application Error) and 1001 (Windows Error Reporting).
• Double‑click the error, read the Faulting application and Faulting module lines. Note exception codes (for example, 0xc0000005) — these narrow down access violations vs invalid instructions.
• If Event Viewer implicates a DLL, check whether that DLL belongs to a third‑party driver or antivirus. Update, roll back, or temporarily remove the driver/application to test.
• If the Event Log is inconclusive, run Procmon with filters for the target executable, reproduce the crash, and stop the trace. Export the trace and correlate file/registry errors to the Event Log timestamps.

Scenario B — You need a timeline of recently opened/closed apps​

• Use NirSoft LastActivityView for a quick human‑readable timeline, then confirm suspicious entries by searching Event Viewer for matching timestamps. Keep in mind normal exits aren’t always logged. fileciteturn0file19turn0file13

Exporting and sharing logs​

• Export .evtx from Event Viewer for forensic integrity.
• For spreadsheets or sharing with non‑Windows experts, export via PowerShell to CSV (Get‑WinEvent … | Export‑Csv).

---

Common Event IDs (cheat sheet)​

• 1000 — Application Error (crash).
• 1001 — Windows Error Reporting entry, often follows a 1000.
• 1002 — Application Hang (unresponsive).
• 1074 — User or process initiated shutdown/restart.
• 6005 / 6006 — Event Log service started / stopped (useful as boot/shutdown markers).
• 6008 / 41 (Kernel‑Power) — Unexpected shutdown / unclean reboot.
• 7000 / 7001 / 7009 / 7031 / 7034 — Service start/stop and timeout errors (System log).

These mappings are stable across recent Windows 10 and Windows 11 builds and form the basis for common filter presets used in Event Viewer and PowerShell. fileciteturn0file6turn0file16

---

Automating continuous logging and collection​

For persistent audit trails or multi‑machine collection, consider:

• A lightweight PowerShell WMI logger that registers for process start/stop events and writes to a secure file or central collector. A basic example registers Win32_ProcessStartTrace / Win32_ProcessStopTrace and appends timestamps and process names — useful for long‑term audits or troubleshooting recurring issues. Customize it to include user name, PID, or parent process for forensic context.
• Central collection with SIEM/EVENT collectors or scheduled PowerShell jobs that use Get‑WinEvent and push CSV/.evtx outputs to a secure server. This reduces manual data gathering across many systems.

Be mindful of storage and privacy: continuous logging produces large volumes of data and may capture sensitive user activity — secure logs, rotate them, and ensure retention policies align with your organization’s rules.

---

Security, privacy, and enterprise considerations​

• Third‑party tools (NirSoft, Procmon, portable utilities) may trigger endpoint protection. These detections are often false positives because the tools access system internals, but always verify binaries and checksums and coordinate with IT before running on managed endpoints. fileciteturn0file8turn0file19
• Log retention: Event logs have maximum sizes and rotation policies. If you need longer history, increase maximum log sizes or export logs regularly; otherwise, old events may be overwritten.
• Privacy & compliance: Logging user activity can fall under legal and policy restrictions; seek legal and IT guidance before enabling broad auditing on user devices.

---

Strengths, limitations, and risks — critical analysis​

Strengths:

• Built‑in tools (Event Viewer, PowerShell) provide authoritative, auditable system data without extra software.
• Command‑line tools scale for automation and remote work; PowerShell’s Get‑WinEvent handles modern channels reliably.
• Third‑party utilities deliver immediate, user‑friendly tables and exports for fast triage.

Limitations and risks:

• Normal app closures are often not logged. If you need complete start/stop coverage, you must enable continuous monitoring (PowerShell WMI logger, Procmon) or deploy endpoint agents — both of which increase storage and privacy costs.
• High data volume from real‑time captures like Procmon creates analysis complexity and storage considerations. Filter aggressively.
• Portable utilities and Sysinternals tools can be flagged by security scanners and may be restricted in corporate environments — always coordinate with IT, verify downloads, and keep hashes or signed installers on record. fileciteturn0file13turn0file19

When a claim is not universally verifiable — such as assertions that “Windows always logs every app open/close” — the correct stance is caution: verify in the target environment and supplement with dedicated monitoring when needed.

---

Quick reference — commands and recipes​

• Open Event Viewer: Win + R → eventvwr.msc.
• PowerShell: show recent application errors:
  Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2} -MaxEvents 50.
• Export app log to EVTX:
  wevtutil epl Application C:\Logs\AppLog.evtx.
• Procmon for process create/exit: add filters Operation is Process Create OR Process Exit; run as Admin and keep sessions short.
• Quick timeline via NirSoft LastActivityView — download official portable binary, verify checksums.

---

Final checklist: what to do when an app crashes​

• Capture the exact time the crash occurred.
• Open Event Viewer → Application and filter the closest timeframe for Error/Critical. Look for Event ID 1000/1001/1002.
• Export the event (.evtx or XML) and copy the faulting module and exception codes.
• If unclear, run Procmon with Process Create/Exit filters while reproducing the issue, then correlate timestamps.
• If the issue is recurring across many machines, script a Get‑WinEvent extraction and centralize results for pattern analysis.

---

Conclusion​

Knowing how to check application logs in Windows 11 and Windows 10 moves troubleshooting from guesswork to evidence‑driven diagnosis. Start with Event Viewer for approachable, contextual inspection; use PowerShell (Get‑WinEvent) and wevtutil for automation and remote diagnostics; and reach for NirSoft utilities, Log Parser, or Procmon when you need fast tables, SQL‑style analysis, or real‑time, forensic detail. Combine these tools with careful export practices, log retention planning, and security checks for third‑party binaries to build a reliable, auditable troubleshooting workflow that scales from single‑PC fixes to enterprise investigations. fileciteturn0file2turn0file8

---

By following the methods and workflows above, you’ll be equipped to pinpoint app crashes, recover context for support tickets, and set up repeatable diagnostics — all while balancing the operational tradeoffs of volume, privacy, and complexity inherent in system‑level logging. fileciteturn0file13turn0file18

---

Source: H2S Media How to Check Application Logs in Windows 11 or 10 - 3 Methods