Find Windows application crash logs with PowerShell
Create a local report of recent application crashes, hangs, system BugCheck events and dump-file metadata without opening dump contents or changing Windows Error Reporting.
Run the crash and hang diagnostic
pwsh -NoProfile -File .\Invoke-WindowsDiagnostics.ps1 `
-Crashes -PrivacyMode -ExportMarkdownThe command creates a local TXT report and an optional Markdown report. -PrivacyMode replaces common identifying values in the combined report, but the final file should still be reviewed before it is posted publicly.
When this guide is useful
- An application closes unexpectedly or displays a generic crash message.
- The same program freezes repeatedly and Windows reports that it stopped responding.
- A support engineer asks for recent crash events or dump-file information.
- You need to confirm whether a failure is isolated to one application or accompanied by a system BugCheck.
What the report checks
Application events
Recent Application Error, Windows Error Reporting and Application Hang metadata from the Windows Event Log.
System failures
Recent BugCheck events that may indicate a blue-screen or system-level crash rather than an application-only failure.
Dump metadata
File name, timestamp, size and source for recent Minidump, MEMORY.DMP and user CrashDumps files.
Findings summary
An aggregated WARN or ERROR item appears before the detailed event list when relevant evidence is found.
How to interpret Windows crash evidence
Look for repetition
Repeated application names, providers, event IDs and similar timestamps are more useful than a single isolated event. A cluster of failures from the same program can support an application-specific or vendor-specific investigation.
Separate application failures from system crashes
An Application Error or Application Hang event does not mean Windows itself crashed. A BugCheck event or fresh system dump is stronger evidence of a system-level failure and should be investigated separately.
Compare event time with the user-visible symptom
Match the report timestamps to the time the application closed or froze. Old events may be unrelated to the current problem, especially on systems with a long Event Log history.
Treat dump files as evidence, not a diagnosis
The toolkit lists dump metadata but never opens or analyzes the dump. Debugging a dump requires a separate debugger and suitable symbols.
What the toolkit does not do
- It does not restart or repair the application.
- It does not delete dumps or clear Event Logs.
- It does not change recovery, telemetry or Windows Error Reporting settings.
- It does not determine a root cause from a dump file.
Reasonable next steps
- Save the redacted report with the exact time and steps that reproduced the crash.
- Check whether the failure affects one application, several applications or the whole system.
- Attach only the relevant report excerpt to a vendor or project issue.
- For a BugCheck, preserve the dump and investigate it with an appropriate debugger or qualified support channel.