10

A curious question:

How does the well-known "Process is terminated due to StackOverflowException" screen appear if the stack for the current process is full? Is it the runtime saving some registers for its graceful degradation or it's an internal trick that could possibly run another temp process displaying this screen?

P.S. Knowing a possible answer to this question could help someone to build his own "graceful degradation (assuming a very limited functionality of showing such a message)" mechanism from similar critical failure situations.

enter image description here

Arman
  • 5,136
  • 3
  • 34
  • 36
  • duplicate of http://stackoverflow.com/questions/206820/how-do-i-prevent-and-or-handle-a-stackoverflowexception-c – Mike Beeler Jan 29 '13 at 19:10
  • 4
    @Mike.Beeler They are related, but I don't think it's a duplicate. – svick Jan 29 '13 at 19:21
  • See the comment in the answer below "there is no way to intercept this exception if generated by the CLR. Exactly as the question that I am refering you to. – Mike Beeler Jan 30 '13 at 15:25

1 Answers1

11

This message is displayed by the CLR. You can see the code in the SSCLI20 distribution, clr/src/vm/eepolicy.cpp source code file:

void DisplayStackOverflowException()
{
    PrintToStdErrA("\n");

    PrintToStdErrA("Process is terminated due to StackOverflowException.\n");
}

Which in turn is called by the EEPolicy::HandleFatalStackOverflow() method. The only reason you can see it at all is because you are running a console mode app so output to stderr ends up on the console window. And you'll only see it if Windows Error Reporting (WER) hasn't itself terminated the app.

There is no option to intercept this exception, the CLR cannot continue running managed code since there is too little stack space left to run any managed code safely. The line of code after the DisplayStackOverflowException() call is:

    TerminateProcess(GetCurrentProcess(), COR_E_STACKOVERFLOW);
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Hans, thanks for the detailed reply. Then am I thinking right that this window has actually nothing to do with the .net application caused that unfortunate SOE? This console is shown by the CLR or the CLR uses the crashed applications console window to print this output and destroy the process until the WER hasn't itself terminated the app? – Arman Jan 29 '13 at 21:26
  • 2
    If there's too little stack space to run managed code, how come some unmanaged code can still run? – svick Jan 29 '13 at 22:27
  • 2
    Several reasons. It doesn't have to be jitted, will not trigger a GC, will not raise any exceptions, will not cause an assembly to be loaded, has a well defined call-depth. – Hans Passant Jan 29 '13 at 22:39
  • @HansPassant, Now it's clear to me that the runtime prints this msg directly on the output stream of the app being crashed. I guess it has a dedicated dynamic mechanism of the stack limit counting and when it's hit the CLR outputs the msg(for console mode) and then terminates the proc. It definitely should have a free stack to run even unmanaged code though. But that's ought to be a tricky/esoteric part. Would be interesting to know one day. – Arman Jan 30 '13 at 08:45