SetUnhandledExceptionFilter does not work with boost context

Question

I'm using make_fcontext and jump_fcontext from boost context to achieve userspace context switching. I use another library to catch and report application crashes. I found these 2 does not work together on Windows.

The crash library calls SetUnhandledExceptionFilter during startup time to setup an exception handler to catch unhandled exceptions from the process. It then processes the exception record for crash reporting. This works most of the time and there is no other exception handling in my application.

However, when a crash (hardware/software exception) happened in a thread running on a boost context, I found that the set exception handler was not triggered. Seems like instead the kernel launched WerFault.exe which generates a minidump under C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps.

It seems like running on a boost context affects the kernel's ability to find or use the superseded global unhandled exception filter. When running on a boost context, the bottom of the stack looks like:

...
my_context_function
make_fcontext+0x76

While running on a normal Windows stack:

...
my_thread_start_function
KERNEL32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

I'm wondering what could possibly go wrong here. I'm new to Windows and SEH so apologize in advance if the question does not make sense.

I think you have almost answered the question yourself with stack listings. In Windows DLLs there is some code like `__try { ... } __except(UnhandledExceptionFilter(GetExceptionInformation()) {}`. But you can have this in your code as well: `__try`, `__except` are MSVC keywords, `GetExceptionInformation()` is a MSVC built-in and `UnhandledExceptionFilter` is a WinAPI function — Alex Guteniev, Sep 27 '21 at 16:25
yes, I'm aware of the Windows DLLs behavior. But I'm not sure if this is a limitation of using boost context this way or a later version might fix the problem for me? I guess I'm trying to look for a solution that would not require adding __try/__except in the context function. Also, I'm not exactly clear about the sequence that the kernel takes to look for an exception handler in this case. — yijiem, Sep 27 '21 at 21:47

score 1 · Accepted Answer · answered Sep 28 '21 at 09:20

I think this is a limitation of default context, which does not do everything that Windows does, which is not likely to be fixed for you. If you want full support of Windows stuff, you probably should switch to Windows Fibers. Looks like Boost Context supports them.

The drawback of using Windows Fiber could be worse performance.

If this matters for you, you probably have to use fast context, and have your own SEH frame:

__try 
{ 
   ... 
} 
__except(UnhandledExceptionFilter(GetExceptionInformation()) 
{
}

Sure this is not guaranteed to repeat Windows internal handling exactly. But you only have to do what matters for you, not necessarily repeating the whole Windows internals.

The SEH frame could be centralized in a wrapper function. Alternatively, you can try AddVectoredContinueHandler (as far as I remember, vectored continue handler is called after frame-based handlers, unlike AddVectoredExceptionHandler which is called before them).

SetUnhandledExceptionFilter does not work with boost context

1 Answers1