How to get a stack trace when C++ program crashes? (using msvc8/2005)

后端 未结 7 710
不知归路
不知归路 2021-02-09 13:44

Sometimes my c++ program crashes in debug mode, and what I got is a message box saying that an assertion failed in some of the internal memory management routines (accessing una

相关标签:
7条回答
  • 2021-02-09 14:29

    You can use Poppy for this. You just sprinkle some macros across your code and it will gather the stack trace, together with the actual parameter values, local variables, loop counters, etc. It is very lightweight so it can be left in the release build to gather this information from crashes on end-user machines

    0 讨论(0)
  • 2021-02-09 14:31

    If you have a crash, you can get information about where the crash happened whether you have a debug or a release build. And you can see the call stack even if you are on a computer that does not have the source code.

    To do this you need to use the PDB file that was built with your EXE. Put the PDB file inside the same directory as the EXE that crashed. Note: Even if you have the same source code, building twice and using the first EXE and the second PDB won't work. You need to use the exact PDB that was built with your EXE.

    Then attach a debugger to the process that crashed. Example: windbg or VS.

    Then simply checkout your call stack, while also having your threads window open. You will have to select the thread that crashed and check on the callstack for that thread. Each thread has a different call stack.

    If you already have your VS debugger attached, it will automatically go to the source code that is causing the crash for you.

    If the crash is happening inside a library you are using that you don't have the PDB for. There is nothing you can do.

    0 讨论(0)
  • 2021-02-09 14:32

    CrashFinder can help you locate the place of the exception given the DLL and the address of the exception reported.
    You can take this code and integrate it into your application to have a stack trage automatically generated when there is an uncaught exception. This is generally performed using __try{} __except{} or with a call to SetUnhandledExceptionFilter which allows you to specify a callback to all unhandled exceptions.

    0 讨论(0)
  • 2021-02-09 14:41

    If I remember correctly that message box should have a button which says 'retry'. This should then break the program (in the debugger) at the point where the assertion happened.

    0 讨论(0)
  • 2021-02-09 14:44

    You can trigger a mini-dump by setting a handler for uncaught exceptions. Here's an article that explains all about minidumps

    Google actually implemented their own open source crash handler called BreakPad, which also mozilla use I think (that's if you want something more serious - a rich and robust crash handler).

    0 讨论(0)
  • 2021-02-09 14:47

    You can also have a post-mortem debugger installed on the client system. This is a decent, general way to get information when you do not have dump creation built into your application (maybe for an older version for which you must still get information).

    Dr. Watson on Windows can be installed by running: drwtsn32 -i Running drwtsn32 (without any options) will bring up the configuration dialog. This will allow the creation of crash dump files, which you can later analyze with WinDbg or something similar.

    0 讨论(0)
提交回复
热议问题