I am trying to learn about the exception handling provided by Windows operating system. Now there are two different types of exception handling: One we probably know where we know that this call could fail -- we could use Structured Exception Handling which involves using of try,except, finally blocks. Other is we could register the exception handler So, I got two APIs one is AddVectoredExceptionHandler and other one is SetUnhandledExceptionFilter. I checked they are pointing both to the EXCEPTION_POINTERS structure. For the first use case I am clear of using try blocks whenever necessary, but I am confused for the second type as there are two different APIs so when to use which one?

Hello, Welcome to Microsoft Q&A! According to the Doc: Vectored Exception Handling Vectored handlers are not frame-based, therefore, you can add a handler that will be called regardless of where you are in a call frame. According to the Doc: UnhandledExceptionFilter This function can be called only from within the filter expression of an exception handler. As far as I'm concerned, it is frame-based. According to the link: https://stackoverflow.com/a/54879453/11872808 VEH handlers added by AddVectoredExceptionHandler will handle exceptions before they reach frame-based handlers. Filter set by SetUnhandledExceptionFilter will handle exceptions after frame-based handlers failed. And you could refer to the thread: Is AddVectoredExceptionHandler a replacement for SetUnhandledExceptionFilter? Vectored Exception Handling is useful as a diagnostic tool. Thank you. Jeanine If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Some doubt in Exception Handling

Rohan Pande 445

I am trying to learn about the exception handling provided by Windows operating system. Now there are two different types of exception handling:

One we probably know where we know that this call could fail -- we could use Structured Exception Handling which involves using of try,except, finally blocks.
Other is we could register the exception handler So, I got two APIs one is AddVectoredExceptionHandler and other one is SetUnhandledExceptionFilter. I checked they are pointing both to the EXCEPTION_POINTERS structure.

For the first use case I am clear of using try blocks whenever necessary, but I am confused for the second type as there are two different APIs so when to use which one?

David Lowndes 2,555 Reputation points MVP

2024-03-29T12:10:15.2+00:00

Does the documentation of Vectored Exception Handling and Frame-based Exception Handling help clarify the different uses?
Rohan Pande 445 Reputation points

2024-03-29T12:17:39.61+00:00

I get the point of Frame based exception handling is having a piece of code inside a guarded block like __try and Vectored Exception Handling is registering with a handler that gets invoked if any exception is raised.

Let me restate my question, I am asking the difference between Vectored Exception Handling vs Unhandled Exception Filter? When to use which one?
David Lowndes 2,555 Reputation points MVP

2024-03-29T12:29:16.3333333+00:00

OK, you're not alone in being confused. It's not something I've ever used so I'm not familiar with it. There is a discussion on it here where people endeavour to explain it better than the documentation does. Does that help any?

1 answer

Jeanine Zhang-MSFT 9,786 Reputation points Microsoft Vendor

2024-04-01T03:36:20.3033333+00:00

Hello,

Welcome to Microsoft Q&A!

According to the Doc:Vectored Exception Handling

Vectored handlers are not frame-based, therefore, you can add a handler that will be called regardless of where you are in a call frame.

According to the Doc:UnhandledExceptionFilter

This function can be called only from within the filter expression of an exception handler.

As far as I'm concerned, it is frame-based.

According to the link: https://stackoverflow.com/a/54879453/11872808

VEH handlers added by AddVectoredExceptionHandler will handle exceptions before they reach frame-based handlers.

Filter set by SetUnhandledExceptionFilter will handle exceptions after frame-based handlers failed.

And you could refer to the thread: Is AddVectoredExceptionHandler a replacement for SetUnhandledExceptionFilter?

Vectored Exception Handling is useful as a diagnostic tool.

Thank you.

Jeanine

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Please sign in to rate this answer.
Rohan Pande 445 Reputation points

2024-04-01T08:02:53.2666667+00:00

I tried adding both the handlers VectorException and then Unhandled Exception too.

Below adding a small piece of code that I am trying to run:

#include <iostream> #include <Windows.h> LONG WINAPI MyVectoredExceptionHandler(PEXCEPTION_POINTERS ExceptionPtr) { if (ExceptionPtr->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION) { printf ("Memory access violation occurred, thread id-->%ld\n", GetCurrentThreadId()); //RaiseException (EXCEPTION_INT_DIVIDE_BY_ZERO, EXCEPTION_NONCONTINUABLE_EXCEPTION, NULL, nullptr); } else if (ExceptionPtr->ExceptionRecord->ExceptionCode == EXCEPTION_INT_DIVIDE_BY_ZERO) { printf ("Int divide by zero, thread id-->%ld\n", GetCurrentThreadId()); } else { printf ("Some other exceptions"); } return EXCEPTION_CONTINUE_SEARCH; } LONG WinExceptionHandler( EXCEPTION_POINTERS* pExceptionInfo) { printf ("Inside WinExceptionHandler"); return EXCEPTION_EXECUTE_HANDLER; } void def () { printf ("inside def"); } DWORD WINAPI abc (LPVOID pParms) { printf("inside abc func thread id-->%ld\n", GetCurrentThreadId()); int* ptr = nullptr; *ptr = 10; // Cause an access violation exception int a = 4, b = 0; int res = a/b; def (); return 0; } int main() { HANDLE handle; printf ("inside main thread id-->%ld\n", GetCurrentThreadId()); SetUnhandledExceptionFilter (WinExceptionHandler); AddVectoredExceptionHandler(0, MyVectoredExceptionHandler); handle = ::CreateThread (nullptr, 0, abc, nullptr, 0, 0); WaitForSingleObject (handle, INFINITE); if (handle!=nullptr) { printf ("handle was not null\n"); CloseHandle (handle); } system("pause"); return 0; }

I didn't add anything like guarded blocks like try block but still the output when I run this it first hits the VectoredException Handler, and then Unhandled exception handler.

Since there are no try blocks so this is not frame based exception handling right?

Jeanine Zhang-MSFT 9,786 Reputation points Microsoft Vendor

2024-04-01T08:32:36.7066667+00:00

According to the Doc:Frame-based Exception Handling

A frame-based exception handler consists of the following elements.

A guarded body of code A filter expression An exception-handler block

As far as I'm concerned, if there is no exception-handler block, it is not frame-based.

Darran Rowe 1,041 Reputation points

2024-07-06T22:18:47.6266667+00:00

@rohan pande It is frame based. There is always an exception handling block in the startup code.

If you dig around in the source provided by Visual Studio, you will find the startup code. These are named exe_<entrypointname>.cpp and exe_common.inl. The entrypoint corresponds to your application's entry point function. So if you are using main, then exe_main.cpp would be the startup source file.

Executable startup usually starts by calling <entrypointname>CRTStartup (so mainCRTStartup as an example). The startup code calls __scrt_common_main, which you can find the definition for in exe_common.inl. __scrt_common_main then initialises the security cookie and then calls __scrt_common_main_seh. This is where the first guarded block of code is, it uses a __try/__except block to guard the remainder of the CRT startup including the call to the entrypoint function.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Some doubt in Exception Handling

1 answer

Your answer