google-breakpad 中的无用转储
Useless dumps in google-breakpad
我将 google-breakpad 插入到我的测试应用程序中。但是在应用程序崩溃并且我从转储中获取信息之后,在崩溃的线程中总是这样:
google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread
我做错了什么?我怎样才能得到有用的 crash-place?我的 "installing code":
VS_ExceptionHandlerDescriptor(std::string dump_path) :
eh(std::wstring(dump_path.begin(), dump_path.end()), NULL, DumpCallback, NULL, true) {
}
我的崩溃部分代码:
void doCrash()
{
delete reinterpret_cast<char*>(0xFEE1DEAD);
}
int main()
{
bool installed = VS_ExceptionHandler::InstallExceptionHandler("C://Users//fetterless/Desktop");
doCrash();
return 0;
}
线程堆栈跟踪崩溃:
Thread 0 (crashed)
0 ntdll.dll + 0x1f911
eip = 0x77c2f911 esp = 0x0057f778 ebp = 0x0057f7e4 ebx = 0x00000000
esi = 0x00000040 edi = 0x00000000 eax = 0x00000000 ecx = 0xeedc6d7f
edx = 0x00000000 efl = 0x00000246
Found by: given as instruction pointer in context
1 kernel32.dll + 0x11193
eip = 0x75cc1194 esp = 0x0057f7ec ebp = 0x0057f7fc
Found by: previous frame's frame pointer
2 kernel32.dll + 0x11147
eip = 0x75cc1148 esp = 0x0057f804 ebp = 0x0057f810
Found by: previous frame's frame pointer
3 CrashTest.exe!google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread(_EXCEPTION_POINTERS *,MDRawAssertionInfo *) [exception_handler.cc : 722 + 0x13]
eip = 0x0019d303 esp = 0x0057f818 ebp = 0x0057f82c
Found by: previous frame's frame pointer
4 CrashTest.exe!google_breakpad::ExceptionHandler::HandleException(_EXCEPTION_POINTERS *) [exception_handler.cc : 506 + 0xd]
eip = 0x0019bc65 esp = 0x0057f834 ebp = 0x0057f86c
Found by: call frame info
5 kernel32.dll + 0x50302
eip = 0x75d00303 esp = 0x0057f874 ebp = 0x0057f8f4
Found by: call frame info
6 ntdll.dll + 0x7344e
eip = 0x77c8344f esp = 0x0057f8fc ebp = 0x0057ffa8
Found by: previous frame's frame pointer
7 ntdll.dll + 0x39854
eip = 0x77c49855 esp = 0x0057ffb0 ebp = 0x0057ffc0
Found by: previous frame's frame pointer
UPD1:我发现来自不同计算机的同一个崩溃程序的转储具有不同的信息。从 First dump useless as above,在另一个上它显示了确切需要的堆栈和位置。这东西怎么了?
UPD2:下面的回答对我有帮助。我想补充一点,您可以安装 Cygwin 并使用它的 minidump_stackwalk 来生成有用的堆栈跟踪。如果您不想安装它并且只需要解码转储的东西,这里是存档,您可以在其中找到 minidump_stackwalk.exe 和所有需要的 dll。我从我安装的 Cygwin 中获取了它们。 minidump_stackwalk archive
我在某些 Windows 机器上遇到了同样的情况。有趣的是,Windows 10 对我来说效果很好,而 Windows 7 和 8.1 给出的结果与你的相似。我只能得出结论,问题在于 stack-walker(minidum_stackwalk.exe 或 Cygwin dll 之一)。符号文件和 .dmp 文件都正常。我实际上从一台这样有问题的 Windows 机器上处理了符号和 .dmp 文件,并且能够在我的 Linux 框中生成正确的调用堆栈。因此,您也可以将其用作变通方法。但是解决方案必须来自 Google 人。
我将 google-breakpad 插入到我的测试应用程序中。但是在应用程序崩溃并且我从转储中获取信息之后,在崩溃的线程中总是这样:
google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread
我做错了什么?我怎样才能得到有用的 crash-place?我的 "installing code":
VS_ExceptionHandlerDescriptor(std::string dump_path) :
eh(std::wstring(dump_path.begin(), dump_path.end()), NULL, DumpCallback, NULL, true) {
}
我的崩溃部分代码:
void doCrash()
{
delete reinterpret_cast<char*>(0xFEE1DEAD);
}
int main()
{
bool installed = VS_ExceptionHandler::InstallExceptionHandler("C://Users//fetterless/Desktop");
doCrash();
return 0;
}
线程堆栈跟踪崩溃:
Thread 0 (crashed)
0 ntdll.dll + 0x1f911
eip = 0x77c2f911 esp = 0x0057f778 ebp = 0x0057f7e4 ebx = 0x00000000
esi = 0x00000040 edi = 0x00000000 eax = 0x00000000 ecx = 0xeedc6d7f
edx = 0x00000000 efl = 0x00000246
Found by: given as instruction pointer in context
1 kernel32.dll + 0x11193
eip = 0x75cc1194 esp = 0x0057f7ec ebp = 0x0057f7fc
Found by: previous frame's frame pointer
2 kernel32.dll + 0x11147
eip = 0x75cc1148 esp = 0x0057f804 ebp = 0x0057f810
Found by: previous frame's frame pointer
3 CrashTest.exe!google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread(_EXCEPTION_POINTERS *,MDRawAssertionInfo *) [exception_handler.cc : 722 + 0x13]
eip = 0x0019d303 esp = 0x0057f818 ebp = 0x0057f82c
Found by: previous frame's frame pointer
4 CrashTest.exe!google_breakpad::ExceptionHandler::HandleException(_EXCEPTION_POINTERS *) [exception_handler.cc : 506 + 0xd]
eip = 0x0019bc65 esp = 0x0057f834 ebp = 0x0057f86c
Found by: call frame info
5 kernel32.dll + 0x50302
eip = 0x75d00303 esp = 0x0057f874 ebp = 0x0057f8f4
Found by: call frame info
6 ntdll.dll + 0x7344e
eip = 0x77c8344f esp = 0x0057f8fc ebp = 0x0057ffa8
Found by: previous frame's frame pointer
7 ntdll.dll + 0x39854
eip = 0x77c49855 esp = 0x0057ffb0 ebp = 0x0057ffc0
Found by: previous frame's frame pointer
UPD1:我发现来自不同计算机的同一个崩溃程序的转储具有不同的信息。从 First dump useless as above,在另一个上它显示了确切需要的堆栈和位置。这东西怎么了?
UPD2:下面的回答对我有帮助。我想补充一点,您可以安装 Cygwin 并使用它的 minidump_stackwalk 来生成有用的堆栈跟踪。如果您不想安装它并且只需要解码转储的东西,这里是存档,您可以在其中找到 minidump_stackwalk.exe 和所有需要的 dll。我从我安装的 Cygwin 中获取了它们。 minidump_stackwalk archive
我在某些 Windows 机器上遇到了同样的情况。有趣的是,Windows 10 对我来说效果很好,而 Windows 7 和 8.1 给出的结果与你的相似。我只能得出结论,问题在于 stack-walker(minidum_stackwalk.exe 或 Cygwin dll 之一)。符号文件和 .dmp 文件都正常。我实际上从一台这样有问题的 Windows 机器上处理了符号和 .dmp 文件,并且能够在我的 Linux 框中生成正确的调用堆栈。因此,您也可以将其用作变通方法。但是解决方案必须来自 Google 人。