Windows Error Reporting

Location & availability

ProgramData\Microsoft\Windows\WER\ReportArchive and ReportQueue; Application event log

Availability depends on reporting policy, cleanup and application behaviour. Dumps can contain sensitive process data.

Fields to examine

• Report.wer application path and report identifiers.
• Failure time and exception or fault-module information where supplied.
• Associated Application error events and dump metadata.

What it can establish

• Support that an application encountered the reported failure.
• Identify a faulting component for further examination.

What it cannot prove

• Infer malicious injection merely because a DLL appears in a crash report.
• Assume a report preserves every module or all earlier executions.

Use it in a screenshare

1. Locate a report tied to the relevant executable and preserve the whole report directory.
2. Read the application path and failure context alongside Application events; distinguish report creation from the actual failure time.
3. Examine a dump only within the agreed scope, then correlate file identity and legitimate overlays or drivers.

Worked example

A game crashed with a capture overlay listed as the faulting module. Record the crash and module identity. A faulting module can be a legitimate installed component and needs examination before any accusation.

Cross-check the finding

• Live processes and loaded modules →Support that a process or module was visible at the observation time.
• Prefetch →Support execution of an associated executable within the retained history.
• Game and launcher logs →Support the application’s recorded description of a particular instance/session.

Sources

• Microsoft — Windows Error Reporting ↗