使用 minidumps 和 GDB 分析 mingw 编译的可执行文件的崩溃？

Posted 2023-02-21

【中文标题】使用 minidumps 和 GDB 分析 mingw 编译的可执行文件的崩溃？

【英文标题】：Analyze crash using minidumps and GDB for mingw compiled executables?

【发布时间】：2013-11-08 11:44:35

【问题描述】：

我使用 Cmake + mingw 来编译我的项目。由于某个未知的时刻，我的程序在启动时开始崩溃，我想出了如何让 windows 为我崩溃的应用程序制作 minidump。我会使用 GDB 直接调试我的应用程序，但是当我使用 GDB 时，程序不会崩溃。 Google breakpad 包含将 minidumps 转换为 coredumps 的工具，所以我尝试编译 google breakpad 但似乎 breakpad 不是 Windows 解决方案。 我正在寻找解决方案如何检查小型转储并找出我的程序在启动时崩溃的原因。 你是怎么做到的？

【问题讨论】：

我在 Google 中找到了this。你有WinGDB吗？

那是赢得 DBG 而不是 GDB。它需要 PDB 文件，没有它们几乎没有信息。我很想有回溯。 GDB 是 windows 上 mingw 库的一部分。我只需要弄清楚如何检查 mingw 可执行文件的 minidump 文件。

操作，抱歉。我看错了。

【参考方案1】：

您无需分析小型转储。相反，您可以将调试器设置为事后调试器。我在互联网上搜索了“windows replace postmortem debugger with gdb”。看，有 Mingw 博士：https://github.com/jrfonseca/drmingw。这是来自他们的网站：

博士。 Mingw 是一个即时 (JIT) 调试器。申请时 抛出一个未处理的异常，Mingw 博士将自己附加到 应用程序并收集有关异常的信息，使用 可用的调试信息。

我写了一个简单的 C++ 测试：

int f()

  int *ptr = 0;
  *ptr = *ptr +1;
  return  *ptr;


int main()

  f();
  return 0;

构建它：

g++ -g main.cpp

---

这是当我的程序崩溃并且您的磁盘上有源文件时 DrMingw 的输出。如您所见，很容易找到有问题的行：

.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

---

如果测试是使用“-g”构建的，但没有可用的源文件，则 Dr.Mingw 的输出看起来像这样，并且您的程序在哪一行崩溃也很清楚：

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

---

如果测试是在没有“-g”的情况下构建的，那么 Dr.Mingw 的输出如下所示：

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 

【讨论】：

请根据问题添加有关使用带有小型转储的 DrMingw 的信息。

【参考方案2】：

你能在找到它的 PID 后附加到一个崩溃的进程吗？我可以为我的应用执行此操作。

(gdb) attach 1337
Attaching to process 1337
...
(gdb)

Using GDB on Windows