Process Explorer course

Create Process Dump Files with Process Explorer

Learn how to create minidumps and full process-memory dumps with Process Explorer, choose the correct process, preserve diagnostic context, and prepare files for WinDbg analysis.

A process dump is a point-in-time file containing diagnostic information from a running Windows program. Depending on the selected dump type, it can include working memory, thread state, loaded modules, exception details, and other execution data.

Dump files help investigate application crashes, exceptions, hangs, abnormal behavior, and memory-related failures. A dump is not normally human-readable by itself. Load it into a debugger, such as WinDbg, to inspect threads, call stacks, modules, exceptions, and memory state.

Before You Begin

  • Understand basic Windows processes and the Process Explorer process tree. See the Process Explorer course for related fundamentals.
  • Know how to identify a process by its name and process ID (PID). A PID is the numeric identifier assigned to a running process.
  • Have a writable destination with enough free space, particularly when creating a full dump.
  • Check whether the dump may contain sensitive information before saving or sharing it.
  • Use an elevated Process Explorer session when the target belongs to another user or requires higher privileges. See how to run Process Explorer as administrator.

Minidump and Full Dump Options

Process Explorer provides two relevant commands in a process's context menu: Create Minidump and Create Full Dump.

Characteristic — Minidump — Full Dump

Relative file size — Usually smaller and quicker to save — Often much larger because it captures substantially more process memory

Captured memory and state — Focused diagnostic information, with some memory omitted — Broader process-memory and execution-state capture

Typical use case — First capture for a repeatable crash or initial support report — Hangs, memory-related problems, or investigations requiring data omitted from a minidump

Storage requirements — Generally modest, but still requires a writable destination — Can require substantial free space and may be affected by quotas

Privacy considerations — May still include sensitive in-memory data — Greater chance of containing document fragments, credentials, connection strings, or customer data

Deep-debugging usefulness — Often sufficient for basic exception and stack analysis — More likely to support detailed memory and state analysis

A minidump is a reasonable first capture when you need a relatively small file for an initial crash investigation. Choose a full dump when the initial file lacks the required memory, when investigating a hang, or when a developer or vendor specifically requests a complete capture. Follow organizational approval and data-handling procedures before collecting or sharing either type.

Select the Correct Process

Open Process Explorer and locate the process while the failure or hang is present. Selecting the wrong instance produces a dump that may not contain the relevant application state.

  • Compare the executable name with the application you are investigating.
  • Use the PID to distinguish multiple instances with the same name.
  • Inspect the process tree and parent-child relationship. A child process may perform the actual work while the visible application is only a launcher.
  • Check publisher information, user identity, command-line details, and process properties when available. The Process Properties view can help confirm identity.
  • Consider resource activity and the process's current state. For a hung application, select the instance that is unresponsive rather than another idle instance.

Create a Dump from the Context Menu

  1. Start Process Explorer. Elevate it if the target process requires administrative access.
  2. Find and select the process to investigate.
  3. Right-click the selected process in the process list.
  4. Choose Create Minidump for a focused capture, or Create Full Dump for a broader memory capture.
  5. In the save dialog, select a destination folder and enter an appropriate file name if prompted.
  6. Wait for the capture to complete. Record the saved path and confirm that the dump file exists and has a plausible size.

Creating a dump does not intentionally end the selected process. The application should normally remain running after capture. A large capture can temporarily affect responsiveness and consume CPU, disk I/O, and storage capacity. This action is different from suspend, which pauses execution, and from terminating the process. For related process actions, see Process Actions.

Choose a Useful File Name and Location

Use a destination with sufficient free space and write permission. Full dumps can be large, so check available capacity before starting. Avoid temporary folders that are automatically cleaned before the file can be analyzed.

A descriptive name makes a dump easier to correlate with other evidence. Include the application, capture time, PID, and dump type, for example:

AppName_2026-08-19_1430_PID4820_minidump.dmp
AppName_2026-08-19_1435_PID4820_fulldump.dmp

Preserve related material with the dump:

  • Application name, exact version, and build number
  • Windows edition, version, and architecture
  • Capture date and time, including the time zone when relevant
  • PID and the identity of the selected process
  • Event logs and application logs
  • Steps that reproduce the failure and what the user was doing at capture time
  • Whether the process was crashing, hung, consuming excessive memory, or behaving abnormally

