Debugging: When Recursive Becomes Recursively Too Much
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! :)