How to recover from a EXCEPTION_STACK_OVERFLOW?
in [Win32 Kernel]
|
From: Aurelien Regat-Barrel on 24 Nov 2006 10:30 Hi, > Mode "Safe": It starts an watchdog-process (actually rundll32.exe with an > exported "DebuggerMain" from my dll (by using rundll32 I must not deploy > anything else but the dll), which attaches to the application as a Debugger, > and calls "MiniDumpCreateDump" within the watchdog process. You can also use your program that you can start in debugger mode. Depending on command line, it can attach itself to the process whose PID is given in argument: int main( int argc, char *argv[] ) { crash_guard guard; if ( !guard.start_watchdog( argc, argv ) ) { return 0; } // normal code goes here } The first time start_watchdog() is called, it doesn't find any special command line argument, so it starts itself as a child process giving it its PID (a kind of fork()). Then it returns true. The child process will also call start_watchdog(), find the command line argument(), and starts executing without returning. When it does (after the given process exited), it returns true and execution stops. Depending on the configuration/command line/registry settings/..., start_watchdog() can also start a new thread, or simply install a filter. -- Aur�lien Regat-Barrel
From: Ben Voigt on 24 Nov 2006 11:11 "G�nter Prossliner" <g.prossliner/gmx/at> wrote in message news:%23fUlrG9DHHA.3596(a)TK2MSFTNGP03.phx.gbl... > Hello Oleg! > > > Thank you for your informative answer! > >>> 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? >>> >> >> Yes, the performance hit is coming from dispatching debug events to >> the debugger. >> So if the application generates lots of events (usually exceptions, >> also debug output, module load/unload, thread start/exit, etc.), it >> can be slowed down. If there is not too many debug events, >> performance will not be seriously affected. > > Ok. In the "normal program flow" there shall be not too many of them. How > are the calls serialized between the debuggee and the debugger? Over > shared memory? > > When I do nothing within the most event-procedures (only unhandled > exceptions will be processed) is it possible to say how much overhead it > will be? Is it possible to subscribe to the needed event(s) only? > >> This is if you attach debugger to an already running application. If >> you start the app under debugger (which you shouldn't do IMO), there >> will be lots of various debug checks enabled by default (heap, etc.), >> which will hurt performance too. > > The application will not be started under the debugger. > >>> 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). >>> >> >> Yes, though creating a new thread from the filter is not a good idea >> IMO, >> I would better recommend to create the helper thread beforehand, then >> the failing thread would only need to set one event and wait for >> another - >> same as with external watchdog. > > This is a very good idea! I will go on with that. > > > I will implement the following methods: > > You can configure the DumpHelper by using two modes: > > Mode "Fast": It creates a thread which waits for an event to be set until > it calls "MiniDumpCreateDump" in process. The event will be set from the > custom unhandled exception filter. My worry here would be that the process might die before the other thread gets scheduled. Your unhandled exception filter will have to wait on the other thread somehow. > > Mode "Safe": It starts an watchdog-process (actually rundll32.exe with an > exported "DebuggerMain" from my dll (by using rundll32 I must not deploy > anything else but the dll), which attaches to the application as a > Debugger, and calls "MiniDumpCreateDump" within the watchdog process. > > I will forget about the third method (creating a debugger-process within > the unhandled exception filter which creates the Minidump) because > according to your posting it is not any safer than the "Fast" mode. > > What do you think about it? > A better version of option 3 is to combine the other two solutions. Run your watchdog process all the time, but wait for an event before attaching the debugger. The problem of keeping the process alive until the watchdog wakes is still present. > > GP >
From: Aurelien Regat-Barrel on 24 Nov 2006 11:36 Hi Ben, Ben Voigt a �crit : > A better version of option 3 is to combine the other two solutions. Run > your watchdog process all the time, but wait for an event before attaching > the debugger. The problem of keeping the process alive until the watchdog > wakes is still present. By starting the watchdog as a child process, you could make it to inherit a kernel object (an event for example) to set once it is ready ? -- Aur�lien Regat-Barrel
From: Ben Voigt on 24 Nov 2006 12:04 "Aurelien Regat-Barrel" <nospam.aregatba(a)yahoo.fr.invalid> wrote in message news:O1RfBc%23DHHA.3524(a)TK2MSFTNGP06.phx.gbl... > Hi Ben, > > Ben Voigt a �crit : >> A better version of option 3 is to combine the other two solutions. Run >> your watchdog process all the time, but wait for an event before >> attaching the debugger. The problem of keeping the process alive until >> the watchdog wakes is still present. > > By starting the watchdog as a child process, you could make it to inherit > a kernel object (an event for example) to set once it is ready ? Named events can be used for communication between processes. You might need one event set by the exception handler "APPNAME_BEGINDUMP" and one set by the watchdog "APPNAME_DUMPCOMPLETE" > > -- > Aur�lien Regat-Barrel
From: Ben Voigt on 24 Nov 2006 12:15
> could call HeapValidate before HeapDestroy, but ergh, I am not writing > software for the Space Shuttle :-) I wish you were, as I write software that processes the telemetry data downlinked via satellites, and trust me, some of the "non-critical" parts of the on-board software don't do nearly as good a job of error handling. |