Debugging: When Recursive Becomes Recursively Too Much

NOTE: This post – drafted, composed, written, and published by me – originally appeared on and is potentially (c) Microsoft.

Recently, I had a problem with a build environment and, specifically, I was receiving a StackOverflowException.

This is what the exception information looked like from the Application Log perspective:

Faulting application name: <redacted>, version: <redacted>, time stamp: 0x5347902e

Faulting module name: clr.dll, version: 4.0.30319.34014, time stamp: 0x52e0b784

Exception code: 0xc00000fd

Fault offset: 0x00002cf4

Faulting process id: 0x1848

Faulting application start time: 0x01cf815776173165

Faulting application path: <redacted>

Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll

Report Id: b5a7c204-ed4a-11e3-825f-6c3be5144bba

Faulting package full name:

Faulting package-relative application ID:

Not much to go on, right?

I attached adplus (via pmn) and caught the First Chance Exception and process exit dumps. Using the first chance exception dump, I could see (via the stack back-trace) that thread 0 (1eb8) was well over 7,000 frames and that the same objects were repeating on the thread-stack (!dso).

Using this information, I went to the developers of the internal application and they had a compiled fix for me to test and run.

Needless to say, it’s a lot easier to get work done without the StackOverException haunting me

Attached, you’ll find a (heavily-redacted) text file (sort-of) illustrating the recursion in the thread.

Happy debugging! 🙂