How I captured a real StackOverflowException dump

I wanted to prove something to myself: even though .NET refuses to hand StackOverflowException back to you in code, you can see exactly why it happened — with a real dump. In this post I’ll show you the full route: small registry tweak to save crash dumps, a tiny console app that intentionally overflows the stack, and then how to open and debug the resulting .dmp in Visual Studio. This is great for learning, and for building lab cases you can analyze.

What we accomplished

1. Configured Windows Error Reporting (WER) to save crash dumps to C:\Dumps.
2. Created a small Console App that intentionally triggers a StackOverflowException.
3. Ran the app → it crashed. WER created a .dmp file.
4. Opened that dump in Visual Studio and examined the exception, threads, and call stack.
5. Performed a basic diagnostic/debug session (“Debug with Managed Only”) and inspected the recursion chain.

Important: do this only on a test machine/project. Intentionally overflowing the stack will crash the process.

Configuration Steps for Automatic Dump Generation

Step 1: Open the Registry Editor
Press Win + R, type regedit, and hit Enter.
If prompted by UAC, click Yes to allow changes.

Step 2: Navigate to the WER Key
Go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting

Step 3: Create a new key
Right-click on Windows Error Reporting
Select New → Key
Name it:
LocalDumps

           Now you should have:
           HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Step 4: Create the dump configuration values
Inside LocalDumps, create these entries:

           (1) DumpFolder
                Right-click in the right pane → New → String Value
                     Name: DumpFolder
                     Value: C:\Dumps
                     (This is where dump files will be stored — create this folder manually if it doesn’t exist.)

           (2) DumpCount
                Right-click → New → DWORD (32-bit) Value
                     Name: DumpCount
                     Value: 10 (decimal)
                     (This means WER will keep up to 10 dump files before overwriting old ones.)

           (3) DumpType
                Right-click → New → DWORD (32-bit) Value
                     Name: DumpType
                     Value: 2 (decimal)
                     (This means 2 = Full dump (includes full memory) & 1 = Mini dump (smaller file, limited info))

Step 5: Verify folder permissions
Ensure the folder C:\Dumps exists and your app (or service user) has write permissions.

Step 6: Create the .NET Console project (not a class library)
We want a simple console program that will intentionally overflow the stack.

a) Open Visual Studio → Create a new project.

b) Choose Console App (.NET) (pick a modern .NET like .NET 6/8/9).

c) Name it StackOverflowTest. Create the project.

d) Replace Program.cs with this:

namespace StackOverflowTest
{
    class Program
    {
        static void CauseStackOverflow()
        {
            // Intentional infinite recursion
            CauseStackOverflow();
        }

        static void Main()
        {
            Console.WriteLine("Starting StackOverflow test...");
            CauseStackOverflow();
        }
    }
}

e) Build and run the app (and let it crash)
In Visual Studio: Build → Build Solution, then Ctrl+F5 (Run Without Debugging).

dotnet build
dotnet run

You’ll see:
Starting StackOverflow test...

Step 7: Then the process will terminate because of the StackOverflowException. If WER is configured as above, a dump is now in C:\Dumps.

Verify the dump file exists
Open C:\Dumps and look for a file named like:

StackOverflowTest.exe..dmp

Step 8: Open the dump in Visual Studio and read the Minidump summary

Step 9: Open Visual Studio.

1. File → Open → File... → choose the .dmp file from C:\Dumps.
2. Visual Studio will open a Minidump File Summary page with sections like:
3. Dump Summary: exception type and code (for stack overflow you'll see 0xC00000FD)
4. System Information: OS version, CLR version
5. Modules: list of loaded DLLs and their paths

From my run, the dump summary showed:

• Exception Code: 0xC00000FD (stack overflow)
• Exception Information: "The thread used up its stack."
• CLR Version: e.g., .NET 9.0.x

Capturing a stack overflow dump is an essential technique in a debugger’s toolbox. It forces you to look at a post-mortem memory snapshot and gives you exactly what you need: the call stack that exhausted the stack memory. Once you’ve done this once, reading .dmp files becomes a systematic and satisfying process.