VMware ESXi and vSphere Cluster Management

Create Process Dump Files with Process Explorer

Learn how to create minidumps and full process memory dumps with Process Explorer, choose the right dump type, save them safely, and analyze them in WinDbg.

A process dump is a point-in-time capture of a running program's memory and execution-related state. It preserves diagnostic evidence so that you or a support team can investigate the program later. A dump does not repair the application or automatically identify the root cause.

Process Explorer can capture either a minidump or a full memory dump from a selected active process. The capture is performed while the process is running; creating the dump does not terminate the selected process.

Why Create a Process Dump?

Dump files are useful when an application crashes, terminates unexpectedly, becomes unresponsive, or behaves incorrectly. A debugger can use the captured information to examine the state of threads, loaded modules, exceptions, and memory at the time of capture.

• Crash investigation: Examine an exception, failing module, and thread call stacks.
• Hang investigation: Inspect threads and determine what the application was doing when it stopped responding.
• Unexpected behavior: Preserve in-memory state that may help explain incorrect results or abnormal termination.
• Support escalation: Provide reproducible diagnostic evidence to a development or support team.

Important Terms

Before Capturing a Dump

• Make sure Process Explorer is available and that you can identify the affected application.
• Decide whether a lightweight minidump is sufficient or whether a full dump is required.
• Choose a local writable folder and verify that the destination drive has adequate free space.
• Consider whether the process contains confidential information such as credentials, documents, tokens, connection strings, or personal data.
• Obtain authorization before collecting or transferring a dump from another user's process or a business application.

Select the Correct Process

Open Process Explorer and locate the relevant application in the process list. Selecting the correct executable is essential because several processes may have similar names, and an application may use separate helper, renderer, service, or child processes.

Use the available process details to confirm the target. Useful evidence can include the process name, PID, executable path, parent process, owning user, and command line. The PID is especially important when multiple instances have the same executable name.

1. Find the application or the process associated with the problem.
2. Compare its executable path with the expected installation location.
3. Record the PID and, where useful, the parent process and user.
4. Confirm that you are selecting the process that is crashing or frozen, rather than a helper process.

Choose Between a Minidump and a Full Dump

Begin with a minidump when it is likely to answer the question and storage or transfer size matters. Use a full dump when developers need broad memory context, suspect memory corruption, or cannot resolve the issue from a minidump. Both types should be treated as sensitive diagnostic files.

Create a Minidump in Process Explorer

A minidump is a practical first capture for many crashes and initial investigations. It is relatively lightweight and is usually easier to share with a support or development team.

1. Select the confirmed target process in Process Explorer.
2. Open the process's context menu, normally by right-clicking the process.
3. Choose Create Minidump.
4. When prompted, choose a destination folder and enter a descriptive file name.
5. Confirm the save operation and wait for the dump creation to finish.
6. Record the application name, PID, timestamp, symptoms, and reproduction details with the file.

For example, a useful name could be AppName_PID4120_20260818-1430_minidump.dmp. Use a naming convention that identifies the application, PID, capture time, and dump type.

Create a Full Memory Dump in Process Explorer

A full dump captures much more of the selected process's memory. It is useful for detailed debugging, memory-related failures, hangs, and cases where a minidump does not provide enough context.

1. Identify and select the affected process.
2. Verify the PID and executable path, particularly when several instances are running.
3. Check the free space on the destination drive.
4. Open the process's context menu.
5. Choose Create Full Dump.
6. Select a writable destination and provide a descriptive file name when prompted.
7. Allow the capture to complete. Large processes may take considerable time.

Creating the full dump does not end the selected process. If the application is frozen, retain the process after capture when you need to perform additional troubleshooting or compare its behavior.

Choose and Name the Save Location

During either dump operation, Process Explorer displays a save-location prompt. Select a local folder that is writable, available, and protected from unauthorized access. Avoid locations that are disconnected, read-only, unavailable over the network, or protected by permissions that do not allow the current account to create files.

A descriptive naming pattern makes several captures easier to identify:

<application>_PID<pid>_<YYYYMMDD-HHMM>_<dump-type>.dmp

Include the application name, PID, timestamp, and either minidump or fulldump. Keep a separate record of the application version, user-reported symptoms, and what the application was doing at capture time.

Process Explorer Dump Creation Workflow

Analyze the Dump with WinDbg

