views:

79

answers:

3

I have a program that crashes (attempting to read a bad memory address) while running the "release" version but does not report any problems while running the "debug" version in the visual studio debugger.

When the program crashes the OS asks if I'd like to open up the debugger, and if I say yes then I see an arrow pointing to where I am in a listing of some assembler which I am not skilled enough to read properly (I learned 6502 assembler 30 years ago). Is there any way for my to determine where in my sourcecode the offending memory read was located?

+1  A: 

Have a look here.

Gianluca
The article looks like it was written for an older version of the compiler. So for example where it says select "line numbers only" - VS 2008 does not appear to have this as an option - should I select "program database" instead?
Mick
@Mick I don't have VS 2008 but I think adding /Zd to the compiler parameters should still work
Gianluca
+5  A: 

You need to build your program with Debug info enabled (which you can do even for release builds) and that debug info (*.pdb files) must be accessible to the debugger (just copy it beside the executable).
The VS should be able to show you the source, stack and everything else.

sbi
Just a remark. Like that you have to run it in the debugger. This way you may alter the behavior and prevent the crash to happen.If it still crashes, than perfect. Otherwise i suggest to check the link I have posted.
Gianluca
@sbi: If I run the release version in the debugger will it run at near enough full speed?
Mick
@Mick: you don't have to run it in the debugger. As you found yourself, the OS will ask whether you want to debug when the program crashes. (That's called just-in-time debugging.) But the debugger hast to have the debug information in order to make good use of that feature.
sbi
A: 

Just want to add one point apart from what sbi has told you. There are Microsoft Debugging Tools for Windows. This package contains a good book "Debugging Help". Even if you are not going to use WinDbg to analyze crashes you might find reading the "Debugging Help" quite useful.

skwllsp