{EDIT to close thread] Rather than post again to this, and bump it to the top... I'll edit the head message... It seems I had "module" and "process" a bit confused; any time a .dll is loaded by a process, it is mapped into that process' address space... so "exit()" and "_exit()" will both work, from either the parent module or the DLL. BTW the crash handling .dll is coming along very well... all we have left to do is pop up the actual dialog... it is logging everything very well. [/EDIT] Been buildin' a heap-nice crash handler for our apps... Buidling it into a separate DLL which isn't loaded into the current process' address space, to keep the stack(s) separate and process memory separate, so that when an unhandled exception occurs, the Dialog box pops up (out of the DLL) and nothing (stack/memory) from the main process is touched (or, touched very much [smile] ) Simple question really... What is the best way, after returning all the information to the user, of getting the main process (.exe) to end? Currently, the Policy class we're using for that is called "AllowCrash", which just sends the unhandled exception back, and pops up Microsoft's crash dialog. This is undesired. We'd like our dialog to be the "last word" before the app quits. "exit()" seems to be good, "_exit()" may be better... but these exit the current process... and if the exception handler (made of policies) is inside the dll, we can't run "exit()" in there... (it would cause the .dll to unload!) Should/can we: 1) Pass a static pointer (to a Terminator object) to a .dll function... which object exists in the .exe process... which would simply run "exit()" inside the .exe? Will that work? Thanks for any reply. Chad [Edited by - Verg on July 24, 2005 4:15:49 PM]

my_life:          nop          jmp my_life

IOW, this is what I'm asking...

//will this work?

//PSEUDO-CODE

// somewhere inside main prog (.exe)DllFunc(&m_staticTerminatorObject);// in DllFunc:void DllFunc(Terminator *terminator){    Set Exception handler with "terminator" ptr...}// when Exception handler is ready to endterminator->exit();// with static instance of "Terminator" created in main process... and...void Terminator::exit(){    _exit(3);}

my_life:          nop          jmp my_life

Quote:Original post by bytecoder
TerminateProcess sounds like it does what you want.

Thanks man... I have seen TerminateProcess...

Yep; but TerminateProcess isn't (in MSDN's words) "the preferred method of exiting a process"...

...then again, a seg-fault isn't the preferred course of action for an app, either [smile]

It's a question of:

...what process is running the ExceptionHandler anyway? It's being called by the system... but since the .dll wasn't loaded by the .exe at runtime...

If the ExceptionHandler, which is instantiated inside the .dll, is being called by the .exe's process, then I could call _exit() directly.

...

If only there were a way to run _exit() from the .exe's process after the ExceptionHandler's had its way... a way to message the .exe process to _exit() immediately... (without using Windows' messages... the .exe process, remember, is in a broken state...)

TerminateProcess may be the only solution then... hrmmm...

my_life:          nop          jmp my_life

How about a thread in the original process? One that checks the existance of a mutex, or something?

Say... if the mutex exists, it would call _exit()?

So... when the .dll's process creates the mutex, the .exe's Termination thread would call _exit()?

Or... do all threads get suspended when the application hits a seg-fault?

my_life:          nop          jmp my_life