SetUnhandledExceptionFilter doesnt work
-
I have a C++ DLL that some other programs use. I set SetUnhandledExceptionFilter in the DLL to catch any application crashes. The application crashes, the DLL's ProcessDetach isnt called, but this filter function isnt called either. Any tips for debugging this problem? thanks!
-
I have a C++ DLL that some other programs use. I set SetUnhandledExceptionFilter in the DLL to catch any application crashes. The application crashes, the DLL's ProcessDetach isnt called, but this filter function isnt called either. Any tips for debugging this problem? thanks!
-
I have a C++ DLL that some other programs use. I set SetUnhandledExceptionFilter in the DLL to catch any application crashes. The application crashes, the DLL's ProcessDetach isnt called, but this filter function isnt called either. Any tips for debugging this problem? thanks!
Maybe another module called
SetUnhandledExceptionFilter
and replaced your handler but isn't calling yours. It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE. You could place a breakpoint insideSetUnhandledExceptionFilter
and check for this. Steve -
Maybe someone called ExitProcess? put a breakpoint in ExitProcess and track back the call stack..
__yb wrote:
Maybe someone called ExitProcess?
If that is the case my DLL's ProcessDetach should be called right? Other possibility is TerminateProcess is called.
__yb wrote:
put a breakpoint in ExitProcess and track back the call stack..
I will try this. Although I only have release version of the application - I am not sure if I am going to get the call stack to see. thanks!
-
Maybe another module called
SetUnhandledExceptionFilter
and replaced your handler but isn't calling yours. It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE. You could place a breakpoint insideSetUnhandledExceptionFilter
and check for this. SteveStephen Hewitt wrote:
Maybe another module called SetUnhandledExceptionFilter and replaced your handler but isn't calling yours
How do we detect that? How do find out the currently set unhandled exception filters, if any?
Stephen Hewitt wrote:
It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE
Actually, it used to work earlier. Due to some changes this regressed. I only need tips to debug this.
Stephen Hewitt wrote:
You could place a breakpoint inside SetUnhandledExceptionFilter and check for this.
As I said I already have a message box as the first statement in SetUnhandledExceptionFilter filter, and that doesnt come up. So I am assuming my filter isnt called at all :-( thanks!
-
Stephen Hewitt wrote:
Maybe another module called SetUnhandledExceptionFilter and replaced your handler but isn't calling yours
How do we detect that? How do find out the currently set unhandled exception filters, if any?
Stephen Hewitt wrote:
It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE
Actually, it used to work earlier. Due to some changes this regressed. I only need tips to debug this.
Stephen Hewitt wrote:
You could place a breakpoint inside SetUnhandledExceptionFilter and check for this.
As I said I already have a message box as the first statement in SetUnhandledExceptionFilter filter, and that doesnt come up. So I am assuming my filter isnt called at all :-( thanks!
Brundiez wrote:
How do we detect that? How do find out the currently set unhandled exception filters, if any?
I would use WinDBG as follows: 1. Start the process in question. 2. Type "bp kernel32!SetUnhandledExceptionFilter" in the command window. 3. Press F5. 4. When the breakpoint is hit look at the stack. 5. Goto step 3 This will show every call to
SetUnhandledExceptionFilter
made in the process. I would only pay attention to breakpoints that occur after your call toSetUnhandledExceptionFilter
. Steve