How to recover from a EXCEPTION_STACK_OVERFLOW?
in [Win32 Kernel]
|
From: Skywing [MVP] on 26 Nov 2006 11:55 To add to this, this in particular context switch is especially bad because it is also an address space switch and not just a register context switch, which has severe implications on things like processor caches, TLBs, and whatnot. There is also a lot of overhead if your program frequently creates threads or loads DLLs, as those events cause the entire process to be suspended and the debugger to be awoken. On XP and later, the communication between the debugger and debuggee will by default use a new underlying API (based on the kernel debug object) instead of the LPC port model, but the principles are the same as Oleg has outlined. -- Ken Johnson (Skywing) Windows SDK MVP http://www.nynaeve.net "Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message news:%23054ReAEHHA.4952(a)TK2MSFTNGP06.phx.gbl... >>> 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? >> > > There is a debug port the debugger is listening on. When a debug event > occurs, > a message will be delivered to that port. While the message is being > delivered > and the debugger processes it, the debuggee is suspended. I am not sure > that > I understand all the details of this process (I am not a kernel expert and > can > be wrong), but the main point here is that delivery of debug events > requires > thread context switch, which affects performance the most, even if > the debugger itself processes the event quickly. > >> 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? > > IMO the best way would be to measure how your application works > under debugger (use a custom debugger, or WinDbg, which also processes > debug events very quickly (unlike VS debugger)). > > I did some tests in the past and found that on an application that raises > lots of exceptions the performance hit was very significant (several times > slower > for that particular application). But for most normal applications there > should > be no significant slowdown. > >> Is it possible to subscribe to the needed event(s) only? > > No. > >> 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. >> >> 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? >> > > I think it should be OK. > > Oleg > > > >
From: G�nter Prossliner on 28 Nov 2006 07:24
Hello Skywing! Thank you for your very informative response! > I would recommend the rundll32 option. I have done something very > similar before for a product that I worked on (and in fact also used > rundll32 for this purpose). Is this product closed source? Is is possible to get the (relevant) source? The component I am working on (I am still in the planning phase) will be Open-Source (I will publish it on codeproject.com). GP |