windows MinGW 应用程序的崩溃报告

Crash reporting for MinGW applications

提问by Jong Bor Lee

I have a c++ application compiled with MinGW for which I've been receiving crash complaints from customers. So, besides heavily logging in the parts that might be crashing (before releasing a new version), I've been looking for a crash reporter that will help me find out the stack trace and any other useful debugging information whenever an error arises.

我有一个用 MinGW 编译的 c++ 应用程序，我一直在收到客户的崩溃投诉。因此，除了大量记录可能崩溃的部分（在发布新版本之前），我一直在寻找一个崩溃报告器，它可以帮助我在出现错误时找出堆栈跟踪和任何其他有用的调试信息。

Does any such tool exist that is compatible with MinGW applications?(It seems that there is a close relation between then compiler and the crash reporting strategy, thus the question).

是否存在与 MinGW 应用程序兼容的此类工具？（似乎 then 编译器和崩溃报告策略之间存在密切关系，因此问题）。

Are there any Windows tools that can help me?The application is being run mostly in Windows XP machines.

是否有任何 Windows 工具可以帮助我？该应用程序主要在 Windows XP 机器上运行。

Being able to write information to a file is enough for my purposes. Then I can ask my customer to mail me the information.

能够将信息写入文件就足以满足我的目的。然后我可以让我的客户把信息邮寄给我。

I've been looking into google-breakpadand SetUnhandledExceptionFilter, but I still don't know if they will be useful in any way. Other crash report utilities, such as crashrpt, are designed for Visual C++, so I guess trying them with MinGW doesn't make a lot of sense.

我一直在研究google-breakpad和SetUnhandledExceptionFilter，但我仍然不知道它们是否会有任何用处。其他崩溃报告实用程序，例如crashrpt，是为 Visual C++ 设计的，所以我想用 MinGW 尝试它们没有多大意义。

EDIT: some useful links on the subject

编辑：有关该主题的一些有用链接

• Solving random crashes
• DrMinGW (just in time debugger)
• Some code I used to get a stack trace
• Some people with the same problem:
  • Core dumping under mingw
  • create & read gdb core dump on Mingw32
  • postmortem debugging with MinGW + GDB

• 解决随机崩溃
• DrMinGW（及时调试器）
• 我用来获取堆栈跟踪的一些代码
• 有些人有同样的问题：
  • mingw下的core dump
  • 在 Mingw32 上创建和读取 gdb 核心转储
  • 使用 MinGW + GDB 进行事后调试

采纳答案by 0xC0000022L

Actually the problem is not so much getting the crash reports to work. That is rather trivial with the DbgHelp library functions and most prominently there MiniDumpWriteDump. Remember, however, to redistribute the DbgHelp library on older systems and observe the version requirements for the functions you intend to call - newer versions of Windows come with at least some version of this library.

实际上，问题并不是让崩溃报告起作用。这对于 DbgHelp 库函数来说是相当微不足道的，尤其是在那里MiniDumpWriteDump。但是，请记住，要在旧系统上重新分发 DbgHelp 库并遵守您打算调用的函数的版本要求 - 较新版本的 Windows 至少带有此库的某些版本。

Your problem with using a non-MS compiler (the problem also exists with the Embarcadero, formerly Borland, products, for example, or Watcom) is that the debug symbolscreated make no sense to the DbgHelp library - which is thestandard facility for debugging on Windows. The PDB format is largely undocumented (for some clues search for the terms: Sven Schreiber PDB) and the libraries used to createthem are not "public" in the same sense as the DbgHelp library - the latter can only be used to read/parse the created debug symbols. They are part of the Visual Studio products and usually named something like mspdbXY.dll (where XY are decimal digits).

您使用非 MS 编译器的问题（例如，Embarcadero，以前的 Borland，产品或 Watcom 也存在问题）是创建的调试符号对 DbgHelp 库毫无意义 - 这是调试的标准工具在 Windows 上。PDB 格式基本上没有记录（一些线索搜索术语：Sven Schreiber PDB）并且用于创建它们的库与 DbgHelp 库在同一意义上不是“公共的”——后者只能用于读取/解析创建的调试符号。它们是 Visual Studio 产品的一部分，通常命名为 mspdbXY.dll（其中 XY 是十进制数字）。

So, if you want to create bug reports I strongly suggest that instead of concentrating on the "compiler issues", concentrate on the debugger issues. Here are the general directions in which you can go:

因此，如果您想创建错误报告，我强烈建议您不要专注于“编译器问题”，而是专注于调试器问题。以下是您可以前往的一般方向：

1. Use a debugger that understands your particular debug format (GDB for DWARF in MinGW, IIRC)
2. Use a debugger that understands multiple formats (IDA comes to mind and has other advantages, too ;))
3. Write an extension to something like WinDbg in order to make sense of yourdebug symbols (DWARF) or more generically .mapfiles (I'm aware that such extensions were written some years ago for Borland .mapfiles)
4. Learn assembly language and use the available tools (WinDbg or more generally the DbgHelp library) withoutsymbols (probably a too steep learning curve unless you know it already)

1. 使用了解您特定调试格式的调试器（GDB for DWARF in MinGW, IIRC）
2. 使用理解多种格式的调试器（想到 IDA 并且还有其他优点；））
3. 为 WinDbg 之类的东西写一个扩展，以便理解你的调试符号（DWARF）或更一般的.map文件（我知道这些扩展是几年前为 Borland.map文件编写的）
4. 学习汇编语言并使用可用的工具（WinDbg 或更普遍的 DbgHelp 库）而无需符号（除非您已经知道，否则学习曲线可能太陡峭）

As an extension to 4 you can also let GCC create the .S(assembly) files during compilation in order to cross-reference source code and crash dump when working without symbol support.

作为 4 的扩展，您还可以让 GCC.S在编译期间创建（程序集）文件，以便在没有符号支持的情况下工作时交叉引用源代码和故障转储。

Given that I prefer GDB on unixoid platforms, but WinDbg and other debuggers on Windows, I cannot really say whether there is support for the actual crash dump format (created with MiniDumpWriteDump) in GDB on Windows, so I'm not sure what format may be expected by GDB in this case.

鉴于我更喜欢​​ unixoid 平台上的 GDB，但 Windows 上的 WinDbg 和其他调试器，我真的不能说是否支持MiniDumpWriteDumpWindows 上的 GDB 中的实际故障转储格式（创建），所以我不确定可能是什么格式在这种情况下，GDB 预期。

BTW: if you use Windows XP or higher and can rely on that fact, use AddVectoredExceptionHandlerinstead of SetUnhandledExceptionFilterto prepare writing the crash dump.

顺便说一句：如果您使用 Windows XP 或更高版本并且可以依赖该事实，请使用AddVectoredExceptionHandler而不是SetUnhandledExceptionFilter准备编写故障转储。