Use Windows Error Reporting evidence to separate app crashes from app hangs
WER can preserve report identifiers and crash/hang context that help connect an incident to the correct process without turning every report into a root-cause claim.
- Record whether the user observed a crash, a Not responding hang, or a full-system freeze.
- Match the exact timestamp to Application Error, Application Hang and Windows Error Reporting records.
- Preserve report IDs and repeated application/version information.
- Use Reliability Monitor as a timeline cross-check when available.
What this problem usually means
Windows Error Reporting has separate reporting paths for application failures and hangs. Microsoft documents AppHang reporting and WER report identifiers that can correlate a hang record with its WER report. WER settings also define local report queuing/archive and optional local dump collection. These artifacts establish what Windows observed; they do not automatically identify the defective module.
What is known, and what is not proven yet
Keep observation, evidence and conclusion separate before making a higher-impact change.
Windows recorded an application crash or hang around the reported symptom.
Application Error/Hang record, WER report ID, process/version, Reliability Monitor and optional process dump.
One user-mode application or a dependency it uses.
A repeated matching signature and proof that the event timestamp belongs to the user-visible failure.
Repair/update the owning app or dependency only after the repeated signature is established.
Vendor or developer with report ID and process dump when first-line app repair does not resolve a reproducible failure.
Work from the narrowest fix to the broader one.
Classify the incident before interpreting it
Low riskWhy this belongs here: A hang and a crash represent different failure states and can require different evidence.
- If the process terminated unexpectedly, use the Application Error/crash path.
- If the process stopped responding while Windows remained usable, use the AppHang/wait-chain path.
- If the whole system stopped responding or restarted, use system crash/restart evidence instead.
Use WER report identity to correlate the same incident
Low riskWhy this belongs here: Matching report identity and timestamp reduces the chance of mixing unrelated background errors with the failure being investigated.
- Compare the application name/version and report identifier where present.
- Check whether the same signature repeats across multiple incidents.
- Preserve existing report folders or vendor-requested artifacts before cleanup.
When this guide stops being the right path
Do not edit WER registry settings, enable broad local dump collection or delete report history merely to make an Event Viewer warning disappear. Collection changes should have a specific diagnostic purpose.
If the problem is still not fixed
For repeatable app hangs, use wait-chain/process-dump evidence. For repeatable crashes, use Event 1000/WER and app-specific repair or a process dump when requested by support.
Sources reviewed for this page
Primary technical guidance is preferred. A source supports the scope stated here; it does not imply that every possible cause is covered.