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...
Loading
AlanPosted Dec 10, 2007, 2:48 PM
Hadn't thought of that but it's clearly a useful technique for tracking down this sort of bug.
Thanks for posting it :)
Dr SpackPosted Dec 10, 2007, 10:32 AM
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 SpackPosted Dec 6, 2007, 10:46 AM
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.
AlanPosted Dec 6, 2007, 9:59 AM
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!