Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I recently read the following about Windows’ exception handling.
In certain unhandled exceptions, such as a double stack fault, the operating system will immediately terminate the application without calling the unhandled exception filter or a JIT debugger.
What is a double stack fault? How does it differ from a regular stack fault?
This phrase probably came from this Codeproject article. That site is not well known for technical review. The true meaning of “double fault” is related to operating system kernels, you get a double fault when the kernel’s fault handler responding to a user-mode fault itself suffers from a fault. Which is fatal and invokes a kernel panic. Blue Screen on Windows. Also something that exists in processors, an x86 core stops executing code when it suffers from a “triple fault”.
Nothing that bad here, what he meant to describe in his article is a condition where a program bombs due to a stack overflow and the code that runs in response to the crash, such as registered with UnhandledExceptionFilter(), consumes the last bit of stack that Windows gives a thread to try to recover from an SO. Which isn’t much, 8192 bytes (two pages) with less than 7080 bytes usable. If such code consume that reserve then the show is over, no further function calls can be made. The kernel raises an access violation and that terminates the process unconditionally.
That small reserve is also the reason that managed code cannot survive an SO, the CLR needs too much stack space to reflect the exception so immediately terminates the program without trying. A generic backgrounder article on guard pages, the underlying mechanism, is here.