The pipeline: crash, dump, report, queue
When an application hits an unhandled error, the WER service and its worker WerFault.exe collect the basics: which app, which version, which module it died in, and the exception signature. Optionally they also capture a dump — a frozen snapshot of the process's memory at the moment of death. The report lands in %ProgramData%\Microsoft\Windows\WER\ReportQueue, gets uploaded to Microsoft (or held there if you have diagnostics dialed down), then moves to ReportArchive. Kernel crashes live separately: minidumps pile up in C:\Windows\Minidump, the full kernel dump sits in C:\Windows\MEMORY.DMP, and GPU driver live-dumps land in C:\Windows\LiveKernelReports. Per-application dumps land in %LOCALAPPDATA%\CrashDumps when something enables that for the app.
None of this touches the health of your system. WER is bookkeeping: it records that something broke, keeps the evidence for a while, and lets Microsoft see crash patterns across millions of machines. The reports are small; the dumps are what get big — a full dump of a heavy application can run to hundreds of megabytes, because it is, literally, a copy of what that app had in memory.
- %ProgramData%\Microsoft\Windows\WER\ReportQueue — reports waiting to upload
- %ProgramData%\Microsoft\Windows\WER\ReportArchive — reports already sent or kept
- %LOCALAPPDATA%\CrashDumps — per-app .dmp files, when enabled
- C:\Windows\Minidump — small dumps of every BSOD
- C:\Windows\MEMORY.DMP — the full kernel dump from the last BSOD
- C:\Windows\LiveKernelReports — GPU and display driver live-dumps (Watchdog)
What is actually inside a dump
A dump is process memory, and process memory is your data: fragments of the document that was open, image buffers, URLs, session tokens — whatever that app was holding. That is why the diagnostics setting matters. Under Settings → Privacy & security → Diagnostics & feedback, "Required diagnostic data" sends the small stuff, while "Optional diagnostic data" is the switch that lets richer memory slices leave your machine. Most people are well served by required-only, and crash reports still work.
Locally, a dump only matters if somebody reads it. If you debug a recurring crash yourself — or paste it into a forum where someone else does — the dump is gold, read with tools like WinDbg. If nobody is debugging, an old dump is an artifact: evidence of a crash that has already been fixed, forgotten, or tolerated.
Cleaning up without breaking anything
Everything in ReportArchive and ReportQueue can go, along with minidumps and MEMORY.DMP files from crashes you have already dealt with; Windows will simply make new ones when something new breaks. Storage Sense and Disk Cleanup largely ignore these folders, so it is a manual job or a tool-assisted one — a cleanup like Kleaner PRO shows these locations with their sizes, which turns "a few hundred MB of mystery" into a decision you can actually make. The one thing worth doing before deleting: if a crash keeps repeating and you plan to ask about it, copy the dump out first.
Disabling WER entirely (services.msc → Windows Error Reporting Service) stops the collection but not the crashes; the app still dies, you just get no report. And when WerFault.exe eats noticeable CPU, it is almost always a program crashing in a loop — treat the crashing app, not the messenger. Fixing the crash is the only step that makes any of this machinery go quiet.
Questions and Answers
Is it safe to delete Windows error reports?
Yes. The contents of WER's ReportArchive and ReportQueue, plus old .dmp files, can all go. You lose crash history you weren't using — nothing else breaks.
Should I disable Windows Error Reporting?
Only if crash data leaving the machine bothers you. Disabling WER doesn't make Windows faster or more stable; it just stops the reports and makes your own crash diagnosis harder.
Know what is included before you buy.
The one-time 30-minute trial covers core tools. PRO-labelled features stay locked until a paid license is activated.
Read next
Write to us: [email protected]