Windows Error Reporting (WER)

What it is

Windows Error Reporting (WER) is the service that handles application crashes, hangs and some kernel problems. For each event it builds a report folder containing a text file named Report.wer (plus, in some cases, memory dumps and metadata) and writes matching entries to the Application event log. For an investigator, WER is a quiet source of evidence of execution: exploit code, unstable implants, credential dumpers and hacking tools crash often, and the report survives after the attacker deletes the binary.

Location

Report folders are named after the event type and application, for example AppCrash_<exe name>_<hash>_<id>, AppHang_... or Kernel_....

What it proves

• Execution: the application at AppPath was running when it crashed or hung. A report for C:\Users\Public\x.exe proves that file existed and ran.
• Identity of a deleted binary: on Windows 10 and later, many system-wide reports carry a SHA-1 of the executable in TargetAppId, in the same 0000-prefixed form as Amcache. Not every report has it.
• What was loaded: LoadedModule[n] lists the DLLs in the process, which can expose an injected module inside a legitimate host.
• Process start time: event 1000 records the faulting application's start time and PID.
• It does not prove the user launched the program deliberately, and a program that never crashed leaves nothing here.

Key fields

Event 1000 (Application Error) holds the faulting application and module names and versions, exception code, fault offset, faulting process ID, application start time, application path, module path and a Report Id. Event 1001 (Windows Error Reporting) holds the fault bucket, event name, problem signature, attached files and the folder where the report is stored.

Timestamps

Retention and clearing

• Documented defaults: MaxArchiveCount 1,000 reports and MaxQueueCount 50 reports; the oldest are dropped beyond that.
• WER can be disabled with Disabled = 1, archiving with DisableArchive = 1 and queuing with DisableQueue = 1 under the WER key or its policy equivalent. Any of these on a workstation deserves a question.
• Disk Cleanup offers to delete error-report files, and attackers can simply wipe the WER folders. Deletions may still show in the USN journal and the $MFT, and Application events 1000/1001 outlive the files until the log rolls over.
• LocalDumps (Windows Vista SP1 and later) is off by default. Under HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps (global or per <exe> subkey), DumpFolder (default %LOCALAPPDATA%\CrashDumps), DumpCount (default 10) and DumpType (0 custom, 1 mini, 2 full) control dumps kept locally. A LocalDumps\lsass.exe subkey with DumpType 2 is a credential-theft red flag.

Collection

• KAPE target: WER (both WER trees, CrashDumps and *.dmp in C:\Windows).
• Velociraptor (Windows.Triage.Targets): WER.
• Built-in: the folders are readable by administrators; keep timestamps with robocopy. Export the Application log for events 1000/1001/1002 and the WER key from the SOFTWARE hive.

robocopy C:\ProgramData\Microsoft\Windows\WER E:\case\WER\System /E /COPY:DAT /DCOPY:T /B
wevtutil epl Application E:\case\Application.evtx
reg export "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" E:\case\wer-config.reg
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000,1001,1002} | Format-List TimeCreated, Id, Message

Parsing tools

• Any text editor or Get-Content: Report.wer is plain Name=Value text in UTF-16.
• AppCrashView (NirSoft, free): lists crashes from the WER report files of a live or mounted system.
• EvtxECmd (Eric Zimmerman): includes a map for Application event 1001 (Windows Error Reporting).
• Velociraptor: the community artifact Windows.System.WindowsErrorReporting (artifact exchange) extracts EventTime, AppPath, OriginalFilename and the SHA-1 from TargetAppId.
• WinDbg: analyse any dump attached to a report or kept by LocalDumps (see crash dumps).

Investigation tips

• Grep every Report.wer for AppPath values in user-writable folders (\Temp\, \Downloads\, \Users\Public\, \ProgramData\) and for tool names such as mimikatz, procdump, rclone or psexec.
• Extract the SHA-1 from TargetAppId and look it up in Amcache and threat intelligence, even when the binary is gone.
• Compare OriginalFilename with the file name in AppPath: svchost.exe whose original name is mimikatz.exe is a renamed tool.
• Crashes of lsass.exe, explorer.exe or a browser with an unexpected module in LoadedModule can reveal injection; check the module path against Prefetch.
• A burst of crashes of the same binary at intrusion time often matches an exploit being retried; line up EventTime with logons in the event logs.
• A Defender kill or quarantine can also make a process die; cross-check with Microsoft Defender logs before calling it a crash.