DMP File Documentation

---

Technical details

Feature	Value
Full name	Windows Memory / Crash Dump file
File extension	.dmp
MIME type	application/octet-stream
Format type	Binary memory snapshot (minidump / kernel / full dump)
Developer	Microsoft
Introduced	Windows minidump format, Windows 2000/XP era
Category	System / diagnostic
Minidump magic	4D 44 4D 50 (“MDMP”) at offset 0
Kernel dump magic	PAGEDU64 (x64) or PAGEDUMP (x86)
Header size	32-byte MINIDUMP_HEADER
Version constant	Low 16 bits = 42899 (0xA793)
Byte order	Little-endian
Open standard	No — Microsoft-defined
Typical minidump	C:\Windows\Minidump\, a few hundred KB
Full memory dump	C:\Windows\MEMORY.DMP, up to RAM size
Read with	WinDbg (!analyze -v), NirSoft BlueScreenView, Visual Studio
Safe to delete	Yes — Disk Cleanup “System error memory dump files”
Convert to	Text/HTML analysis report only (not the raw dump)
Also used by	Oracle Data Pump export (expdp/impdp) — unrelated
Related extensions	.mdmp, .hdmp, .dump, .core
Specification	learn.microsoft.com/windows-hardware/drivers/debugger/

What is a DMP file?

A .dmp file is, on a normal Windows PC, a memory dump: a snapshot of what was in memory at the moment something went wrong. When Windows hits a fatal error, the “blue screen of death”, it writes the contents of memory to disk so the crash can be analysed afterwards. Individual applications also write .dmp files when they crash, through Windows Error Reporting or a debugger's “save dump” command. These are diagnostic artefacts, not user documents; you read them with a debugger, not a viewer.

There is a second, unrelated file that shares the extension. Oracle's Data Pump utility (expdp) writes database exports as .dmp files, restored with impdp. That file has nothing to do with memory; it is a proprietary database export and is meaningless to a debugger. The two are told apart by their contents: a Windows dump begins with a recognisable header, described below, while an Oracle export does not. This page covers the Windows memory dump, which is the dominant meaning.

Three dump sizes: minidump, kernel and complete

Windows can write dumps at very different levels of detail, controlled by the system's crash settings. The size trade-off is between how much you capture and how much disk (and privacy exposure) it costs.

Dump type	Contents	Typical location / size
Small memory dump (minidump)	Stop code, loaded drivers, the crashing thread's call stack	C:\Windows\Minidump\, a few hundred KB
Kernel memory dump	All kernel-mode memory; omits user-mode pages	C:\Windows\MEMORY.DMP, hundreds of MB
Complete memory dump	The entire contents of physical RAM	C:\Windows\MEMORY.DMP, up to RAM size

The minidump is what you want for most blue-screen diagnosis: it is small, safe to share, and still names the faulting driver and stop code. A complete dump is the most detailed but is as large as installed RAM and is the most likely to contain sensitive data, since it copies everything that was in memory. Application crash dumps are a separate, user-mode variety that captures one process rather than the whole system.

The MINIDUMP_HEADER and the MDMP signature

A user-mode minidump (and the .dmp most people encounter) is the MDMP format, and it begins with a fixed 32-byte header. This header is the map to the rest of the file: it says how many data streams the dump contains and where the directory listing them lives.

MINIDUMP_HEADER (32 bytes, offset 0):
  Signature            u32  "MDMP" = 0x504D444D
  Version              u32  low 16 bits = 42899 (0xA793)
  NumberOfStreams      u32  count of streams in the dump
  StreamDirectoryRva   u32  file offset of the stream directory
  CheckSum             u32
  TimeDateStamp        u32  when the dump was written
  Flags                u64  which MINIDUMP_TYPE data was captured

The Signature is always the four bytes MDMP (the value 0x504D444D stored little-endian), and the low 16 bits of Version are always 42899. StreamDirectoryRva is a relative virtual address, an offset in bytes from the start of the file, pointing at the stream directory. Kernel and complete dumps use a different header entirely, beginning with the ASCII strings PAGEDU64 on 64-bit Windows or PAGEDUMP on 32-bit, but the same idea applies: a fixed header describing what follows.

Streams and the stream directory

A minidump is not one monolithic blob; it is a container of typed streams, each holding one category of data. The header points to a directory, an array of fixed-size entries, and each entry names a stream's type and where in the file its data sits.

MINIDUMP_DIRECTORY (one per stream):
  StreamType   u32   what kind of data (enum)
  Location     MINIDUMP_LOCATION_DESCRIPTOR:
       DataSize   u32   length of this stream
       Rva        u32   file offset of this stream

Common StreamType values:
  ThreadListStream      threads and their register contexts
  ModuleListStream      loaded modules (name, base address, size)
  ExceptionStream       the exception record: what fault occurred
  SystemInfoStream      OS version, CPU, and processor architecture
  Memory / Memory64ListStream   captured memory ranges

To read a dump, a tool parses the header, walks the directory, and jumps to each stream by its Rva. The SystemInfoStream carries the OS build and the CPU architecture (which a debugger needs to interpret registers correctly), the ExceptionStream holds the fault that triggered the dump, and the ModuleListStream lists every loaded module with its base address, so an address in a call stack can be attributed to the right driver or DLL. Full dumps simply include far larger memory streams.

Analysing a dump with WinDbg and BlueScreenView

Because a stream holds raw addresses rather than function names, real analysis needs a debugger plus symbols. Microsoft's free WinDbg (part of the Debugging Tools for Windows, in the Windows SDK, and also on the Microsoft Store) opens a dump through File › Open Crash Dump. The single most useful command is !analyze -v: it walks the exception and thread streams, resolves the faulting stack against symbols, and names the driver or module responsible along with the stop code. WinDbg downloads matching symbol files (PDBs) from the Microsoft symbol server, because the dump stores addresses and the module list, not the function names those addresses map to.

For a non-expert, NirSoft's free BlueScreenView is simpler: it auto-loads the minidumps in C:\Windows\Minidump and shows each blue screen as a row, highlighting the driver that appears at the top of the crashing stack and the BSOD stop code, with no debugging knowledge required. Developers debugging their own application open a user-mode .dmp in Visual Studio, which lines the crash up against their source and symbols. In every case the output is a report; you do not convert the dump, you analyse it and export the analysis. A dump cannot become an .exe (it is a snapshot, not a program) and there is no direct dump-to-PDF path beyond printing the text report.

Deleting dumps and reclaiming disk space

Crash dumps are diagnostic leftovers, not system requirements, so they are safe to delete. A MEMORY.DMP can be as large as installed RAM, so removing it can free several gigabytes. The clean way is Disk Cleanup, which lists “System error memory dump files” and “System error minidump files” as removable items; Windows simply writes a fresh dump on the next crash. Deleting old dumps does not affect stability and does not remove the crash-dumping feature itself.

References

• Microsoft Learn — Open a dump file with WinDbg
• Microsoft Learn — Analyze a kernel-mode dump with WinDbg
• NirSoft — BlueScreenView

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.