Reading Windows Error Reporting history like a witness, not a believer

The events that name names

Application → ProviderName Application Error/Windows Error Reporting + EventID 1000/1001 — the canonical crash duo: the 1000 records the faulting module and exception code, the 1001 names the bucket generated.

Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Application Error'; Id = 1000; StartTime = (Get-Date).AddDays(-1) } |
  Select-Object TimeCreated, Message

What to take from each field

• Faulting module name — ProofTune.UI.exe vs Microsoft.UI.Xaml.dll vs apphelp.dll tells you the layer, more than any hex address;
• Exception code — 0xC0000005, 0xE0434352, 0xC000027B carry lore; e0434352 is always .NET-managed, c000027b is a stowed (packaged-app) exception;
• Timestamp consistency — the user's narrative lines up or they didn't; the event log is the unemotional tiebreaker.

Memory trick: %LOCALAPPDATA%\CrashDumps has per-app crash artifacts written by WER (configurable per user) — the dump stamp minus the dialog timestamp identifies the module in advance whenever your memory won’t serve.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.