The essentials

Quick reference

One focused task per row. Jump to the related section for complete, working examples.

UseSyntaxExamples
Read recent WER eventsGet-WinEvent -FilterHashtable @{ LogName='Application'; ` ProviderName='Windows Error Reporting'; ` StartTime=(Get-Date).AddHours(-4) } -MaxEvents 100View examples
Read application crash eventsGet-WinEvent -FilterHashtable @{ LogName='Application'; ` ProviderName='Application Error'; ` StartTime=(Get-Date).AddHours(-4) } -MaxEvents 100View examples
Read bug-check eventsGet-WinEvent -FilterHashtable @{ LogName='System'; ` Id=1001; StartTime=(Get-Date).AddDays(-7) } -MaxEvents ` 50View examples
Inspect kernel dump settingsGet-ItemProperty -LiteralPath ` 'HKLM:/SYSTEM/CurrentControlSet/Control/CrashControl'View examples
Inspect page-file usageGet-CimInstance -ClassName 'Win32_PageFileUsage' | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsageView examples
Inspect MEMORY.DMP metadataGet-Item -LiteralPath (Join-Path $env:SystemRoot 'MEMORY.DMP') | Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtcView examples
List recent user dumpsGet-ChildItem -LiteralPath (Join-Path $env:LOCALAPPDATA 'CrashDumps') -Filter '*.dmp' | Sort-Object LastWriteTimeUtc -DescendingView examples
Hash a dump artifactGet-FileHash -LiteralPath ` 'C:/CrashEvidence/App_260812_101500.dmp' -Algorithm ` SHA256View examples
Inspect LocalDumps policyGet-ItemProperty -LiteralPath ` 'HKLM:/SOFTWARE/Microsoft/Windows/Windows Error Reporting/LocalDumps' ` -ErrorAction SilentlyContinueView examples
Inspect per-app LocalDumpsGet-ItemProperty -LiteralPath ` 'HKLM:/SOFTWARE/Microsoft/Windows/Windows Error Reporting/LocalDumps/MyApp.exe' ` -ErrorAction SilentlyContinueView examples
Plan exception captureprocdump.exe -ma -e -n 1 -w 'MyApp.exe' ` 'C:/CrashEvidence'View examples
Cancel ProcDump monitoringprocdump.exe -cancel 4321View examples
Validate dump structuredumpchk.exe 'C:/CrashEvidence/App_260812_101500.dmp'View examples
Open a dump in WinDbgwindbg.exe -z 'C:/CrashEvidence/App_260812_101500.dmp'View examples
Set Microsoft symbol cache.symfix C:\Symbols; .reload /fView examples
Run verbose analysis!analyze -vView examples
Select exception context.ecxr; kvView examples
List loaded moduleslm t nView examples

Crash dumps are snapshots of process or kernel memory, not harmless log files. They can contain credentials, personal data, encryption material, and proprietary content, and capture can pause a process or consume substantial disk space. First identify whether the failure is user-mode or a system bug check, preserve timestamps and hashes, then analyze a copy with matching binaries and trusted symbols. Never force a crash or attach a debugger to production without an approved outage and recovery plan.

Step by step

Detailed examples

01

Classify the failure and preserve a UTC timeline first

An application crash, hang, service termination, restart, and kernel bug check require different evidence. Capture the exact host, UTC window, user-visible symptom, process or service identity, recent deployments, Application Error and WER events, and System bug-check or unexpected-shutdown events before changing configuration. Event ID alone is not globally unique, so retain ProviderName and Message. Reading protected logs can require elevation; it changes no state and needs no reboot or WhatIf.

Build a bounded crash timeline
$start = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{ LogName='Application'; StartTime=$start } -MaxEvents 300 | Where-Object ProviderName -in 'Application Error','Windows Error Reporting' | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message
Get-WinEvent -FilterHashtable @{ LogName='System'; StartTime=$start } -MaxEvents 300 | Where-Object Id -in 41,1001,6008 | Select-Object TimeCreated, ProviderName, Id, Message
Back to quick reference ↑
02

Verify kernel dump type, destination, page file, and free space together

CrashDumpEnabled selects a small, kernel, complete, automatic, or active memory dump policy depending on its numeric value and Windows version. Successful capture also depends on paging-file and dedicated-dump settings, destination capacity, storage availability during the crash, encryption, and overwrite policy. Automatic Memory Dump manages paging-file behavior differently from Complete Memory Dump. Read and document current effective settings first; changing HKLM requires elevation, can affect the next crash or boot, and may require a restart. Registry-provider WhatIf only previews registry writes—it cannot prove that Windows can produce a dump.

Read kernel capture prerequisites without modifying them
$crash = Get-ItemProperty -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl'
$crash | Select-Object CrashDumpEnabled, DumpFile, MinidumpDir, Overwrite, AlwaysKeepMemoryDump, DedicatedDumpFile
Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage
Get-Volume -DriveLetter $env:SystemRoot[0] | Select-Object DriveLetter, FileSystem, Size, SizeRemaining
Back to quick reference ↑
03

Treat every dump as restricted evidence

Memory dumps can contain authentication tokens, plaintext secrets, customer content, keys, network data, and source code. Restrict ACLs, encrypt storage and transport, minimize retention, and share only through an approved incident channel. Record original path, size, UTC timestamps, host, incident, capture method, dump type, and SHA-256 before analysis. Analyze a copy and preserve the original. Get-FileHash is read-only; Copy-Item supports WhatIf but its preview cannot verify destination ACLs, encryption, capacity, or chain of custody.

Record non-content artifact metadata
$dump = Get-Item -LiteralPath 'C:\CrashEvidence\App_260812_101500.dmp'
$hash = Get-FileHash -LiteralPath $dump.FullName -Algorithm SHA256
[pscustomobject]@{ Name = $dump.Name; Length = $dump.Length; CreatedUtc = $dump.CreationTimeUtc; ModifiedUtc = $dump.LastWriteTimeUtc; SHA256 = $hash.Hash }
Back to quick reference ↑
04

Choose WER or ProcDump capture with an explicit budget

WER LocalDumps can collect after supported user-mode crashes; per-application keys override global settings. Enabling it requires elevation and writable, capacity-managed folders whose ACLs allow the crashing identity. ProcDump is a separately downloaded Microsoft Sysinternals utility; dump type, trigger, count, clone mode, and target must be reviewed for the installed version. Full dumps can pause the process and be as large as its memory. ProcDump and WER configuration do not offer a reliable end-to-end WhatIf simulation; validate in staging and schedule production capture with an owner and cancellation path.

Review an exception-capture proposal before execution
$target = Get-Process -Name 'MyApp' -ErrorAction Stop | Select-Object Id, ProcessName, StartTime, Path, WorkingSet64
$target
Get-PSDrive -Name C | Select-Object Name, Used, Free
# After approval, a pinned ProcDump version can monitor one unhandled exception:
# procdump.exe -ma -e -n 1 -w 'MyApp.exe' 'C:\CrashEvidence'
# This attaches a debugger and can pause the process; there is no WhatIf mode.
Back to quick reference ↑
05

Validate a copy before investing in analysis

DumpChk from Debugging Tools for Windows checks whether a dump is recognizable and readable, but a successful check does not guarantee that it contains the required memory or that matching symbols exist. Work on a secured copy, verify its hash, record debugger and extension versions, and retain exact command output. Debugger tools are optional components, not built-in PowerShell modules; installing them changes the analyst workstation and can require administrative software deployment, but analyzing an existing dump requires no target reboot.

Preflight an offline analysis copy
$dump = 'C:\CrashEvidence\App_260812_101500.dmp'
Get-Item -LiteralPath $dump | Select-Object FullName, Length, LastWriteTimeUtc
Get-FileHash -LiteralPath $dump -Algorithm SHA256
Get-Command dumpchk.exe, windbg.exe -ErrorAction SilentlyContinue | Select-Object Name, Source, Version
# Run dumpchk.exe only against the secured analysis copy.
Back to quick reference ↑
06

Load trusted symbols before interpreting stacks

Open the dump offline, configure a controlled local symbol cache, and use Microsoft's symbol server plus private symbols from their authoritative build. Never load untrusted debugger extensions or symbol files. Start with !analyze -v, then confirm exception or bug-check context, stack, modules, image versions, and symbol status. Automated probable-cause output is a hypothesis, not proof; corrupted memory often implicates the victim. WinDbg commands have no WhatIf because analysis is read-only, but symbol loading can make outbound network requests and write the analyst cache.

Run a reproducible first WinDbg pass
.symfix C:\Symbols
.sympath
.reload /f
!analyze -v
.ecxr
kv
lm t n
Back to quick reference ↑

Keep exploring

More Windows cheat sheets

Windows · Monitoring, Policy, and Maintenance19 quick references

PowerShell Windows Event Logs Cheat Sheet

Investigate Windows event logs with Get-WinEvent discovery, server-side hashtable filters, structured properties, XML, archived files, remote queries, and summaries.

Open cheat sheet

Sources and further reading

References

Authoritative documentation used to verify and expand this cheat sheet.

  1. MicrosoftCollecting user-mode dumpslearn.microsoft.com
  2. MicrosoftProcDumplearn.microsoft.com
  3. MicrosoftOpen a dump file with WinDbglearn.microsoft.com
  4. MicrosoftUsing the !analyze extensionlearn.microsoft.com
  5. MicrosoftVarieties of kernel-mode dump fileslearn.microsoft.com
  6. MicrosoftEnabling a kernel-mode dump filelearn.microsoft.com
  7. MicrosoftCould not open dump file and DumpChklearn.microsoft.com

Help us improve

Found a typo or missing example?

Tell us what would make this cheat sheet clearer, more complete, or more useful.

Share feedback