- C:
- ProgramData
- Microsoft
- Windows
- WER
- ReportArchive
FolderRisk: Safe
ReportArchive C:\ProgramData\Microsoft\Windows\WER\ReportArchive
Local Windows Error Reporting archive: one subfolder per processed incident (Report.wer, .dmp minidump); can be emptied.
What it’s for
Once Windows Error Reporting has processed an incident (application crash, hang, kernel error), its report lands here, sent or not depending on the configuration. An administrator can find the cause of a crash here without Internet access. Reports still waiting to be sent are in the neighboring ReportQueue folder.
What it contains
One subfolder per report, named after the incident type, the application and a hash, for example AppCrash_.... You will usually find:
Report.wer, a text file describing the incident: application, faulting module, version, parameters;- depending on the case, a
.dmpminidump and.xmlor.txtfiles with system information.
Retention (archive enabled or not, maximum number of reports) is set in the WER settings in the Registry.
Risks and best practices
- Emptying the folder does not hurt Windows. You only lose diagnostic history, so copy the reports of an incident you are investigating first.
- A minidump can hold fragments of the application’s memory, so sensitive data. Send it only to a trusted third party.
- To reclaim space, use Disk Cleanup (Windows Error Reporting files) or reduce retention in the WER settings, rather than disabling the service.
Useful commands
# Archived reports, newest firstGet-ChildItem "$env:ProgramData\Microsoft\Windows\WER\ReportArchive" -Directory | Sort-Object LastWriteTime -Descending | Select-Object -First 20 Name, LastWriteTime
# Read a reportGet-Content "$env:ProgramData\Microsoft\Windows\WER\ReportArchive\<ReportFolder>\Report.wer" -TotalCount 40
# Empty the archive (as administrator); simulate first with -WhatIfGet-ChildItem "$env:ProgramData\Microsoft\Windows\WER\ReportArchive" | Remove-Item -Recurse -Force -WhatIf