Analyze crash using minidumps and GDB for mingw compiled executables? - c++

Question

I use Cmake + mingw to compile my project. Since some unknown moment my program started to crash on startup and i figured out how to make windows make minidump for my crashing application. I would use GDB to directly debug my application, but when i use GDB the program doesn't crash.
Google breakpad contain tool to convert minidumps to coredumps, so i tryed to compile google breakpad but it seems breakpad is not windows solution.
I'm searching for solution how to inspect minidump and find why my program crashes on start.
How do you do it?

Answer 1

You don't need to analyze minidumps. Instead you can set your debugger as a postmortem debugger. I have searched on the Internet for "windows replace postmortem debugger with gdb". Look, there is Dr. Mingw: https://github.com/jrfonseca/drmingw . This is from their site:
Dr. Mingw is a Just-in-Time (JIT) debugger. When the application
throws an unhandled exception, Dr. Mingw attaches itself to the
application and collects information about the exception, using the
available debugging information.
I have writen a simple C++ test:
int f()
{
int *ptr = 0;
*ptr = *ptr +1;
return *ptr;
}
int main()
{
f();
return 0;
}
Build it:
g++ -g main.cpp
This is the output of DrMingw when my program crashed and there are source files on your disk. As you can see it is quite easy to locate a line with a problem:
.exe caused an Access Violation at location 0040139C in module a.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=7ffdb000 ecx=00000001 edx=77c51ae8 esi=01cedca2 edi=2eafc26a
eip=0040139c esp=0022ff38 ebp=0022ff48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
AddrPC Params
0040139C 0000001D 7FFDB000 0022FFA0 a.exe!f() [D:\src-c++\test.crasj/main.cpp # 4]
...
{
int *ptr = 0;
> *ptr = *ptr +1;
return *ptr;
}
...
004013BD 00000001 003D3DC0 003D2C78 a.exe!main [D:\src-c++\test.crasj/main.cpp # 11]
...
{
f();
> return 0;
}
...
004010B9 00000001 A9FF6D08 7C90E64E a.exe!__mingw_CRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c # 244]
00401284 2EAFC26A 01CEDCA2 7FFDB000 a.exe!WinMainCRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c # 274]
7C816D4F 0040126C 00000000 78746341 kernel32.dll!RegisterWaitForInputIdle
If the test is build with "-g" but there is no source files availbale then the output of Dr.Mingw looks like this and it is also clear on which line your program crashed:
a.exe caused an Access Violation at location 0040139C in module a.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=7ffd7000 ecx=00000001 edx=77c51ae8 esi=01cedca8 edi=ef612c64
eip=0040139c esp=0022ff38 ebp=0022ff48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
AddrPC Params
0040139C 0000001D 7FFD7000 0022FFA0 a.exe!f() [D:\src-c++\test.crasj/main.cpp # 4]
004013BD 00000001 003D3D98 003D2C50 a.exe!main [D:\src-c++\test.crasj/main.cpp # 11]
004010B9 00000001 F7114D08 7C90E64E a.exe!__mingw_CRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c # 244]
00401284 EF612C64 01CEDCA8 7FFD7000 a.exe!WinMainCRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c # 274]
7C816D4F 0040126C 00000000 78746341 kernel32.dll!RegisterWaitForInputIdle
If the test is build without "-g" then the output of Dr.Mingw looks like this:
a.exe caused an Access Violation at location 0040139C in module a.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=7ffdf000 ecx=00000001 edx=77c51ae8 esi=01cedca4 edi=79abd658
eip=0040139c esp=0022ff38 ebp=0022ff48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
AddrPC Params
0040139C 0000001D 7FFDF000 0022FFA0 a.exe
004013BD 00000001 003D3DC0 003D2C78 a.exe
004010B9 00000001 A9D73D08 7C90E64E a.exe!__mingw_CRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c # 244]
00401284 79ABD658 01CEDCA4 7FFDF000 a.exe!WinMainCRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c # 274]
7C816D4F 0040126C 00000000 78746341 kernel32.dll!RegisterWaitForInputIdle

Answer 2

Can you attach to a crashing process after you find its PID? I could do this for my app.
(gdb) attach 1337
Attaching to process 1337
...
(gdb)
Using GDB on Windows