How to recover from a EXCEPTION_STACK_OVERFLOW?
in [Win32 Kernel]
|
From: G?nter Prossliner on 20 Nov 2006 10:38 Hi Jochen! > By the way: There is *no* reliable way to catch unhandled exceptions > in-process! I have plans to create a managed c++ assembly, which uses the SetUnhandledExceptionFilter API to create a thread which uses "MiniDumpWriteDump" to create a ("adplus" like) memory dump (and performs additional things like compressing, upload to a server, ...). According to your statement above, this is no good idea. Why? On MSDN I have not read about calling in-process is not reliable. It just says, that it may not produce a valid stack trace for the calling thread. This is no problem for me, since the calling thread (which does nothing but calling "MiniDumpWriteDump") will be filtered out by using the MINIDUMP_CALLBACK_INFORMATION parameter. Would this work? Or can I forget about it? > The only reliable way is to let your ptogram run under a debugger... ON of the first questions that I asked myself when thinking about this project was: "Would it not be better to to this from within another processes (a debugger)?". But AFAIK in WinNT (XP) Debuggers can only be registered from within the Registry, and global for all applications. Or am I wrong? It would be really cool to have a function like "SetDebuggerOnCrash(PCTSTR debuggerCommandLine)", which specifies the debugger that will be used (just for this application) on crash. GP
From: Dan Mihai [MSFT] on 20 Nov 2006 11:37 I recommend leveraging whenever possible the Error Reporting mechanisms provided by the Operating System, instead of developing home-grown solutions. http://msdn.microsoft.com/isv/resources/wer/ has information about that. The OS developers encountered many of these fragility problems around error reporting, solved some of them already and keep working on improving this application crash feedback loop. Dan -- This posting is provided "AS IS" with no warranties, and confers no rights. "G?nter Prossliner" <g.prossliner/gmx/at> wrote in message news:eRX%23unLDHHA.3476(a)TK2MSFTNGP04.phx.gbl... > Hi Jochen! > >> By the way: There is *no* reliable way to catch unhandled exceptions >> in-process! > > I have plans to create a managed c++ assembly, which uses the > SetUnhandledExceptionFilter API to create a thread which uses > "MiniDumpWriteDump" to create a ("adplus" like) memory dump (and performs > additional things like compressing, upload to a server, ...). > > According to your statement above, this is no good idea. Why? On MSDN I > have not read about calling in-process is not reliable. It just says, that > it may not produce a valid stack trace for the calling thread. This is no > problem for me, since the calling thread (which does nothing but calling > "MiniDumpWriteDump") will be filtered out by using the > MINIDUMP_CALLBACK_INFORMATION parameter. > > Would this work? > Or can I forget about it? > >> The only reliable way is to let your ptogram run under a debugger... > > ON of the first questions that I asked myself when thinking about this > project was: "Would it not be better to to this from within another > processes (a debugger)?". But AFAIK in WinNT (XP) Debuggers can only be > registered from within the Registry, and global for all applications. Or > am I wrong? > > It would be really cool to have a function like "SetDebuggerOnCrash(PCTSTR > debuggerCommandLine)", which specifies the debugger that will be used > (just for this application) on crash. > > > GP >
From: G?nter Prossliner on 20 Nov 2006 12:24 Hi Dan! > I recommend leveraging whenever possible the Error Reporting > mechanisms provided by the Operating System, instead of developing > home-grown solutions. http://msdn.microsoft.com/isv/resources/wer/ > has information about that. In general, I would agree with your statement. But IMO the WER has some significant drawbacks: * the data is send to Microsoft instead of the own server * you have no control over the UI being displayed ("Microsoft" instead of "Company X"). Not that I think that MS is doing something "evil" with the data. The problem is that the user so not think that MS is responsible for "Product X", and will propably never send the Error Report. > The OS developers encountered many of these fragility problems around > error reporting, solved some of them already and keep working on > improving this application crash feedback loop. I think that this is the right direction. But I hope that there will be more customizations possible in future versions. GP
From: Oleg Starodumov on 20 Nov 2006 13:24 > I have plans to create a managed c++ assembly, which uses the SetUnhandledExceptionFilter API to create a thread which > uses "MiniDumpWriteDump" to create a ("adplus" like) memory dump (and performs additional things like compressing, > upload to a server, ...). > > According to your statement above, this is no good idea. Why? It's not necessarily bad idea, IMO. 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. In managed applications, probability of such fatal state corruptions is lower than in native ones, though. 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 >> The only reliable way is to let your ptogram run under a debugger... > > ON of the first questions that I asked myself when thinking about this project was: "Would it not be better to to this > from within another processes (a debugger)?". But AFAIK in WinNT (XP) Debuggers can only be registered from within the > Registry, and global for all applications. Or am I wrong? > 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). 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. There are other approaches exist, see discussion by the link above (e.g. launch your own debugger using CreateProcess, use a non-debugging watchdog process that creates the dump, etc.). -- Regards, Oleg [VC++ MVP http://www.debuginfo.com/]
From: Skywing [MVP] on 20 Nov 2006 14:08
As Oleg pointed out, calling MiniDumpWriteDump is extremely likely to fail in a corrupted process. I would either use WER or start some kind of watcher process ahead of time which looks for exceptions from the watched process and makes the MiniDumpWriteDump call out of process. With Windows Vista, the WER support is *much* expanded from XP and is actually a viable solution for error reporting now. -- Ken Johnson (Skywing) Windows SDK MVP http://www.nynaeve.net "G?nter Prossliner" <g.prossliner/gmx/at> wrote in message news:eRX%23unLDHHA.3476(a)TK2MSFTNGP04.phx.gbl... > Hi Jochen! > >> By the way: There is *no* reliable way to catch unhandled exceptions >> in-process! > > I have plans to create a managed c++ assembly, which uses the > SetUnhandledExceptionFilter API to create a thread which uses > "MiniDumpWriteDump" to create a ("adplus" like) memory dump (and performs > additional things like compressing, upload to a server, ...). > > According to your statement above, this is no good idea. Why? On MSDN I > have not read about calling in-process is not reliable. It just says, that > it may not produce a valid stack trace for the calling thread. This is no > problem for me, since the calling thread (which does nothing but calling > "MiniDumpWriteDump") will be filtered out by using the > MINIDUMP_CALLBACK_INFORMATION parameter. > > Would this work? > Or can I forget about it? > >> The only reliable way is to let your ptogram run under a debugger... > > ON of the first questions that I asked myself when thinking about this > project was: "Would it not be better to to this from within another > processes (a debugger)?". But AFAIK in WinNT (XP) Debuggers can only be > registered from within the Registry, and global for all applications. Or > am I wrong? > > It would be really cool to have a function like "SetDebuggerOnCrash(PCTSTR > debuggerCommandLine)", which specifies the debugger that will be used > (just for this application) on crash. > > > GP > |