Breakpad 异常处理程序未在 Windows 上的 DLL 中使用？

Question

我正在开发一个加载 C++ DLL 的 python 应用程序。在这样的 DLL 中，我们完成了所有繁重的工作，我们希望将 Google 的 breakpad 崩溃报告系统添加到其中。在 Windows 上，一旦加载了 DLL，我们就会实例化一个异常处理程序。但是，当发生崩溃并且永远不会写入 minidump 时，永远不会调用该异常处理程序。当我们对一个简单的 C++ 控制台应用程序使用相同的设置时，一切正常。显然有些东西会阻止异常处理程序仅在它在 DLL 中实例化时才被通知。

我们如何确保在 DLL 中调用 Google 的 breakpad 异常处理程序？

以下是我们使用的设置。框架是在我们开始使用 DLL 之前创建的单例。

#  include <client/windows/handler/exception_handler.h>

bool callback(
  const wchar_t* /*dump_path*/, const wchar_t* /*minidump_id*/, 
  void* /*context*/, EXCEPTION_POINTERS* /*exinfo*/,  MDRawAssertionInfo* /*assertion*/,
  bool succeeded )
{
  std::cout << "dump callback called" << std::endl;
  return succeeded;
}

class Framework
{
  Framework()
    : handler{ std::make_unique<google_breakpad::ExceptionHandler>(  
        L".",       // dump path
        nullptr,    // no filter
        callback,   // to call after writing the minidump
        nullptr,    // callback does not use context
        google_breakpad::ExceptionHandler::HANDLER_ALL ) }
  {
    std::cout << "Exception handler registered" << std::endl;
  }

  ~Framework()
  {
    std::cout << "Exception handler destroyed" << std::endl;
  }  

private:
  std::unique_ptr<google_breakpad::ExceptionHandler> handler;
};

附： : Breakpad 处理程序在我们具有相同设置的 linux 版本的应用程序中运行良好。

感谢您的帮助。

Answer 1

崩溃及其原因在 Windows 和 Linux 上的处理方式完全不同。让我们从 Linux 案例开始，解释为什么该案例能够成功。

在 Linux 上，崩溃的处理是通过信号处理程序在您的程序端完成的。这些是在系统中为您的进程注册的，并在此类信号发送到您的进程后调用。信号处理程序完全独立于您的正常代码流运行，并且无论信号在您的程序中源自何处，都将调用相同的信号处理程序。 Breakpad 为 SIGSEGV、SIGILL 等典型信号安装信号处理程序...

在 Windows 上，崩溃和相关问题的处理不使用信号，而是使用一种称为 SEH (structured exception handling) 的特殊异常。这些异常的工作方式与正常的 C++ 异常非常相似，但通常是通过 __except 而不是 catch 捕获的。这种正常的异常处理要求您的 google_breakpad::ExceptionHandler 对象被自动清理以供识别崩溃的处理程序销毁。 Windows 上的 Linux 信号处理程序没有等效的解决方案。 在典型的应用程序中，如果您想通过 breakpad 报告崩溃，您通常会在启动代码的早期创建 google_breakpad::ExceptionHandler 对象，以便在 SEH 未捕获异常时将其破坏 到达那个地方。