WER queues reports that were never sent and never cleared

When an application crashes, Windows Error Reporting collects a report and queues it to send to Microsoft. On a machine that is offline, behind a proxy, or has reporting disabled, the queue fills and nothing drains it.

Where the reports are

Get-ChildItem "$env:ProgramData\Microsoft\Windows\WER" -Recurse -Force -EA SilentlyContinue |
  Measure-Object Length -Sum |
  Select-Object Count, @{n='MB';e={[math]::Round($_.Sum/1MB)}}
Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Windows\WER" -Recurse -Force -EA SilentlyContinue |
  Measure-Object Length -Sum |
  Select-Object Count, @{n='MB';e={[math]::Round($_.Sum/1MB)}}

Why it grows

• One application crashing in a loop. Each crash is a new report, and a program restarting and failing every minute produces hundreds.
• Reports that cannot be sent. No connection, a proxy in the way, or reporting turned off by policy, so the queue never drains.
• Dumps attached to reports. A report for a large application can include a dump of its memory.

Clearing it

Disk Cleanup lists these under System queued Windows Error Reporting and System archived Windows Error Reporting in its system files mode, which is the tidy route. Deleting the contents of the WER folders directly also works and is safe, since these are records rather than anything the system needs.

The more useful question

A WER folder of any real size names the thing that is failing. The report folders are named after the executable, so listing them tells you which application is crashing repeatedly, which is worth more than the space:

Get-ChildItem "$env:ProgramData\Microsoft\Windows\WER\ReportQueue" -Directory -EA SilentlyContinue |
  Group-Object { ($_.Name -split '_')[1] } | Sort-Object Count -Descending |
  Select-Object Count, Name -First 10

The same is true of crash dumps, which are the kernel side of the same story.