Using Vectored Exception Handling about crashrpt HOT 5 CLOSED

Ok, I'll try to use it in a future version.

An advantage of VEH is an ability to chain exception handlers, so if somebody
installs exception handler above ours, we still can intercept the exception.

The disadvantage is that VEH is available in WinXP and later. So the presence of
SetVectoredExceptionHandler() function should be checked at run-time.

After reviewing VEH some more time, I think it is problematic to use VEH 
instead of
SetUnhandledExceptionFilter(). 

Vectored exception handling is suitable when you need to monitor _ALL_ 
exceptions,
like a debugger does. But how would CrashRpt decide which exception to handle 
and
which to skip? In client's code, some exceptions may be intentionally guarded by
__try{}__except(){}, and handling such exceptions in VEH and not passing it to
frame-based SEH handler, we may introduce bugs into application logics.

SetUnhandledExceptionFilter() is more suitable, because it is the top-level SEH
handler. If nobody handles the exception, top-level SEH handler is called and 
you
don't need to decide if you should skip the exception or not.

I never use try catch or __try __except in my code, therefore did not notice the
difference. I think you are correct at this point. The VEH is always executed 
before
the __except handler, no matter what "First" parameter is specified. Nor there 
seems
no way to get the chain of all the handlers.

However, VEH also has advantages:

You do not have to worry whether other modules would overwrite your handler
registration. In my code, I call SetUnhandledExceptionFilter in a DLL (to create
minidump when crash), and load it into my exe using LoadLibrary in wWinMain(). 
The
exception handler in DLL is never called. When I call 
SetUnhandledExceptionFilter
when the DLL is being unloaded, I noticed that the handler has been changed to
__CxxUnhandledExceptionFilter (likely to be set by CRT). The same issue is also
stated in the crashrpt FAQ. If I switch to VEH, everything works fine. Because 
of
this, it seems I cannot use crashrpt in my DLL neither, unless the DLL is 
delayed
loaded or I can get rid of the __CxxUnhandledExceptionFilter (do you have any 
idea?
Many thanks!).

As you mentioned, even if the exception is handled in the exe, the handler in 
DLL
will still be called. to work around this, I check the exception address in the
handler. If the exception happens between the DLL base and DLL base + DLL image 
size,
its our exception and handle it. Otherwise, directly return 
EXCEPTION_CONTINUE_SEARCH.

Seems __CxxUnhandledExceptionFilter is registered by every DllMainCRTStartup, 
which
means even if SetUnhandledExceptionFilter is called in the exe's main function, 
if
there is any delay load dll, it is possible to overwrite the handler again. It 
is
quite confusion why __CxxUnhandledExceptionFilter takes over the handler all the
time, even the current unhandled exception filter is not NULL.

Maybe I can hook SetUnhandledExceptionFilter() after my handler is successfully
registered, so that other DLL will never overwrite.

Usage of VEH is problematic, because it requires to manually filter exceptions. 
I
currently do not plan to use VEH in CrashRpt.