How do I analyze a crash dump from a binary built with optimizations enabled (release mode)?

Till now I was using debug mode binaries in project. So it was easy to analyze crash dump using symbol files preserved.

Now i have to ship binaries in Release mode. How we can analyze dump files generated by release mode binary.

1. Is it possible at all 开发者_运维百科?
2. How i identify functions in release mode ? (Do in need to generate and preserve map file)

---

You need the .pdb file that corresponds to the executable. That'll give you the symbols.

There are a couple tricky parts to debugging a release build:

1. The order of operations may be off due to optimizations
2. Whole functions/variables/etc. may be optimized away
3. In particular, the arguments passed into functions may not exist (for example, 'this' may be a register, not a spot in memory). Windbg is pretty good about getting the stack track from that though, including figuring out the arguments.

---

There is no need to have MAP files. You need to enable "Generate Debug Info" /DEBUG flag, even for Release build. On VS2008 and higher, the /DEBUG flag is set even for Release builds. On earlier versions you need to explicitly do it.

This will generate .PDB files for your .EXE/.DLL and you must keep them along with your executables/DLLS (You may or may not give to clients, that's your choice). When the crash dump occurs, you should have/get the .DMP file. Just load that DMP file in Visual Studio, from the location where you have stored the PDB files. This will show the call stack where the crash occurred.

If there are multiple threads, you need to switch to 'Threads' window and look for 'Suspended' column. The column having suspended as 1 is the thread that caused the crash.

Using this you can see the proper call stack for ALL running threads. But you will also need to have correct copy of source-code to see the code! Otherwise it would just be assembly. Partial source code of MFC/ATL/STL etc might be visible, but not your code, unless you do have correct source code in place.

PDB files do store the path of source code, and they would enable the debugger to load the source files, even if source is not from the location where you have placed PDB and the DMP file.