Finding the call-stack from a crash report
 

I am famillair with this article, however, I am having an issue that isn't covered by that article.

The crash is occurring deep in the STL library. I am sure the cause is that I am passing some bad data into it, the real question is where?

It would be nice if I can find the call stack and figure out what was the last execution point in my code was before it started descending down into the STL code.


Are there any articles on this topic someone can point me too? Also something that explain how to understand everything in those crash reports that MS report thingy makes would be great as well.

Re: Finding the call-stack from a crash report
 

Take a look at the followings.

Extended Trace Macros for Win32
Extended Debugging Utility Set
Add Crash Reporting to Your Applications

HTH.

Re: Finding the call-stack from a crash report
 

• turn on debug info and generate pdbs for your components as part of the build. Recommebed to make it a practise even for the time you release. Easier to troubleshoot problems on the field.
• Configure dr. Watson so it generates a crash dump. In Start->Run type in drwtsn32. Check full dump and all the check boxes preferably.
• Run your app and reproduce the issue. The dump file is now generated in the location you specified in drwtsn32.
• Download WinDbg from Microsoft
• Open the dump file using WinDbg
• Also specify the symbol file path and point to your pdb file location.
• In WinDbg command prompt, you type in !analyze -v

You shoudl have some info on the stack trace now

Re: Finding the call-stack from a crash report
 

When I set my symbol path to the debug directory (my release directory doesn't have one) it says that it can not find the symbol file even though there is a .pdb file in the directory.

Re: Finding the call-stack from a crash report
 

I found the !sym noisy command, and I noticed I do not have .dbg files in either of my release or debug directories. I took a quick look in the project settings and did not see a way to make one. BTW I am using VC 7.

Re: Finding the call-stack from a crash report
 

I figured out why my stack dump trace didn't work. The original image came from a release build. If It comes from a debug build everything works fine.

I wish to revise my question. How do you get the call stack from a crash report from a release build when there is no debugging information?

Re: Finding the call-stack from a crash report
 

First point I mentioned:

• turn on debug info and generate pdbs for your components as part of the build. Recommebed to make it a practise even for the time you release. Easier to troubleshoot problems on the field.

It should be available in your project settings. For release builds these are turned off by default.

Re: Finding the call-stack from a crash report
 

I can find the option to turn on debug info for my release builds, but do I want that in my published binaries? I do not want .exe files to go out to the field that have debug info in them. I do not see a direct way to tell VS 7 to create debug info but put them into a seperate file.

Re: Finding the call-stack from a crash report
 

If you use program database, the debug info is in a seperate file. You just don't ship it. That's it.

Here are couple os useful articles on debugging:
http://msdn.microsoft.com/msdnmag/is.../06/Bugslayer/
http://support.microsoft.com/kb/121366
http://www.codeproject.com/debug/releasemode.asp
http://www.codeproject.com/script/Ar...?userid=961412

Re: Finding the call-stack from a crash report
 

If I turn on the generate debug code for my release builds, my code size jumps from 412k to 596k. It is definitly adding stuff to it. I am using a program database file too.

Re: Finding the call-stack from a crash report
 

I don't know much about what goes into the exe for referencing the debug info. But that difference you see seem to be pretty big. I tried an application with/without debug info and noticed the size diff to be 4k. Again, this was a barebones sample app.

Re: Finding the call-stack from a crash report
 

It also didn't create a .dbg file. Do you need one, because the only way to get one AFAIK is throught that rebase utility, which requires you to re-base your application. That is something I am not sure about doing

Re: Finding the call-stack from a crash report
 

What IDE do you use ?
What settings do you use for your compilation and linking ?

Rebasing is not tied to debug info, if I am not wrong. Rebasing has to do with your dll's base load address conflicts. But should not affect the debug info generation.

Re: Finding the call-stack from a crash report
 

Wont help unless you have corrosponding map file to map those addresses into meaningful function names.

Re: Finding the call-stack from a crash report
 

I have map files available, I set up my release builds in a manner consistent with the first article I posted. Unfortunatly, that article doesn't help locate the problem if your 'bug' causes something 4 more levels down the call-stack to crash.