How can I get the call stack of a StackOverflowException?

Question

Hello everyone I know this one is a little tricky but I hope someone has a hint or an idea. In our application occurs a StackOverflowException (at least I think that) and the result is that the application just closes. The problem is that I am not really sure which Exception occurs because it happens sporadically and only at one of our customers in different parts of our application. So I have checked our code what will happens when I manually force some unhandled exceptions to occur. For example NullReference DivisionByZero OutOfMemeory. No problem at all. They all where handled by the Application.ThreadException event. With a call stack and everything else that is nice to have. Then I tried StackOverflowException. The application crashes and closes with a Dr. Watson hint. No stack trace and no clue where to start searching. Does anyone know how to log the call stack of an StackOverflowException? (Of course without to install Visual Studio on the customers workstations) The application is developed in c# @ .Net Framework 2.0 Many thanks for every tip in advance...

Alan · Answer

Hadn't thought of that but it's clearly a useful technique for tracking down this sort of bug. Thanks for posting it :)

Dr Spack · Answer

For anyone who is still interested in my problem... I solved it! It was indeed a StackOverflow-Exception. I have found it with help of the CLR Managed Debugger (mdbg) Sample: http://www.microsoft.com/downloads/details.aspx?FamilyID=38449A42-6B7A-4E28-80CE-C55645AB1310&displaylang=en Basically I've... ...compiled the debugger ...copied it to the customers computer ...started via a small batch script the debugger and our app ...redirected the output to a log file ...waited for the customers call ...analyzed the log file The only thing that needed some roundtrips was the output of the call stack. It was clipped after 100 frames out of approximately 84000... To cut a long story short... Here is the command line: mdbg.exe !run YourApplication.exe !GO !WHERE -c all !QUIT >>log.txt Thanks

Dr Spack · Answer

Thank you Alan Maybe I just switch back to Framework 1.0! HAR HAR I took a short look at this SEH stuff and at the moment my first test with RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(...) didn't help. But I will try more... Hmmmmm. I cannot believe there is no way to catch such a fatal exception. I have tried to create a new AppDomain… I have tried to start the whole app on a separate Thread… But everything I do my test application still crashes. Thank you again for the RuntimeHelpers. It is the best thing I've got at the moment. And you are right it is possible that there is a property that does a non indented recursion. But it is like the think with bugs. You can proof that there are bugs present. But their absence? ;) So a call stack would still be nice.

Alan · Answer

It was in fact possible to trap the StackOverflowException in the versions of .NET prior to 2.0 but this is no longer the case - the process is just killed stone dead: http://msdn2.microsoft.com/en-us/library/system.stackoverflowexception.aspx FWIW I found the thread below which suggests using the System.Runtime.CompilerServices.RuntimeHelpers class to install a Windows SEH Handler which will trap this exception but I'm not sure that will necessarily help you here: http://www.msnewsgroups.net/group/microsoft.public.dotnet.languages.csharp/topic13241.aspx If it's a StackOverflowException then it's almost certain to be caused by uncontrolled recursion so if you do have any recursive methods in the application then that would be the best place to start looking for the problem. Having said that I had a case recently where a little used property getter was calling itself repeatedly rather than its backing field (the names were the same but the former began with an upper case and the latter a lower case letter) so it's easy to introduce this problem into apparently harmless non-recursive code!