c++ - 应用程序崩溃，没有任何解释

Question

我想提前道歉，因为这不是一个很好的问题。

我有一个在专用 Windows 服务器上作为服务运行的服务器应用程序。非常随机地，此应用程序崩溃并且没有留下任何关于导致崩溃的原因的提示。

当它崩溃时，事件日志中有一个条目说明应用程序失败，但没有给出原因的线索。它还提供了有关故障模块的一些信息，但它似乎不太可靠，因为故障模块通常在每次崩溃时都不同。比如最新的说是ntdll，前面的说是libmysql，前面的说是netsomething等等。

应用程序中的每个线程都包含在 try/catch (...) 中(任何从异常处理程序抛出的/未专门捕获的)，__try/__except(结构化异常)和 try/catch(特定 C++ 异常)。该应用程序是使用/EHa 编译的，因此 catch all 也将捕获结构化异常。

所有这些异常处理程序都做同样的事情。首先，创建故障转储。其次，一个条目被记录到磁盘上的一个新文件中。第三，在应用程序日志中记录一个条目。在这些崩溃的情况下，这一切都没有发生。最底部的异常处理程序(try/catch (...))什么都不做，它只是终止线程。主应用程序线程处于休眠状态，没有机会抛出异常。

应用程序日志文件只是停止记录。不久之后，监视服务器的进程注意到它不再响应，发送警报并再次启动它。如果服务器监视器注意到服务器仍在运行，但只是没有响应，它会转储进程并报告这一点，但这并没有发生。

除了未捕获的异常，我能想到的唯一其他原因是调用 exit 或类似的。搜索代码不会调用任何可能终止进程的函数。我还确保程序不会正常终止(即来自服务管理器的停止请求)。

我们已经尝试在附加 windbg 的情况下运行它(没有机会使用 Visual Studio，开销太高)，但是当崩溃发生时它没有报告任何内容。

什么会导致应用程序像这样崩溃？我们开始用尽选项并考虑这可能是硬件故障，但我觉得这不太可能。

Answer 1

如果您的应用正在蒸发而不生成转储文件，则很可能正在生成您的应用无法(或无法)处理的异常。这可能发生在两种情况下:

1) 生成了顶级异常，并且没有与该异常类型匹配的 catch block 。

2) 您有一个匹配的 catch block (例如 catch(...))，但是您在该处理程序中生成了一个异常。发生这种情况时，Windows 将从您的程序中删除骨头。您的应用程序将不复存在。不会生成任何转储，并且几乎不会记录任何内容，这是 Windows 为防止流氓程序破坏整个系统所做的最后努力。

关于 catch(...) 的注释。这显然是邪恶的。生产代码中应该(几乎)永远不会有 catch(...)。编写 catch(...) 的人通常会争论两件事之一:

“我的程序应该永远不会崩溃。如果发生任何事情，我想从异常中恢复并继续运行。这是一个服务器应用程序!ZOMG!”

-或-

“我的程序可能会崩溃，但如果确实如此，我想在崩溃的过程中创建一个转储文件。”

前者是一种幼稚而危险的态度，因为如果您确实尝试处理每一个异常并从中恢复，您就会对您的运营足迹造成不利影响。也许您会吞噬堆，使应该关闭的资源保持打开状态，造成死锁或竞争条件，谁知道呢。您的程序最终将遭受致命的崩溃。但到那时，调用堆栈将与导致实际问题的原因毫无相似之处，转储文件也无济于事。

后者是一种高尚而稳健的方法，但它的实现比看起来要困难得多，而且充满了危险。问题是您必须避免在异常处理程序中生成任何进一步的异常，并且您的机器已经处于非常不稳定的状态。通常完全安全的操作突然变成了手榴弹。 new、delete、任何 CRT 函数、字符串格式化，甚至像 char buf[256] 这样简单的基于堆栈的分配都可以让您的应用程序运行>POOF<然后离开。您必须假设堆栈和堆都处于废墟中。没有分配是安全的。

此外，还可能发生 catch block 无法捕获的异常，例如 SEH 异常。出于这个原因，我总是编写一个未处理的异常处理程序，并通过 SetUnhandledExceptionFilter 向 Windows 注册它。 .在我的异常处理程序中，我什至在程序启动之前就通过静态分配分配了我需要的每个字节。在此处理程序中最好(最稳健)的事情是触发一个单独的应用程序启动，这将从您的应用程序外部生成一个 MiniDump 文件。但是，如果您非常小心，不要直接或间接调用任何 CRT 函数，则可以从处理程序本身生成 MiniDump。基本上，如果它不是您调用的 API 函数，它可能不安全。