- C:
- Users
- <utilisateur>
- AppData
- Local
- CrashDumps
FolderRisk: Safe
CrashDumps C:\Users\<utilisateur>\AppData\Local\CrashDumps
Memory dumps (.dmp) of crashed applications, written by Windows Error Reporting when LocalDumps is configured. Safe to delete after analysis.
What it’s for
When an application crashes, Windows Error Reporting (WER) writes a user-mode dump (.dmp) here, provided local dump collection is enabled. You open it in WinDbg or Visual Studio to find the cause of the crash.
What it contains
.dmpfiles named after the executable and the process ID, for exampleapplication.exe.1234.dmp.- Nothing at all until collection is configured: the folder is missing or empty.
- At most ten dumps by default (the
DumpCountvalue); the oldest is replaced by the newest. - Mini or full dumps, depending on
DumpType. A full dump is large and can hold passwords, tokens or documents that were open in memory.
Risks and best practices
- You can delete the
.dmpfiles. Windows does not need them; you only lose the ability to analyze that crash. - Before cleaning up, keep any dump the vendor’s support asks for, and treat them as confidential data.
- Collection is configured under
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps(DumpFolder,DumpCount,DumpType). On a server, pointDumpFolderto a volume with enough space. - Services do not write here: their dumps go to the service account’s profile (
SystemProfileforLocalSystem).
Useful commands
# List dumps, from most recent to oldestGet-ChildItem "$env:LOCALAPPDATA\CrashDumps" -Force | Sort-Object LastWriteTime -Descending | Select-Object Name, Length, LastWriteTime
# Read the collection configuration (absent if not configured)Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps' -ErrorAction SilentlyContinue
# Simulated deletion (remove -WhatIf to run)Remove-Item "$env:LOCALAPPDATA\CrashDumps\*.dmp" -WhatIf