Quick answer: A minidump is a small file capturing the essential state of a program at the moment it crashed: the call stacks of its threads, register values, loaded modules, and selected memory. Games use minidumps to diagnose native crashes, the kind that happen in engine or C++ code below the managed layer, by loading the dump into a debugger after the fact.

Some crashes happen in managed code and produce a clean exception and stack trace. Others happen deep in native code, the engine, a C++ subsystem, a driver, and bring the whole process down hard, with no tidy managed trace. For these, a minidump is how you investigate: a post-mortem snapshot of the dead process you can examine as if you had been debugging it live. It is the native-crash counterpart to a managed stack trace.

What a Minidump Captures

A full memory dump of a crashed game would be enormous, gigabytes, so a minidump captures a curated subset: the call stack and register state of each thread, the list of loaded modules and their versions, the exception information, and selected regions of memory. It is "mini" because it omits the bulk of the heap while keeping the parts needed to understand why the crash happened.

That curated snapshot is usually enough to reconstruct the crash. From the dump you can see which thread crashed, what it was executing, the chain of calls on its stack, and the state of the registers, the raw material for diagnosing a native failure that produced no readable managed trace.

How Games Use Minidumps

When a native crash occurs, a handler writes a minidump file capturing the moment of death, then the game can upload it for analysis. Later, you load the dump into a debugger alongside the matching symbols and build, and the debugger reconstructs the crash: you see the faulting thread's stack, can inspect variables and memory, and can often pinpoint the bad pointer or corrupted state that caused it. It is the closest thing to debugging a crash that happened on a machine you will never touch.

This is especially valuable for the hardest crashes, the intermittent native ones that only happen on specific hardware or after rare sequences. A minidump from a player's machine captures evidence you could never reproduce locally, turning an impossible native crash into one you can actually investigate.

Minidumps, Symbols, and Crash Reporting

Like any release-build crash data, a minidump needs the matching debug symbols to be useful, the symbols translate the dump's addresses into function names and lines. So minidump analysis depends on the same per-version symbol discipline as symbolication. Keep your symbols, and a dump becomes a readable post-mortem; lose them, and it is far harder to interpret.

A crash reporting pipeline ideally captures both managed crash reports and native minidumps, uploads them with their context, and ties them to the build version so they can be symbolicated. Bugnet's crash reporting captures crash data with device context and the build version, so native and managed crashes alike arrive tagged to the right build and grouped by signature, giving you the post-mortem evidence to diagnose even the crashes that happen far below your game code.

A minidump is a post-mortem of a process that died on a machine you'll never touch. With the right symbols, it's almost a live debugger.