Dump files are typically opened in WinDbg or another compatible debugger. The debugger's purpose is to turn the captured state into evidence about the failure.

• Review exception information when the process terminated because of an error.
• Inspect thread information to see what each thread was doing.
• Examine call stacks to identify active function calls and possible blocking points.
• Review loaded modules and identify modules associated with the failure.
• Compare addresses, functions, and versions with the application and its dependencies.

Useful function names and stack details often depend on matching symbols and application binaries. Symbols are debugging metadata that allow a debugger to translate raw addresses into meaningful function names and source locations. Missing or mismatched symbols can make a valid dump appear difficult to interpret.

For deeper analysis, ensure that the debugger has access to symbols appropriate for the operating system and the captured application build. If a minidump does not contain the memory or context required for the question, collect a full dump during a comparable failure.

Practical Examples

Lightweight dump after an application crash

1. Check whether the affected application's process is still present in Process Explorer.
2. Verify its path and PID if similar processes are running.
3. Use the process context menu and select Create Minidump.
4. Save the file in a writable diagnostic folder with a timestamped name.
5. Provide the dump and the accompanying application version, symptoms, and capture time to the development or support team.

Full dump of a frozen application

1. Identify the unresponsive process and verify its PID and executable path.
2. Check that the destination drive has enough free space.
3. Open the process context menu and choose Create Full Dump.
4. Save the dump using a name that records the application, PID, time, and dump type.
5. Retain the process for further troubleshooting because dump creation itself does not terminate it.

Prepare a dump for WinDbg analysis

1. Open the saved dump file in WinDbg.
2. Make appropriate symbols and matching application binaries available.
3. Review exception and thread information.
4. Inspect relevant call stacks and loaded modules.
5. Record conclusions together with the dump's PID, timestamp, application version, and reproduction details.

Security and Operational Considerations

A dump may contain any information that was present in the process's memory at capture time. This can include credentials, authentication tokens, documents, personal data, connection strings, encryption material, or portions of user activity. A small dump is not automatically safe, and a full dump generally exposes more memory.

• Restrict access to dump files using appropriate file-system permissions.
• Store dumps only in approved diagnostic locations.
• Use secure, organization-approved transfer methods when sending dumps to support or development teams.
• Delete or retain dumps according to the organization's data-handling and retention rules.
• Check free disk capacity before creating a full dump.

Elevated rights may be necessary when the target process belongs to another user, runs at a higher privilege level, or has protection restrictions. Where authorized, run Process Explorer with appropriate administrative privileges. Organizational policy may prohibit collection from particular processes, and some protected processes may not be dumpable.

Troubleshooting Dump Collection

Dump creation fails or the destination cannot be used

Common causes include a non-writable folder, an unavailable storage device, or insufficient free space. Choose a local folder where the current account has write access, confirm that the destination is connected and accessible, and free space or select another drive. This is especially important for full dumps.

The dump option is unavailable or access is denied

The process may run under another account, at a higher privilege level, or with protection restrictions. Where authorized, restart Process Explorer with suitable administrative privileges and confirm that organizational policy allows the collection. Some protected processes cannot be dumped.

The full dump is unexpectedly large

The process may have a large memory footprint, and a full dump intentionally captures extensive process memory. Check storage capacity, use a minidump if it meets the investigation requirements, and transfer the file only through approved secure channels.

The debugger cannot show useful function names or stacks

Required symbols may be missing or mismatched, the application binaries may not match the captured version, or the dump may not contain enough data for the question being investigated. Use symbols and binaries matching the captured build, collect a full dump when more memory context is needed, and record the version, PID, timestamp, and reproduction details.

The wrong process was dumped

Several instances may share an executable name, or a helper or child process may have been mistaken for the main application. Verify the PID, executable path, command line, user, and parent-child relationships before capture. Record the chosen PID and time in the file name.

Key Takeaways

• Process Explorer can create a minidump or full memory dump from an active selected process.
• Creating a dump does not terminate the selected process.
• Confirm the target with the PID and other process details before capturing.
• Start with a minidump when a lightweight capture is appropriate; use a full dump when deeper memory inspection is required.
• Save dumps to writable storage with enough capacity and descriptive names.
• Analyze dumps in WinDbg using matching symbols and application binaries.
• Treat every dump as potentially sensitive diagnostic data.

For this lesson's complete procedure, return to creating process dump files when you need to review the capture workflow.