Short answer: Windows Error Reporting files can generally be removed safely when they are no longer needed for troubleshooting, but deleting them permanently removes the diagnostic information stored in those reports.
What Are Windows Error Reporting Files?
Windows Error Reporting, commonly abbreviated WER, is a Windows component that collects diagnostic information when applications or system components encounter certain errors.
Depending on the failure and system configuration, Windows Error Reporting can record application crashes, application hangs, fault information, and other diagnostic details.
The collected information helps Windows, Microsoft, software developers, and support professionals investigate why an application or component failed.
A Windows Error Reporting record may include the affected application's name, version, error identifiers, exception information, timestamps, and references to supporting diagnostic files.
Some reports also include memory dumps or additional diagnostic data. These can be substantially larger than ordinary text-based reports.
Windows Error Reporting files are not personal documents, installed programs, or Windows system components required for normal startup.
However, reports can contain sensitive information about application activity and, in some cases, portions of process memory.
Deleting a previously generated report does not remove the underlying application or repair the problem that caused the report.
Windows can generate new reports when subsequent qualifying errors occur, provided reporting remains available under the current system configuration.
Microsoft documents Windows Error Reporting at https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/windows-error-reporting.
Where Does Windows 11 Store Error Reports?
Windows Error Reporting can store diagnostic records in both system-wide and user-specific directories.
The common system-wide reporting directory is %ProgramData%\Microsoft\Windows\WER.
On a typical Windows 11 installation, this expands to C:\ProgramData\Microsoft\Windows\WER.
The ReportArchive subfolder contains archived error reports. Microsoft documents this location as containing reports that have already been processed or uploaded, with some associated data potentially removed.
The ReportQueue subfolder contains queued reports that may still be awaiting processing or submission.
Windows may also maintain user-specific reporting directories under %LOCALAPPDATA%\Microsoft\Windows\WER.
Depending on the configuration and reporting activity, corresponding ReportArchive and ReportQueue subfolders may exist within the user-specific directory.
Not every Windows installation contains every reporting directory. Some folders may be missing, empty, or inaccessible to ordinary user accounts.
Separate application crash dumps may be stored in %LOCALAPPDATA%\CrashDumps when local dump collection has been configured.
Crash dumps stored through the LocalDumps feature are not necessarily managed by the same cleanup mechanism as ordinary archived WER reports.
Microsoft documents common WER report directories at https://learn.microsoft.com/en-us/windows-server/failover-clustering/troubleshooting-using-wer-reports.
- System-wide reports: %ProgramData%\Microsoft\Windows\WER.
- Archived system reports: %ProgramData%\Microsoft\Windows\WER\ReportArchive.
- Queued system reports: %ProgramData%\Microsoft\Windows\WER\ReportQueue.
- User-specific reports: %LOCALAPPDATA%\Microsoft\Windows\WER.
- Possible user-specific archives: %LOCALAPPDATA%\Microsoft\Windows\WER\ReportArchive.
- Possible user-specific queue: %LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue.
- Configured application crash dumps: %LOCALAPPDATA%\CrashDumps by default when LocalDumps collection is enabled without a custom destination.
- These locations are not interchangeable, and not all of them will exist on every computer.
How to Check the Report Folders Safely
Before removing diagnostic files, identify your Windows version and inspect the available reporting directories using read-only commands.
Step 1: Press Win + R, type winver, and press Enter.
Step 2: Record the Windows version and OS build displayed in the About Windows dialog.
Step 3: Press Win + R, type cmd, and press Enter to open Command Prompt.
Step 4: Run echo %ProgramData% to identify the system-wide application data directory.
Step 5: Run echo %LOCALAPPDATA% to identify the current user's local application data directory.
Step 6: Run dir /a "%ProgramData%\Microsoft\Windows\WER" to inspect the system-wide Windows Error Reporting directory.
Step 7: Run dir /a "%ProgramData%\Microsoft\Windows\WER\ReportArchive" to inspect archived reports when that directory exists.
Step 8: Run dir /a "%ProgramData%\Microsoft\Windows\WER\ReportQueue" to inspect queued reports when that directory exists.
Step 9: Run dir /a "%LOCALAPPDATA%\Microsoft\Windows\WER" to inspect the current user's reporting directory.
Step 10: Run dir /a "%LOCALAPPDATA%\CrashDumps" to check whether the current user's default application crash dump directory exists.
The dir command lists directory contents without deleting or modifying them.
If a command reports File Not Found or The system cannot find the path specified, that directory may not exist on the computer.
If Windows reports Access is denied, do not change folder ownership or security permissions simply to inspect the contents.
A missing directory does not indicate that Windows Error Reporting is broken or that diagnostic reporting is disabled.
When Is It Safe to Delete Windows Error Reports?
Removing old diagnostic reports is generally reasonable when the reports are no longer needed and the associated problems have already been resolved or are no longer relevant.
For example, a report from an application that crashed several months ago may no longer be useful if the application now works correctly and no support investigation is underway.
However, a recent report may contain important information about an unresolved application failure.
If you are investigating repeated crashes, preserve the relevant reports until the cause has been identified or the diagnostic investigation has finished.
Do not remove reports while a support technician, application developer, or troubleshooting tool is actively collecting diagnostic evidence.
Queued reports deserve additional caution because they may still be awaiting processing or submission.
Windows' built-in cleanup tools are preferable to manually deleting reporting directories because they identify supported cleanup categories.
Deleting an old report does not prevent Windows from recording future crashes when reporting is available.
Removing diagnostic files also does not guarantee that an application will stop crashing.
- Generally safe: Removing old reports that are no longer needed for troubleshooting.
- Generally safe: Clearing supported Windows Error Reporting cleanup categories through Windows tools.
- Generally safe: Removing previously reviewed diagnostic data after a completed investigation.
- Keep: Reports associated with unresolved application crashes.
- Keep: Reports requested by Microsoft or a software manufacturer's support team.
- Keep: Diagnostic files needed for an active investigation.
- Use caution: Reports in ReportQueue that may still be awaiting processing.
- Use caution: Application memory dumps that may contain valuable debugging information.
- Not recommended: Deleting every reporting directory without reviewing its contents and purpose.
- Not recommended: Disabling Windows Error Reporting merely to prevent diagnostic files from being created.
Method 1: Clean Error Reports Through Windows 11 Settings
Windows 11 provides built-in storage-management tools that can remove supported temporary and diagnostic files.
The exact cleanup categories shown depend on the Windows version, installed components, and files currently available for cleanup.
Step 1: Save your work and close applications involved in any completed troubleshooting session.
Step 2: Press Win + I to open Settings.
Step 3: Navigate to System > Storage.
Step 4: Open Temporary files.
Step 5: Allow Windows to calculate the available cleanup categories.
Step 6: Look for categories related to Windows Error Reporting, error reports, or system-created diagnostic files.
Step 7: If an appropriate category is present, select it after reviewing its description.
Step 8: Deselect unrelated cleanup categories if you intend to remove only diagnostic reports.
Step 9: Pay particular attention to Downloads, Recycle Bin, and other categories that may contain personal files.
Step 10: Select Remove files and confirm the cleanup when prompted.
Step 11: Allow Windows to finish before inspecting the remaining storage usage.
If Windows Error Reporting does not appear as a separate cleanup category, this does not necessarily indicate a problem. The category may be empty, unavailable, or handled differently by the current Windows installation.
Do not choose an unrelated category simply because Windows Error Reporting is not listed.
The Settings cleanup interface does not necessarily remove every locally configured application dump or every diagnostic file stored by third-party software.
Microsoft documents supported Windows storage cleanup at https://support.microsoft.com/en-us/windows/experience/storage-filemanagement/free-up-drive-space-in-windows.
Method 2: Use Windows Disk Cleanup
Disk Cleanup is another supported Windows utility for removing selected categories of unnecessary files.
Step 1: Press Win + R.
Step 2: Type cleanmgr and press Enter.
Step 3: If prompted, select the drive containing Windows.
Step 4: To confirm the Windows system drive, open Command Prompt and run echo %SystemDrive%.
Step 5: Allow Disk Cleanup to calculate the available cleanup categories.
Step 6: Review the Files to delete list.
Step 7: Look for categories associated with Windows Error Reporting or archived error reports, if available.
Step 8: Select Clean up system files when available, then review the recalculated categories.
Step 9: Select only the diagnostic cleanup categories you intend to remove.
Step 10: Review all selected categories before clicking OK.
Step 11: Confirm Delete Files when prompted.
Step 12: Wait for the operation to complete.
The names and availability of error-reporting cleanup categories can vary between Windows versions and configurations.
Some Windows installations may not display a separate Windows Error Reporting category.
Disk Cleanup does not guarantee removal of every file inside %ProgramData%\Microsoft\Windows\WER.
Disk Cleanup also does not guarantee removal of custom application crash dumps stored outside the locations managed by its selected cleanup categories.
Do not manually delete protected Windows directories because a particular cleanup category is unavailable.
Microsoft documents Disk Cleanup as a supported storage-management method at https://support.microsoft.com/en-us/windows/experience/storage-filemanagement/free-up-drive-space-in-windows.
ReportArchive vs. ReportQueue: What Is the Difference?
Windows Error Reporting maintains different report states, and the distinction matters when deciding whether diagnostic information should be preserved.
ReportArchive generally contains archived reports from errors that have already been processed or submitted.
ReportQueue generally contains reports waiting for processing or submission.
An archived report may retain a Report.wer file even when larger supporting diagnostic files are no longer present.
Queued reports may still contain diagnostic information that Windows has not finished processing.
The existence of a report in ReportArchive does not prove that it is useless. A support investigation may still depend on its metadata.
Likewise, a report in ReportQueue is not automatically safe to delete simply because it has an old timestamp.
To inspect system-wide archived reports, run dir /a "%ProgramData%\Microsoft\Windows\WER\ReportArchive".
To inspect queued reports, run dir /a "%ProgramData%\Microsoft\Windows\WER\ReportQueue".
Both commands are read-only.
If a support investigation is ongoing, preserve both relevant archived reports and queued diagnostic information.
For ordinary cleanup, prefer Windows' supported cleanup categories rather than manually emptying ReportArchive or ReportQueue.
Microsoft describes these reporting directories at https://learn.microsoft.com/en-us/windows-server/failover-clustering/troubleshooting-using-wer-reports.
- ReportArchive: Contains archived Windows Error Reporting records.
- ReportQueue: Contains reports that may still be awaiting processing or submission.
- Report.wer: Common report metadata file associated with a recorded problem.
- Archived does not necessarily mean diagnostically useless.
- Queued does not necessarily mean safe to remove.
- Windows cleanup tools are preferable to manually emptying report directories.
What About Local Crash Dumps?
Windows Error Reporting can also be configured to create local memory dumps when applications crash.
These files are different from ordinary text-based error reports because they can contain portions of an application's memory at the time of failure.
Microsoft documents the LocalDumps feature under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.
Local dump collection through this registry configuration is not enabled by default.
When LocalDumps is configured and no custom DumpFolder is specified, its default output directory is %LOCALAPPDATA%\CrashDumps for the crashing user's account.
Administrators and applications may configure alternative dump directories or application-specific settings.
To inspect the current system's LocalDumps configuration without modifying it, open Command Prompt and run reg query "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /s.
If the registry key does not exist, this particular LocalDumps configuration is not present at that location.
An absent key does not prove that no application or third-party debugging tool can create crash dumps through another mechanism.
To inspect the current user's default dump directory, run dir /a "%LOCALAPPDATA%\CrashDumps".
If local dumps are present, preserve those needed for ongoing application troubleshooting.
Removing an old dump that is no longer needed generally does not remove the application itself, but it permanently removes the diagnostic snapshot stored in that dump.
A full application dump can contain sensitive information from process memory. Do not upload these files to unknown websites or share them publicly.
Do not delete the LocalDumps registry key or disable crash reporting as a routine storage-cleanup technique.
Microsoft documents the configuration and default locations at https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps.
Safe vs. Unsafe Error Reporting Cleanup
Windows Error Reporting files should be managed according to their diagnostic purpose rather than treated as ordinary junk files.
The safest cleanup approach is to remove only reports that are no longer needed and to preserve information associated with unresolved problems.
- Safe: Inspecting WER report locations with read-only commands.
- Safe: Reviewing cleanup categories in Settings > System > Storage > Temporary files.
- Safe: Reviewing supported Disk Cleanup categories through cleanmgr.
- Generally safe: Removing old reports that are no longer needed for troubleshooting.
- Generally safe: Removing obsolete diagnostic data through supported Windows cleanup tools.
- Conditionally safe: Deleting an old application crash dump after confirming that it is no longer needed.
- Keep: Reports related to active or recurring crashes.
- Keep: Reports requested by an application developer or support technician.
- Keep: Crash dumps required for debugging or incident investigation.
- Use caution: Queued reports that have not finished processing.
- Unsafe: Deleting unrelated protected Windows system files.
- Unsafe: Running recursive deletion commands against the entire Windows reporting directory without review.
- Unsafe: Changing protected folder permissions merely to force diagnostic file deletion.
- Not recommended: Disabling Windows Error Reporting to prevent storage usage.
- Not recommended: Automatically deleting crash dumps from applications currently under investigation.
- Not recommended: Uploading crash dumps to untrusted online analysis services.
How to Check Whether You Still Need the Reports
Before removing diagnostic information, determine whether Windows or an application is still experiencing the problem described by the report.
One useful starting point is Windows Reliability Monitor, which displays a history of reliability events when the relevant data is available.
Step 1: Press Win + R.
Step 2: Enter perfmon /rel and press Enter.
Step 3: Review the available reliability history.
Step 4: Look for recent application failures, Windows failures, or recurring problems.
Step 5: Select a relevant event to inspect the information Windows provides.
Step 6: Record the affected application, event date, and available error details.
Step 7: If you are investigating a recurring problem, preserve the associated reports and diagnostic files.
Step 8: If the problem was resolved and no additional investigation is required, older reports may no longer be necessary.
Reliability Monitor availability and the amount of historical information retained can vary by Windows configuration.
You can also inspect application errors through Event Viewer.
Press Win + R, enter eventvwr.msc, and open Windows Logs > Application.
Look for events near the time of the crash, including relevant Application Error or Windows Error Reporting entries.
Event Viewer records and WER report files are related diagnostic sources but are not identical.
Deleting WER report files does not automatically remove every corresponding event from Windows Event Viewer.
Do not clear Windows event logs merely to recover the space associated with Windows Error Reporting.
How Much Disk Space Can You Recover?
There is no fixed amount of storage that can be recovered by deleting Windows Error Reporting files.
The amount depends on how many reports exist, what diagnostic data they contain, and whether larger crash dumps were collected.
A folder containing only small report metadata files may use relatively little disk space.
A directory containing application memory dumps or extensive supporting diagnostic files can use substantially more.
To inspect the size of the Windows Error Reporting cleanup category, open Settings > System > Storage > Temporary files.
If an appropriate error-reporting category appears, review the storage amount reported by Windows.
Alternatively, run cleanmgr and review any available error-reporting cleanup categories.
To measure a specific reporting directory, open PowerShell and run $path = Join-Path $env:ProgramData 'Microsoft\Windows\WER\ReportArchive'.
Next, run if (Test-Path -LiteralPath $path) { Get-ChildItem -LiteralPath $path -File -Recurse -Force -ErrorAction Stop | Measure-Object -Property Length -Sum }.
This read-only PowerShell command reports the combined logical size of files that can be enumerated within the selected archive directory.
If access is denied or another enumeration error occurs, do not treat the result as a complete measurement.
The reported logical size may differ from the actual disk space recovered because of filesystem allocation and other storage behavior.
To check actual available space, open File Explorer > This PC and inspect the free space on the affected drive.
Compare free space before and after cleanup using the same drive.
Windows and applications may create or remove other files during the measurement period, so the difference may not exactly match the cleanup category's estimate.
If error reports account for little storage, investigate other disk usage categories rather than removing diagnostic information unnecessarily.
Will Deleting Error Reports Fix Application Crashes?
No. Windows Error Reporting files record information about problems that have already occurred. Deleting them does not repair the cause of those problems.
If an application repeatedly crashes, investigate the application itself rather than simply clearing its reports.
Begin by checking whether the application has an official update or documented troubleshooting procedure.
Review Reliability Monitor with perfmon /rel to identify recurring failures.
Inspect Windows Logs > Application through eventvwr.msc for relevant errors.
Record the affected application version and any available faulting module or error code.
If the failure began after an application update, consult the application's official recovery or rollback instructions.
If a particular device or driver is involved, inspect its status through Device Manager by running devmgmt.msc.
Do not assume that every application crash is caused by insufficient disk space, an outdated driver, or damaged Windows files.
If the issue persists, preserve the relevant WER reports and contact the application's support provider.
Once the problem is resolved and diagnostic files are no longer needed, cleanup becomes a reasonable option.
Repeatedly deleting reports from an application that continues to crash only removes diagnostic evidence while the underlying failure remains.
Windows Error Reports vs. System Memory Dumps
Windows Error Reporting records, application crash dumps, and system memory dumps are related diagnostic resources but should not be treated as identical files.
WER report directories commonly contain report metadata and supporting files associated with application or system problems.
Application crash dumps may be collected through the LocalDumps feature or application-specific debugging tools.
System memory dumps are associated with Windows system crashes and may be written to %windir%\MEMORY.DMP, depending on the configured crash dump settings.
Smaller system crash dumps may be stored under %windir%\Minidump when that dump type is configured.
To inspect system crash dump settings, press Win + R, enter SystemPropertiesAdvanced.exe, and open Startup and Recovery > Settings.
The Write debugging information setting identifies the configured system crash dump type.
The displayed dump file path identifies the configured location for the selected system crash dump mechanism.
These settings may vary according to Windows version, configuration, and administrative policy.
A Disk Cleanup category named System error memory dump files is not necessarily the same as a category associated with Windows Error Reporting files.
Do not select unrelated crash dump cleanup categories when you intend to preserve diagnostic evidence from a system failure.
If Windows has recently experienced a blue screen or other serious crash, preserve relevant system dumps until the investigation is complete.
For ordinary cleanup, review the exact category and its purpose rather than assuming every diagnostic file is interchangeable.
- WER reports: Diagnostic records associated with reported application or system failures.
- Local application dumps: Process memory snapshots collected when configured.
- System memory dump: Commonly stored at %windir%\MEMORY.DMP when configured.
- System minidumps: Commonly stored under %windir%\Minidump when configured.
- Crash dump settings: SystemPropertiesAdvanced.exe > Startup and Recovery > Settings.
- Different diagnostic file categories can have different cleanup and recovery implications.
- Do not delete crash dumps required for an ongoing investigation.
Can Error Reports Contain Sensitive Information?
Yes. Windows Error Reporting records can contain information about applications, operating system conditions, error events, and diagnostic context.
A report may identify an application, its version, the time of failure, or the technical circumstances surrounding a crash.
Application memory dumps may contain portions of process memory captured at the moment of failure.
Depending on the application, memory contents could include sensitive information that was being processed when the crash occurred.
This does not mean every error report contains passwords, documents, or other private content. The information varies by report type and configuration.
Before sharing diagnostic files, confirm that the recipient is trusted and that the files are actually required for troubleshooting.
Avoid uploading memory dumps to unknown websites or attaching them to public support discussions.
Organizations should follow their data handling and retention policies when storing, sharing, or deleting diagnostic records.
Deleting reports that are no longer needed can reduce locally retained diagnostic information, but it does not necessarily remove reports previously transmitted to an external service.
Windows diagnostic data and privacy settings can be reviewed under Settings > Privacy & security > Diagnostics & feedback on Windows 11.
Those settings are separate from ordinary file cleanup and do not guarantee deletion of every local WER report or application-specific dump.
Do not disable important diagnostic features solely because report files may contain sensitive information. Use appropriate privacy and data-management controls.
What If Windows Error Reporting Files Keep Growing?
If error-reporting storage continues growing after cleanup, a recurring application or system problem may be generating new reports.
First, review Reliability Monitor using perfmon /rel to identify repeated failures.
Then open Event Viewer with eventvwr.msc and inspect Windows Logs > Application for recurring application errors.
Record the affected application names, event timestamps, and error details.
Check whether one application or service repeatedly crashes.
If local application dumps are present, inspect the configured LocalDumps directory and registry settings without modifying them.
Repeated reports from the same application may indicate that a software update, driver correction, or application-specific repair is needed.
A growing reporting directory does not automatically indicate malware or Windows corruption.
Avoid repeatedly emptying report directories while the cause remains unknown.
If the problem concerns a business application or a company-managed computer, preserve relevant diagnostic evidence and contact the responsible administrator or software provider.
Once the underlying problem is resolved, Windows may stop generating repeated reports for that failure.
If disk usage remains high but WER reports are small, investigate other storage locations before changing diagnostic settings.
Key Takeaways and Related Guides
Old Windows Error Reporting files are generally safe to remove when they are no longer needed for troubleshooting.
Use Windows 11 Settings > System > Storage > Temporary files or Disk Cleanup to review supported diagnostic cleanup categories.
The common system-wide reporting location is %ProgramData%\Microsoft\Windows\WER, while user-specific reports may exist under %LOCALAPPDATA%\Microsoft\Windows\WER.
Do not manually remove the entire WER directory, clear reports needed for active investigations, or disable reporting merely to recover storage.
Remember that ReportArchive, ReportQueue, application crash dumps, and system memory dumps serve different purposes.
Deleting error reports does not fix application crashes. It only removes the diagnostic files that were previously generated.
Microsoft's official Windows storage cleanup guidance is available at https://support.microsoft.com/en-us/windows/experience/storage-filemanagement/free-up-drive-space-in-windows.
Microsoft documents WER report directories at https://learn.microsoft.com/en-us/windows-server/failover-clustering/troubleshooting-using-wer-reports.
Microsoft documents locally collected application crash dumps at https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps.
For a broader cleanup strategy, review the related Windows storage guides below.
- Yes, old Windows Error Reporting files can generally be deleted safely.
- Keep diagnostic reports associated with unresolved crashes.
- Use supported Windows cleanup tools rather than deleting protected directories.
- ReportQueue may contain reports awaiting processing or submission.
- Local application dumps may contain sensitive process memory.
- System memory dumps require separate consideration.
- Deleting reports does not repair the underlying application or system problem.
- Measure actual disk usage before removing diagnostic information.
- Investigate repeated crashes if reporting directories continue growing.
Related: