Handling all exceptions in application [modified]
-
Hello fellas! We have a global exception handler "installed" by SetUnhandledExceptionFilter[^] to do some log/dump creating and "gracefully degrade"-ation in case something goes bad. This seems to work quite reliably but...i did some testing by "manually" throwing from inside our code:
throw "stone";
What i don't understand is this: on some systems, this reaches our global handler, creates the dump, displays the "sorry" dialog and shuts down the application, all fine. But on some others, this presents a "CRT runtime error - Abnormal program termination" message box after which is dismissed, the application exits, but our installed global handler doesn't run, so no log/dump is created whatsoever, also, sometimes i see the application "stuck" amongst the processes in task manager. This particularry seems to happen if i build a release of the project, run it (without debugger), make the exception happen, i get the CRT messagebox, if i copy the same executable to a colegue's PC, run it there, then the global handler gets the exception and works as it should. So, can anyone explain to me why this happens and how to change it? I read somewhere that one can also use _set_invalid_parameter_handler[^] to handle CRT exceptions, but the name of this method suggests something else than what i think i am after. Any hints?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
modified on Thursday, September 23, 2010 9:54 AM
-
Hello fellas! We have a global exception handler "installed" by SetUnhandledExceptionFilter[^] to do some log/dump creating and "gracefully degrade"-ation in case something goes bad. This seems to work quite reliably but...i did some testing by "manually" throwing from inside our code:
throw "stone";
What i don't understand is this: on some systems, this reaches our global handler, creates the dump, displays the "sorry" dialog and shuts down the application, all fine. But on some others, this presents a "CRT runtime error - Abnormal program termination" message box after which is dismissed, the application exits, but our installed global handler doesn't run, so no log/dump is created whatsoever, also, sometimes i see the application "stuck" amongst the processes in task manager. This particularry seems to happen if i build a release of the project, run it (without debugger), make the exception happen, i get the CRT messagebox, if i copy the same executable to a colegue's PC, run it there, then the global handler gets the exception and works as it should. So, can anyone explain to me why this happens and how to change it? I read somewhere that one can also use _set_invalid_parameter_handler[^] to handle CRT exceptions, but the name of this method suggests something else than what i think i am after. Any hints?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
modified on Thursday, September 23, 2010 9:54 AM
-
I've had something similar when some other highly clever person in an old team managed to trash the stack. Without the stack there was no way for an exception to find it's way back up to a handler and all sorts of random merriment ensued. Cheers, Ash
I doubt this is the case. The result is always the same CRT-dialog, not random havoc from chaoswille. For testing i started a thread that checks for a certain key-combination and if pressed, throws the exception. There's not much in the call stack that can go wrong (unless somewhere someone corrupts memory maybe but i doubt that) i think.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
I doubt this is the case. The result is always the same CRT-dialog, not random havoc from chaoswille. For testing i started a thread that checks for a certain key-combination and if pressed, throws the exception. There's not much in the call stack that can go wrong (unless somewhere someone corrupts memory maybe but i doubt that) i think.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
Are you catching the exception on the thread that throws it? If the exception gets up to the top of your thread's stack and doesn't find a handler you might just find that something in the CRT is throwing an "Abnormal Application Error..." Cheers, Ash PS: Just thought are you setting your exception filter up in every thread?
-
Are you catching the exception on the thread that throws it? If the exception gets up to the top of your thread's stack and doesn't find a handler you might just find that something in the CRT is throwing an "Abnormal Application Error..." Cheers, Ash PS: Just thought are you setting your exception filter up in every thread?
As the documentation[^] states: "Enables an application to supersede the top-level exception handler of each thread of a process.", so i don't have to explicitly set this up for every thread, and it seems to be working too (mostly at least).
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <