2

我正在使用make_fcontextand jump_fcontextfrom boost context 来实现用户空间上下文切换。我使用另一个库来捕获和报告应用程序崩溃。我发现这两个在 Windows 上不能一起工作。

崩溃库SetUnhandledExceptionFilter在启动期间调用以设置异常处理程序以从进程中捕获未处理的异常。然后它处理异常记录以进行崩溃报告。这在大多数情况下都有效，并且我的应用程序中没有其他异常处理。

但是，当在 boost 上下文上运行的线程中发生崩溃（硬件/软件异常）时，我发现设置的异常处理程序没有被触发。似乎相反，启动的内核WerFault.exe会在C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps.

似乎在 boost 上下文上运行会影响内核查找或使用被取代的全局未处理异常过滤器的能力。在 boost 上下文中运行时，堆栈的底部如下所示：

...
my_context_function
make_fcontext+0x76

在普通 Windows 堆栈上运行时：

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

我想知道这里可能出了什么问题。我是 Windows 和 SEH 的新手，所以如果这个问题没有意义，请提前道歉。

4

1 回答 1

1

我认为这是默认上下文的限制，它不会像 Windows 那样做所有事情，这不太可能为您解决。如果你想完全支持 Windows 的东西，你可能应该切换到 Windows Fibers。看起来Boost Context 支持它们。

使用 Windows Fiber 的缺点可能是性能较差。

如果这对您很重要，您可能必须使用快速上下文，并拥有自己的 SEH 框架：

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

当然，这不能保证完全重复 Windows 内部处理。但是你只需要做对你重要的事情，不必重复整个 Windows 内部。

SEH 帧可以集中在一个包装函数中。或者，您可以尝试AddVectoredContinueHandler（据我所知，向量化的继续处理程序是在基于帧的处理程序之后调用的，与AddVectoredExceptionHandler在它们之前调用的不同）。

于 2021-09-28T09:20:35.763 回答