How to recover from a EXCEPTION_STACK_OVERFLOW?
in [Win32 Kernel]
|
From: Aurelien Regat-Barrel on 21 Nov 2006 07:17 RichK a ?crit : > 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) Thanks for your reply. I will have a look at SetThreadStackGuarantee, which I didn't know the existence. > As you have noticed, gracefully recovering (or even gracefully failing) > from a stack overflow can be difficult and unreliable. Do you know what is _resetstkoflw() good for ? -- Aur?lien Regat-Barrel
From: Skywing [MVP] on 21 Nov 2006 10:04 It is meant to be used with _alloca allocation failures, at the point of failure (not as a UEF). -- Ken Johnson (Skywing) Windows SDK MVP http://www.nynaeve.net "Aurelien Regat-Barrel" <nospam.aregatba(a)yahoo.fr.invalid> wrote in message news:OUG1bdWDHHA.1224(a)TK2MSFTNGP04.phx.gbl... > RichK a ?crit : > > 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) > > Thanks for your reply. I will have a look at SetThreadStackGuarantee, > which I didn't know the existence. > > > As you have noticed, gracefully recovering (or even gracefully failing) > > from a stack overflow can be difficult and unreliable. > > Do you know what is _resetstkoflw() good for ? > > -- > Aur?lien Regat-Barrel
From: Skywing [MVP] on 21 Nov 2006 10:03 Depends on the protection specified for that subsection in the PE header. -- Ken Johnson (Skywing) Windows SDK MVP http://www.nynaeve.net "Aurelien Regat-Barrel" <nospam.aregatba(a)yahoo.fr.invalid> wrote in message news:el57RkUDHHA.4808(a)TK2MSFTNGP03.phx.gbl... >> 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: G?nter Prossliner on 22 Nov 2006 06:56 Hi Oleg! > You simply should be aware that when you run heavy operations (like > MiniDumpWriteDump) in the process > that has just exhibited unhandled exception, the process state can be > corrupted badly enough for those operations to fail. I thought about it. > In managed applications, probability of such fatal state corruptions > is lower than in native ones, though. It is exactly what I tought too. The primary purpose is to catch unhandled _managed_ exceptions. In most cases it sould be possible to create a MiniDimp even if there has been an unhandled managed Exception. In case of an StackOverflowException, I will try to use Jochens Assembler Routine to recover from that. > Various issues related with reliability of exception filters and > just-in-time debugging have been discussed in this newsgroup before, e.g. > you can > find this thread interesting: > http://groups.google.fi/group/microsoft.public.win32.programmer.kernel/browse_thread/thread/aa0bff4829bf3a44 Your posting within this thread (the last one) is quite informative! Maybe I can implement more than one method to create the MiniDump: Method A: The registered custom Exception Filter calls MiniDumpWriteDump from a new thread within the same process Method B: The registered custom Exception Filter signals a Watchdog Process which creates the dump Method C: The Watchdog Process is attached as a Debugger to the "real" Process and creates the dump without the need to setup an custom Exception Filter. The user of the Component may choose what is nessersary in the concrete case. Maybe you can answer me the following question too: If Method C will be implemented, how much performance does it cost? And one which operations? Where does the performance - degradation come from? The Debugger-Events? > There are two basic options: > > 1) Use just-in-time debugger configured in Registry, system-wide. > The problem with reliability of just-in-time debugging is the same as > with MiniDumpWriteDump - JIT debugger has to be started from the > inside of the crashed process, using CreateProcess function, and > CreateProcess itself can fail because of corruption of the process' > state (e.g. process heap). Ok. If I understand this correctly, choosing the method will not be any safer than creating a Thread in-process which creates the dump (new Process vs. new Thread). > 2) Run the application under debugger all the time (that's what > Jochen meant, probably, and that's also what ADPlus (crash mode) and > similar tools do). > This is much more reliable than JIT debugging, since it is not > affected by the possibly corrupted internals of the crashed process. > Also, it does not depend on Registry. This would be Method C. A last question: Can Method C be implemented without installing the "Debugging Tools for Windows" on the users machine? This is the main reason for me to implement an own component. The first solution I have tried to implement is to create a "mini-installation" of the Debugging Tools for Windows (just with cdb, adplus and the needed dlls). But when looking at redist.txt, you can see that only "dbghelp.dll", "symsrv.dll" and "srcsrv.dll" may be redistributed. "MiniDumpWriteDump" is implemented within "dbghelp.dll", so the distribution would be possible. But may I implement an "Watchdog Debugger" by using just the redist dll's? GP
From: G?nter Prossliner on 22 Nov 2006 07:09
Hi Jochen! > The reason is simple: > > ... > > > Conclusion: There is *no* reliable way to catch *every* unhandled > exception within the same process. Ok. I do understand this now. But the primary purpose is to create Dumps from managed Exceptions. I think that nearly all managed exceptions can be caught by the unhandled exception filter (when not using unsafe code). In case of a StackOverflowException, I will try to use your assembler routine. This should be possible, or not? In case of a OutOfMemory operation, there _may_ be not enoght memory for creating the dump. > 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. What do you think about the Method A, Method B, Method C implementation (see my answer to Oleg)? GP |