Some resources seem to suggest that instead of using SetUnhandledExceptionFilter to catch unhandled exceptions, one could use AddVectoredExceptionHandler to be notified of all exceptions.
However, as far as I can understand, a vectored handler is "just" called for each and every (SEH) exception raised in the program, prior to determining whether or not or where the exception will be handled.
Am I missing anything?
Good comment:
It is not [a replacement], the callback doesn't promise anything about the exception getting handled. That happens later. It is, at best, useful as a diagnostic tool to troubleshoot problems with a program that contains too many try/catch-em-all statements. Compare to the .NET AppDomain.FirstChanceException event, the kind of feature that requires AVEH.
– Hans Passant
That being said - and after re-reading the docs I do agree - I think the "confusion", if you will, in the original question I linked to, may stem from the original question that stated
it should catch & properly handle all access violation exceptions which occur in the process
which of course you could use a vectored exception handler for, that is, you could intercept all 0xC0000005 via an VEH, but you'd have no clue whether the code around this may actually catch and handle it -- and, at a low level or for specific cases, catching an Access Violation and continuing at the catch site is a valid approach.
So, as Hans says, it is at best, useful as a diagnostic tool.
Or, phrased another way, a Vectored Exception Handler does NOT catch exceptions, if you interpret "catching" an exception in the sense the catch and __except catch a raised exception at a higher level.
The VectoredHandler only supports EXCEPTION_CONTINUE_SEARCH: find a handler and EXCEPTION_CONTINUE_EXECUTION: the use of which I never quite grasped.