Reading Application Error events without crashing your shell (or your schedule)

The two commands that differ by one letter — wildly

Get-EventLog -LogName Application walks the whole log with .NET-era remoting of the structure; on a real machine with months of history, it's a dozen-second disappointment. The modern interface:

$since = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; Id = 1000; StartTime = $since } -MaxEvents 50 -ErrorAction SilentlyContinue |
  ForEach-Object { $_.Message }

FilterHashtable over -FilterXPath for daily use

• Structured fields beat strings: hashtable keys (Id, Level, StartTime, ProviderName) push filtering into the event service itself — max performance with the least XML.
• XPath is for weird queries only: reach for -FilterXPath when you need provider name entries beyond the hashtable, or when querying Microsoft-Windows-* operational logs with custom names asleep till event.
• Bound your ask: -MaxEvents plus a time filter is the difference between a diagnostic command and an accidental 4-GB read marathon.

In the context of a crash verdict

For post-mortem work — an app that “disappeared” right after starting — an Application Error event with ID 1000 and the faulting module in its message is the cleanest hand-off from Windows. Its FaultingModulePath names the DLL; its timestamp beats your recollection of when you clicked. Tools that take the care to write proper WER-readable events (or Windows-noise-filtered log files) make that the routine check, not a guess.

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