Бесполезные дампы в гугл-брейкпаде

Я вставил google-breakpad в мое тестовое приложение. Но после сбоя приложения, и я получаю информацию из дампа, в сбойном потоке всегда так:

google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread

Что я делаю неправильно? Как я могу получить полезное место аварии? Мой «установочный код»:

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;
}

Stackcece разбитой нити:

    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: Я обнаружил, что дамп из одной и той же аварийной программы с другого компьютера имеет разную информацию. Из первого дампа бесполезно, как указано выше, на другом он показывает точно необходимый стек и место. Что не так с этой вещью?

UPD2: Ответ ниже помог мне. Я хочу добавить, что вы можете установить Cygwin и использовать его minidump_stackwalk для создания полезной трассировки стека. Если вы не хотите устанавливать его и вам нужны только вещи для декодирования дампа, вот архив, в котором вы можете найти minidump_stackwalk.exe и все необходимые библиотеки DLL для него. Я взял их из моего установленного Cygwin. архив minidump_stackwalk

1

Решение

Я испытываю то же самое на некоторых машинах Windows. Интересно, что Windows 10 прекрасно работает для меня, тогда как Windows 7 и 8.1 дают результаты, аналогичные вашим. Я могу только заключить, что проблема заключается в стеке-ходунке (minidum_stackwalk.exe или один из Cygwin dll). Файлы символов и файл .dmp в порядке. Я на самом деле скопировал символы и файл .dmp с одного такого проблемного компьютера с Windows и смог сгенерировать хорошие правильные стеки вызовов на моем компьютере с Linux. Таким образом, вы также можете использовать это в качестве обходного пути. Но решение должно прийти от ребят из Google.

1

Другие решения

Других решений пока нет …