How to Use Microsoft Sysinternals ProcDump to Automatically Generate Crash Dumps Upon Unhandled CLR Exceptions in IIS Worker Processes

Diagnosing intermittent application crashes in production environments is one of the most frustrating tasks for a Windows Server administrator. When an ASP.NET web application hosted in Internet Information Services (IIS) suffers an unhandled Common Language Runtime (CLR) exception, the w3wp.exe worker process violently terminates. The IIS service immediately spins up a new worker process to handle subsequent requests, masking the failure. The only evidence left behind is a cryptic 1026 Event ID in the Windows Application Event Log. To identify the specific line of C# code causing the crash without attaching a live debugger to a production server, administrators must leverage Microsoft Sysinternals ProcDump to autonomously generate full memory crash dumps at the exact millisecond the exception occurs.

The Mechanics of ProcDump

ProcDump is a lightweight, command-line utility designed to monitor a running Windows process for specific CPU spikes or exception codes. When the specified trigger condition is met, ProcDump pauses the process, extracts a complete image of the process’s memory space (a MiniDump), writes it to the disk (a .dmp file), and allows the process to resume or terminate.

Crucially for .NET applications, ProcDump is “CLR aware.” It can hook into the .NET runtime and trigger specifically when unhandled managed exceptions (like a NullReferenceException or OutOfMemoryException) occur, providing developers with a perfect snapshot of the stack trace, the heap, and all local variables at the moment of failure.

Identifying the IIS Worker Process

Before launching ProcDump, you must identify the Process ID (PID) of the specific IIS worker process hosting the failing application pool.

Open an elevated Command Prompt and utilize the native appcmd utility to list the running application pools and their PIDs:

%windir%\system32\inetsrv\appcmd list wp

The output will resemble:

WP "10492" (applicationPool:DefaultAppPool)

In this scenario, the target PID is 10492.

Configuring Autonomous Exception Trapping

Download the Sysinternals suite and extract procdump.exe to a directory on the server (e.g., C:\Sysinternals). Ensure you have created a destination folder to store the dumps (e.g., C:\CrashDumps), as memory dumps for enterprise web applications can consume gigabytes of disk space.

Open an elevated Command Prompt and execute ProcDump with the following parameters:

procdump.exe -ma -e 1 -f "" 10492 C:\CrashDumps

Understanding the critical flags:

• -ma: Write a “Full” dump file. This captures all memory, thread states, and the complete garbage collection heap. Without this, developers cannot inspect the values of variables during the crash.
• -e 1: Instructs ProcDump to create a dump on the “first chance” exception. By default, ProcDump only triggers on “second chance” (fatal/unhandled) exceptions. However, in IIS, the CLR often swallows exceptions or terminates the process before a second chance dump can be fully written. Triggering on the first chance guarantees the capture.
• -f "": This is the exception filter. Leaving it blank captures all exceptions. If you only want to dump when a specific error occurs, you specify it here (e.g., -f "System.NullReferenceException").
• 10492: The PID of the w3wp.exe process.

Monitoring and Analysis

Once executed, ProcDump attaches to the IIS worker process and enters a monitoring loop. The terminal will display “Press Ctrl-C to end monitoring without terminating the process.”

You leave this command window open in the background. The server continues to serve web traffic normally. The moment a user triggers the specific workflow that causes the application to throw the unhandled CLR exception, ProcDump intercepts the fault, writes the massive .dmp file to C:\CrashDumps, and then allows the w3wp.exe process to terminate.

The resulting .dmp file can be compressed and securely transferred to the development team. Using tools like WinDbg (with the SOS extension) or by directly opening the dump file in Microsoft Visual Studio, engineers can navigate the exact stack trace, inspect the values of the HTTP request objects, and pinpoint the flawed C# logic, permanently resolving the instability.