When to Capture a Dump

  • Repeatable crash: Reproduce the failure and capture the process while it is still present. If it remains active after the failure, begin with a minidump for an initial report.
  • Hung application: Capture while the application is unresponsive. A full dump may preserve the thread and memory state needed to determine what caused the hang.
  • Before ending a problematic process: Capture first if later analysis is required, then terminate it only when operationally necessary and authorized.
  • Process already exited: A process that has ended cannot be dumped through the normal live-process context-menu workflow. Use an existing crash dump, configured crash-dump collection, or reproduce the problem while the process is running.

Dump Capture Decision Guide

Situation — Recommended capture — Reason — Additional notes

Repeatable crash — Minidump first — Provides a smaller initial diagnostic file — Reproduce the issue and confirm that the correct process remains available

Unresponsive application — Full dump when permitted and practical — Preserves broader thread and memory state during the hang — Capture before terminating the process

Low disk space — Minidump if it answers the immediate question — Reduces storage and write requirements — Do not start a full capture without enough capacity

Need to share diagnostics externally — Minidump by default, or an approved full dump when required — Limits the amount of potentially sensitive data — Review, protect, and transfer the file according to policy

Multiple matching process names — Either type after verifying identity — The dump is useful only if it comes from the relevant instance — Match the PID, parent process, user, command line, and activity

Access denied — Capture after resolving authorization, if allowed — The operating system or security controls may block access — Elevate Process Explorer or use an approved support workflow

Open the Dump in a Debugger

Load the resulting file into a debugger such as WinDbg, a Windows debugging tool commonly used for dump analysis. The debugger interprets the captured process state and presents information that cannot be understood reliably by opening the file as ordinary text.

Symbols are debugging metadata that map program addresses to meaningful function and source-level names. Correct, matching symbols make call stacks and function names much more useful. Before interpreting results, configure access to the symbols appropriate for Windows and the application, and retain the exact executable and module versions associated with the capture when possible.

Typical analysis goals include:

  • Inspecting exception information and error codes
  • Reviewing the threads active at capture time
  • Examining a call stack, the sequence of active function calls for a thread
  • Identifying loaded modules and their versions
  • Checking memory and other execution-state evidence

Dump analysis may require developer expertise or vendor support, especially when symbols are unavailable, the application is proprietary, or the failure depends on external services. Provide the dump together with the capture time, application build, operating system details, logs, and reproduction notes.

Troubleshooting Capture Problems

The dump command is unavailable or access is denied

Common causes include insufficient privileges, a process owned by another user, a protected process, endpoint security controls, or organizational policy. Run Process Explorer with suitable administrative privileges when authorized. If restrictions remain, verify policy and use the organization's approved support or security workflow. Some protected processes cannot be captured through ordinary methods.

The full dump cannot be saved

Check free disk space, write access to the destination, file-system quotas, and path restrictions. Try a writable location with adequate capacity. Use a minidump if it is sufficient for the immediate diagnostic goal, and do not store the only copy in a folder that may be automatically cleaned.

The dump does not contain enough information

The capture may have been taken from the wrong PID, a minidump may have omitted required memory, symbols may be missing or mismatched, or the failure may not have been active at capture time. Verify the process identity, reproduce the issue, capture while the crash or hang is occurring, configure correct symbols, and collect a full dump when justified and permitted.

The application remains running after capture

This is normal. Dump creation is diagnostic collection, not process termination. Use separate suspend or terminate actions only when operationally necessary and authorized; suspending pauses execution and is not part of ordinary dump creation.

Practical Examples

Application repeatedly crashes during startup

Reproduce the startup failure and locate the application process if it remains active. Verify its PID and create a minidump for an initial support report. Include the dump, application version, Windows details, and reproduction steps.

Application is frozen but still listed as running

Select the unresponsive instance and create a full dump when adequate disk space and approved data-handling procedures are available. Preserve the process for analysis instead of immediately ending it.

Several instances share an executable name

Compare the PID, user, parent process, command-line context, and resource activity. Select the instance that corresponds to the reported behavior before choosing either dump command.

Escalating to a developer

Provide the dump file, capture time, exact application build, operating system details, relevant logs, and a concise description of what the user was doing. State whether the process was crashing, hung, or still responsive.

Key Points

  • Use Create Minidump for a smaller first capture and Create Full Dump when deeper memory analysis is needed.
  • Verify the process name, PID, parent relationship, publisher, and properties before capturing.
  • Dump creation normally leaves the process running, although a large capture can temporarily affect performance.
  • Capture a live process before terminating it when later investigation matters.
  • Protect dump files because they may contain sensitive in-memory data.
  • Use matching symbols and binaries when opening the dump in WinDbg or another debugger.