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

Question

Sometimes my C ++ program crashes in debug mode, and I get a window with a message stating that in some procedures for managing internal memory (access to unallocated memory, etc.), the statement failed. But I don’t know where it came from, because I didn’t have a stack trace. How to get a stack trace, or at least see where it doesn't work in my code (instead of library / built-in procedures)?

Answer 1

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

To do this, you need to use the PDB file that was created with your EXE. Place the PDB file in the same directory as the EXE that crashed. Note. Even if you have the same source code, creating twice and using the first EXE and the second PDB will not work. You need to use the exact PDB that was built with your EXE.

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

Then just check your call stack and also open your threads window. You will need to select the thread that crashed and check it in that thread. Each thread has a different call stack.

If you already have your VS debugger, it will automatically go to the source code, which causes a crash for you.

If an accident occurs inside the library that you are using, you do not have a PDB. You cannot do anything.

Answer 2

If you run the debug version on a machine with VS, it should offer to raise it and see the stack trace.

The problem is that the real problem is no longer in the call stack. If you free the pointer twice, this may lead to the problem being in a different place not related to the program (next time something will turn to heap arrays)

I wrote this blog about some tips to identify a problem in the call stack so you can understand what is going on.

http://www.atalasoft.com/cs/blogs/loufranco/archive/2007/02/06/6-_2200_Pointers_2200_-on-Debugging-Unmanaged-Code.aspx

The best advice is to use the gflags utility to create problems with pointers causing immediate problems.

Answer 3

You can call a mini dump by setting a handler for thrown exceptions. Here's an article that explains everything about minidumps

Google actually implemented its own open source crash handler called BreakPad , which also uses mozilla, I think (that if you want something more serious - a rich and reliable crash handler).

Answer 4

This article describes how to calculate the stack trace.

Answer 5

If I remember correctly, the message box should have a button that says 'retry'. Then this should break the program (in the debugger) in the place where this statement occurred.

Answer 6

CrashFinder can help you locate an exception based on the DLL and address of the exception message.
You can take this code and integrate it into your application to automatically generate a stack trace when there is an uncaught exception. This is usually done with __try{} __except{} or with a call to SetUnhandledExceptionFilter , which allows you to specify a callback for all unhandled exceptions.

Answer 7

A debugger can also be installed in the client system after opening. This is a decent general way to get information when you don’t have a dump built into your application (maybe for an older version, for which you should still get information).

R. You can install Watson on Windows by: drwtsn32 -i Starting drwtsn32 (without any parameters) will bring up a configuration dialog. This will allow you to create crash dump files that can later be analyzed using WinDbg or something similar.

Answer 8

You can use Poppy for this. You just cover some macros through your code and it will collect the stack trace along with the actual parameter values, local variables, loop counts, etc. It is very lightweight, so you can leave it in the release build to collect this information from crashes on end-user machines