x64-Win32 SetUnhandledExceptionFilter does not work with make_fcontext/jump_fcontext about context

[jonasmr]

I tried doing the same thing with one of the samples, and it has the same problem - here is a compressed version of it:

#include <cstdlib>
#include <iostream>
#include <boost/context/continuation.hpp>
LONG WINAPI XptHandler(struct _EXCEPTION_POINTERS* pInfo)
{
	printf("ExceptionHandler\n");
	return EXCEPTION_EXECUTE_HANDLER;
}
void Crash()
{
	intptr_t* p = 0;
	*p = 32;
}
namespace ctx = boost::context;
ctx::continuation f1( ctx::continuation && c) {
	Crash();
    return std::move( c);
}
int main() {
	SetUnhandledExceptionFilter(XptHandler);
    ctx::continuation c;
    int data = 1;
    c = ctx::callcc( f1, data);
	int x;
	std::cin >> x;
    return EXIT_SUCCESS;
}

[olk]

Could you check your example with Win32 please? Maybe the x64 version needs to preserve SEH too.
It migh also be possible that some additional parts of the TEB/TIB must be preserved during context switch too (probably undocumented by MS).

[jonasmr]

I forgot to mention it but the version using callcc was actually using x86(I didnt get around to figuring out how to compile boost in x64).

So it happens for both x64 and x86.

In windbg, !exchain reports a valid exchain in x86:

0:000:x86> !exchain
0000000000b2fe2c: ConsoleApplication1!__scrt_stub_for_is_c_termination_complete+e60 (0000000000a09e20)
0000000000b2ff8c: ConsoleApplication1!__scrt_stub_for_is_c_termination_complete+df0 (0000000000a09db0)
0000000000b2ffa8: ntdll_77b70000!FinalExceptionHandlerPad27+0 (0000000077bf2eeb)
Invalid exception stack at ffffffffffffffff

But not in x64:

0:000> !exchain
7 stack frames, scanning for handlers...
Frame 0x02: error getting module for 00000242ceb92070
Frame 0x03: error getting module for 0000000100000000
Frame 0x04: error getting module for 000000000000808f
Frame 0x05: error getting module for fdfdfdfd00000057
Frame 0x06: error getting module for 0000008034dff980

I assume thats related to your comment about preserving SEH - Not sure if it helps as it still does not call the exception handler in either case.

[olk]

Strange, I assumed that x64 does table-based exception handling and doesn't require the x86's frame based exception handling (SEH chains on the stack). C++ exceptions are thrown and catched without problems in x64 Window apps.
At the moment I've no solution - sorry.

[olk]

Replace
SetUnhandledExceptionFilter(XptHandler);
by
AddVectoredExceptionHandler(1, XptHandler);
XptHandler gets called.

[jonasmr]

While its a proper workaround for the programs i provided, I think it is not a real fix.
As I read it, AddVectoredExceptionHandler and SetUnhandledExceptionFilter serves two different purposes.

Vectored gets called before handlers, Unhandled after.
http://cbloomrants.blogspot.com/2011/11/11-09-11-weird-shite-about-exceptions.html
http://stackoverflow.com/questions/28629351/is-addvectoredexceptionhandler-a-replacement-for-setunhandledexceptionfilter

[olk]

I've no informations where the XptHandler will be stored if SetUnhandledExceptionFilter is used.
I think it is not the TEB because only special parts like stack begin/end, fiber local storage data are exchanged by jump_fcontext. Remains only the stack, but it seams undocumented by MS (at least I didn't found a usefull information at MSDN).
Do you have an idea?

[olk]

as unit tests show, throwing and catching exceptions is working for 32bit/64bit - try/catch and __try/__except

[olk]

I confused that on 32bit '!exchain' shows a correct exception handler chain but not for x64.
The question is if '!exchain' is permitted to e used on x64 (on x64 exception handler chain is not stored on the stack as done in i386).

BTW, at least in MS VC 2015 '!exchain' is not accepted as a vailid command (immediate window).

[jonasmr]

I used !exchain in windbg, there it works on x64 as well.

I dont have any suggestions as to what can be wrong ..

[olk]

I believe that the prologue in jump_fcontext needs some additional statements (save frame pointer) that could fix the problem.

[olk]

you could use WinFibers instead by applying property context-impl=winfib at b2 command line

[jonasmr]

Thanks for the workaround!

Out of curiosity: Do you consider the problem to be unfixable?

[olk]

I believe it is fixable but I'm too busy + I don't use Windows (need for diving deeper into the Windows mechanisms).

[rxra]

Thanks for the workaround!

Out of curiosity: Do you consider the problem to be unfixable?

hello @jonasmr , so yo succeed to have "SetUnhandledExceptionFilter " working now ?
In our project we are using boost::coroutines2::coroutine and we have the same kind of issue : my crash handler is not working if crash hapened in coroutine. And I am a bit lost. I think it is related to "context switch" but cannot find what to do to correctly handle the crash. Do I need to setup my handler differently or do we badly use coroutine. Any help is welcome.

[olk]

You could build/use boost.context/boost.coroutine2 with context-impl=winfib in order to use Windows Fibers instead the assembler (MS does not provide enough infos which parts of TEB have to be copied during context switch)

[rxra]

ok i'll try this. thanks.

[olk]

as long as MS does not publish all relevant infos... yes

[rxra]

Hello again. At this time it is not clear for me where to make the change. Is it a compilation option for boost that I have to change, to use another context implementation. Or is it when I instantiate the coroutine that I have to setup it differently ?

[rxra]

ok I found something
https://www.boost.org/doc/libs/1_68_0/libs/context/doc/html/context/ff/implementations__fcontext_t__ucontext_t_and_winfiber.html

[olk]

ok I found something
https://www.boost.org/doc/libs/1_68_0/libs/context/doc/html/context/ff/implementations__fcontext_t__ucontext_t_and_winfiber.html

correct - compile boost and your application with b2 property

context-impl=winfib

[rxra]

Yeah. It seems it is working. Thanks.