如何在 Windows 上检查子进程是否被信号杀死

问题

给定一个在 python 中启动的子进程，其代码类似于：

import subprocess
p = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
p.communicate()
print('Return code: {}'.format(p.returncode))

根据官方文档 https://docs.python.org/3.7/library/subprocess.html#subprocess.CompletedProcess.returncode，可以检查子进程是否被信号终止：

负值 -N 表示子进程被信号 N 终止（仅限 POSIX）。

但仅限于 POSIX 平台。

有没有办法在 Windows 平台上检查进程是否被信号终止（不关心是哪个信号）？

背景

我在运行 googletest 测试时遇到了这个问题。这故障中断 CLI 标志测试 https://github.com/google/googletest/blob/2fe3bd994b3189899d93f1d5a881e725e046fdc2/googletest/test/googletest-break-on-failure-unittest_.cc在 Windows 平台（VC14、VS2017）上失败，但在 POSIX 平台（2x Ubuntu、2x macOS）上运行良好。

在命令行上手动，我得到以下结果：

> .\googletest-break-on-failure-unittest_.exe --gtest_break_on_failure
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Foo
[ RUN      ] Foo.Bar
<some path>\googletest\test\googletest-break-on-failure-unittest_.cc(52): error: Expected equality of these values:
  2
  3

> echo %ERRORLEVEL%
-2147483645

但是，调用此测试的 python 包装器接收2147483651（正数）。

（我之前刚刚添加了一个打印这条线 https://github.com/google/googletest/blob/2fe3bd994b3189899d93f1d5a881e725e046fdc2/googletest/test/gtest_test_utils.py#L290)

请注意，这些指的是数字0xFFFFFFFF80000003（负数）和0x‭80000003‬（正数）以十六进制表示，并且返回代码没有被进一步处理。 （看here https://github.com/google/googletest/blob/2fe3bd994b3189899d93f1d5a881e725e046fdc2/googletest/test/gtest_test_utils.py#L245)

为什么返回码会这样改变呢？

PS：是的，我查过GTEST_OS_WINDOWS and GTEST_HAS_SEH在 C++ 代码中是正确的。

CMD's ERRORLEVEL环境变量是一个 32 位有符号值。正范围是 0x00000000-0x7FFFFFFF（0 到 2147483647），负范围是 0x80000000-0xFFFFFFFF（-2147483648 到 -1）。当进程由于未处理的异常而退出时，状态通常是异常代码，通常是 32 位带符号的NTSTATUS https://msdn.microsoft.com/en-us/library/cc704588价值。也就是说，没有什么可以阻止我们打电话ExitProcess or TerminateProcess带有超过 0x7FFFFFFF 的无符号退出代码，因此负数ERRORLEVELCMD 本身并不意味着进程异常退出。

在本例中，-2147483645 是NTSTATUS code STATUS_BREAKPOINT（0x80000003）。这源于gtest_break_on_failure https://github.com/google/googletest/blob/827515f8a092050901d4eb9fdc1ddbb972f38442/googletest/src/gtest.cc#L4732Google Test 的选项，调用 WinAPIDebugBreak https://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx。对于 x86 架构，后一个函数只是执行一个int 3指令（软件中断3），该指令被捕获在内核中以引发断点异常。

通常，如果没有附加的调试器，这将执行默认的 Windows 未处理的异常处理程序，该处理程序调用Windows 错误报告 https://en.wikipedia.org/wiki/Windows_Error_Reporting（见下文）。但是问题集中链接的代码ExitWithExceptionCode作为应用程序的未处理异常过滤器。该过滤器只是通过以下方式退出exit(exception_pointers->ExceptionRecord->ExceptionCode).

至于Unix信号，Windows内核没有实现它们。 C 运行时实现了标准 C 所需的六个。在控制台应用程序中，标准SIGINT信号与控制台相关联CTRL_C_EVENT。非标的SIGBREAK信号用于其他控制台控制事件，包括CTRL_BREAK_EVENT and CTRL_CLOSE_EVENT。这些事件的默认处理程序调用ExitProcess(STATUS_CONTROL_C_EXIT)。因此，要从字面上回答这个问题，要确定进程是否被控制台“信号”杀死，请检查STATUS_CONTROL_C_EXIT（0xC000013A 或-1073741510）。

处理未处理的异常

• 如果调试器连接到进程调试端口，内核会向其发送第一次机会异常事件。如果它不处理异常，内核会将异常分派到线程的向量异常处理程序和结构化异常处理程序链（基于堆栈，从当前帧反向检查）。我们假设异常没有被它们中的任何一个处理。

• 最后检查的帧是线程启动函数的帧，RtlUserThreadStart。该帧的处理程序，_C_specific_handler，传递一个调度记录，允许它确定范围的异常过滤器。该过滤器依次调用进程的未处理异常过滤器，因为它之前是通过设置的RtlSetUnhandledExceptionFilter。在进程启动时，kernelbase.dll 的初始化例程将其设置为适当命名的函数，UnhandledExceptionFilter.

• 如果连接了调试器，UnhandledExceptionFilter回报EXCEPTION_CONTINUE_SEARCH。随后，内核向调试器发送第二次机会异常事件。如果调试器不处理异常，内核会尝试将事件发送到子系统，即 Windows 会话服务器 csrss.exe。服务器随后将故障转发给 Windows 错误报告 (WER) 服务，该服务最终将终止该进程。

• 如果没有附加调试器，UnhandledExceptionFilter调用应用程序的未处理异常过滤器（如果之前已通过设置）SetUnhandledExceptionFilter https://msdn.microsoft.com/en-us/library/windows/desktop/ms680634。如果应用程序过滤器返回EXCEPTION_CONTINUE_EXECUTION or EXCEPTION_EXECUTE_HANDLER, then UnhandledExceptionFilter将此值返回给帧处理程序。

• 如果应用程序没有设置自己的过滤器或者它的过滤器返回EXCEPTION_CONTINUE_SEARCH, then UnhandledExceptionFilter接下来检查作业、进程和线程错误模式的标志SEM_NOGPFAULTERRORBOX。该标志禁用错误报告，在这种情况下过滤器只是返回EXCEPTION_EXECUTE_HANDLER.

• 如果允许错误报告，UnhandledExceptionFilter调用 Windows 错误报告 (WER) 服务。当 WER 处于循环中时，行为最终取决于它在注册表、组策略中的配置方式以及当前 Windows 版本的默认行为。 WER 可以根据系统“AeDebug”设置创建并附加调试器进程。如果它附加了调试器，UnhandledExceptionFilter回报EXCEPTION_CONTINUE_SEARCH，就像已经附加了一个调试器一样。否则返回EXCEPTION_EXECUTE_HANDLER.

• 最终，如果它执行“未处理”异常的异常处理程序，则堆栈首先展开到RtlUserThreadStart框架通孔RtlUnwindEx，这将调用任何finally中间帧中的终止处理程序。异常处理程序的执行上下文通过以下方式恢复RtlRestoreContext，并且异常代码在整数返回寄存器中设置（例如rax在 x64 中）。最后，处理程序通过以下方式自行终止NtTerminateProcess(NtCurrentProcess(), exceptionCode).