How to recover from a EXCEPTION_STACK_OVERFLOW?
in [Win32 Kernel]
|
From: Skywing [MVP] on 20 Nov 2006 14:28 You cannot rely on this unless the exception filter function itself uses SEH, has C++ objects with unwinding, or you have explicitly disabled FPO optimizations... -- Ken Johnson (Skywing) Windows SDK MVP http://www.nynaeve.net "Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach(a)holzma.de> wrote in message news:%235x7FcKDHHA.1016(a)TK2MSFTNGP02.phx.gbl... > Hi Aurelien! >>> static LONG __stdcall CrashHandlerExceptionFilter(EXCEPTION_POINTERS* >>> pExPtrs) >>> { >>> if (pExPtrs->ExceptionRecord->ExceptionCode == >>> EXCEPTION_STACK_OVERFLOW) >>> { >>> static char MyStack[1024*128]; // be sure that we have enought >>> space... >>> // it assumes that DS and SS are the same!!! (this is the case for >>> Win32) >>> // change the stack only if the selectors are the same (this is the >>> case for Win32) >>> //__asm push offset MyStack[1024*128]; >>> //__asm pop esp; >>> __asm mov eax,offset MyStack[1024*128]; >>> __asm mov esp,eax; >>> } >>> >>> // TODO: ... >>> } >> >> Thanks. I guess I can no longer use pExPtrs after modifying esp, nor any >> local variable even if declared after the change? > > Local variables and paramaters are addressed via "ebp". And this points to > the "correct" value (because I have not changed "ebp". > > But you should not use any local variables, because this increases the > (unchanged) stack! > > By the way: There is *no* reliable way to catch unhandled exceptions > in-process! > The only reliable way is to let your ptogram run under a debugger... > > Greetings > Jochen
From: RichK on 20 Nov 2006 15:14 Some ideas that have worked for me are: A) Reduce the amount of local variables in your exception handling, to get the handling to fit in what little stack is available. B) Start a different thread to perform the shutdown. C) On Windows 2003 there is an API SetThreadStackGuarantee, which arranges for a specific amount of stack space to be available during the exception processing of stack overflows. Call this API early in the life of each thread, and you will have a more stack space to work with when a stack overflow occurs. (This API causes the stack overflow to occur sooner, leaving more room for the exception handler) As you have noticed, gracefully recovering (or even gracefully failing) from a stack overflow can be difficult and unreliable. "Aurelien Regat-Barrel" <nospam.aregatba(a)yahoo.fr.invalid> wrote in message news:uxyOHzIDHHA.4024(a)TK2MSFTNGP04.phx.gbl... > Hi, > I am writting an exception filter for my app that displays a message box > and kills the app. The problem is that it does nothing if the exception is > a stack overflow, because some stack space is needed to execute my error > handling code... > I tried to use _resetstkoflw() but it doesn't help. Is there a way to > recover some stack space in order to execute my handler before killing the > app? > I am thinking about: > - modifying ESP by hand (risky) > - unblocking a thread in my handler, and execute my error handling code in > that thread > > Do you have better idea ? > > Thanks. > > -- > Aur?lien Regat-Barrel
From: Jochen Kalmbach [MVP] on 21 Nov 2006 01:45 Hi G?nter! >> By the way: There is *no* reliable way to catch unhandled exceptions >> in-process! > > According to your statement above, this is no good idea. Why? The reason is simple: If an unhandled exception is thrown you do not know what really happend. Of course this is normal. Let use create one scenario: Some API have overwritten some region. If this region is in a data-regions not much damage would occur and the OS should be enable to call the unhandled exception filter. Scenario 2: Your app has (for some reason) overwritten code-regions (for example your unhandled exception filter). Then maybe the OS was able to call your function, but you are not able to do any successfull action. Scenario 3: The app has overwritten some code-region in some OS DLLs (copy-on-write). Then you call some functions in this DLL and a third exception will occur... Conclusion: There is *no* reliable way to catch *every* unhandled exception within the same process. Of course: The same is true for "Dan"s suggestion. The OS is also not possible to catch all exceptions because it relies on the default-implementation of the unhandled exception filter inside the "die-ing" process. If scenario 2 or 3 was the case, then WER is also not able to report this problem. See also other answers... Greetings Jochen
From: Aurelien Regat-Barrel on 21 Nov 2006 03:41 > Scenario 2: > Your app has (for some reason) overwritten code-regions (for example > your unhandled exception filter). Then maybe the OS was able to call > your function, but you are not able to do any successfull action. > Scenario 3: > The app has overwritten some code-region in some OS DLLs > (copy-on-write). Then you call some functions in this DLL and a third > exception will occur... Is it possible to write in code region without having called VirtualProtect, i.e. without explicitly wanted to do so? -- Aur?lien Regat-Barrel
From: Jochen Kalmbach [MVP] on 21 Nov 2006 03:49
Hi Aurelien! > Is it possible to write in code region without having called > VirtualProtect, i.e. without explicitly wanted to do so? AFAIK: At least in W2k... Greetings Jochen |