Crash reporting for MinGW applications

Question

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.

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).

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

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-breakpad and 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.

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

Answer 1

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.

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 symbols created make no sense to the DbgHelp library - which is the standard 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 create them 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).

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 .map files (I'm aware that such extensions were written some years ago for Borland .map files)
4. Learn assembly language and use the available tools (WinDbg or more generally the DbgHelp library) without symbols (probably a too steep learning curve unless you know it already)

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.

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.

BTW: if you use Windows XP or higher and can rely on that fact, use AddVectoredExceptionHandler instead of SetUnhandledExceptionFilter to prepare writing the crash dump.