Google-breakpad中无用的转储

Question

I inserted google-breakpad into my test app. But after application crashes and I get info from the dump, in crashed thread always this:

google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread

What am I doing wrong? How can I get usefull crash-place? My "installing code":

VS_ExceptionHandlerDescriptor(std::string dump_path) :
    eh(std::wstring(dump_path.begin(), dump_path.end()), NULL, DumpCallback, NULL, true) {
}

My crash-part code:

   void doCrash()
{
    delete reinterpret_cast<char*>(0xFEE1DEAD);
}

int main()
{
    bool installed = VS_ExceptionHandler::InstallExceptionHandler("C://Users//fetterless/Desktop");

    doCrash();
    return 0;
}

Crashed thread stacktrace:

    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: I Found that the dump from the same crash-program from different computer has different info. From First dump useless as above, on another it shows exactly needed stack and place. What is wrong with this thing?

UPD2: Answer below helped me. I want to add that you can install Cygwin and use it's minidump_stackwalk to produce usefull stack-trace. If you don't want install it and need just stuff for decoding dump, here is archive in which you can find minidump_stackwalk.exe and all needed dll's for it. I took them from my installed Cygwin. minidump_stackwalk archive

Answer 1

I am experiencing the same on some of the Windows machines. Interestingly, Windows 10 works fine for me whereas Windows 7 and 8.1 give results similar to yours. I can only conclude that the problem lies with the stack-walker (minidum_stackwalk.exe or one of the Cygwin dlls). The symbol files and the .dmp file are OK. I actually coped the symbols and the .dmp file from one such problematic Windows machine and was able to generate nice correct call stacks on my Linux box. So, you can also use this as a work-around. But a solution has to come from the Google guys.