我正在为我们的一个应用程序设计崩溃处理程序解决方案，该解决方案使用MiniDumpWriteDump()函数创建故障转储文件 . 在阅读有关该主题的内容时，我已经看到了从外部进程调用 MiniDumpWriteDump() 的建议，以最大限度地提高转储文件包含正确信息的可能性 . 常见的解决方案似乎是与应用程序进程并行运行监视程序 . 当应用程序崩溃时，它会以某种方式联系监视程序进程，为其提供创建故障转储所需的信息 . 然后应用程序进入休眠状态，直到监视程序进程终止它 .
我可以想象这样一个看门狗进程作为后台服务不断运行 . 这有很多含义，从“谁创建服务？”开始，还有“哪个用户将服务运行为？”，以及“应用程序如何联系服务？”它似乎是一个非常重量级的解决方案，我觉得不适合我的任务范围 .
this SO answer建议采用一种更简单的方法：在应用程序启动时启动一个与应用程序进程紧密耦合的保护进程 . 这是非常好的，但它仍然让我完成以下任务：1）在应用程序的某处保存信息，以便在发生崩溃时如何联系警卫程序; 2）如果申请流程正常关闭，请务必终止保护流程 .
最简单的解决方案是在崩溃发生时启动崩溃转储处理程序进程，将创建崩溃转储所需的所有信息作为进程的参数传递 . 此信息包括
-
崩溃的应用程序进程的进程ID
-
崩溃的线程的线程ID
-
EXCEPTION_POINTERS结构的地址，描述导致崩溃的异常
这种“即发即忘”的方法很有说服力，因为它不需要任何状态保留，也不需要任何复杂的超时流程管理 . 事实上，这种方法似乎非常简单，我不禁觉得我忽略了一些东西 .
反对这种方法的理由是什么？
1 回答
正如我所说的那样，反对“即发即忘”方法的主要论点是，当应用程序已经处于崩溃状态时，启动新进程是不安全的 .
因此，我采用了"guard process"方法 . 它带来了许多挑战，Hans Passant已经为此提出了挑战 . 我还添加了一些代码in this answer，这有助于深度复制最重要的
EXCEPTION_POINTERS数据结构 .正如评论中提出的那样，使用WER看起来也是编写自己的守卫进程的一个很好的选择 . 不过，我必须承认我没有进一步调查过这个问题 .