为什么不在应用程序崩溃时启动外部故障转储处理程序？

Question

我正在为我们的一个应用程序设计崩溃处理程序解决方案，该应用程序使用 MiniDumpWriteDump() 函数创建故障转储文件。在阅读该主题时，我看到了从外部进程调用 MiniDumpWriteDump() 以最大限度地提高转储文件包含正确信息的机会的建议。常见的解决方案似乎是 运行 一个与应用进程并行的看门狗进程。当应用程序崩溃时，它会以某种方式联系看门狗进程，为它提供创建故障转储所需的信息。然后应用程序进入休眠状态，直到它被看门狗进程终止。

我可以想象这样一个看门狗进程 运行 持续作为后台服务。这有很多含义，从 "who creates the service?" 开始，还有 "which user does the service run as?" 和 "how does the application contact the service?" 等。这似乎是一个非常重量级的解决方案，我认为它不适合我的范围任务。

this SO answer 建议了一种更简单的方法：在应用程序启动时启动一个与应用程序进程紧密耦合的保护进程。这非常好，但它仍然留给我以下任务：1）在应用程序的某个地方保存信息，以便在发生崩溃时如何联系守卫进程；和 2) 如果应用程序进程正常关闭，请确保终止保护进程。

最简单的解决方案是在崩溃发生时启动故障转储处理进程，将创建故障转储所需的所有信息作为参数传递到过程。此信息包括

• 崩溃的应用进程的进程 ID
• 崩溃线程的线程 ID
• 描述导致崩溃的异常的EXCEPTION_POINTERS结构的地址

这种"fire and forget" 方法很有吸引力，因为它不需要任何状态保留，也不需要任何复杂的超时流程管理。事实上，这个方法看起来非常简单，我不禁觉得我忽略了什么。

反对这种方法的理由是什么？

Answer 1

反对 "fire and forget" 方法的主要论据是，在应用程序已经处于即将崩溃的状态时启动新进程是不安全的.

因此，我选择了 "guard process" 方法。它带来了许多挑战，Hans Passant 对此提出了 outlined a solution。 我还添加了一些代码 应该有助于深度复制最重要的 EXCEPTION_POINTERS 数据结构。

如评论中所建议的那样，使用 WER 看起来也是编写自己的保护进程的一个很好的替代方法。不过，我必须承认我还没有对此进行进一步调查。