VC++ debugger

[ADoozer]

hello all.

ive been programming in c++ for about 4 years now (although i favour vb for the past 2) but i still havent figured out how to use the debugger.

can anyone recommend a tutorial/book that will teach me how to use it properly (ive tried learning assembly but that just confuses me).

i have limited experiance using softice but this doesnt seem to help me either.

any input appreciated! If somethings hard to do, its not worth doing - Homer Simpson

 

[palbano]

>> i still havent figured out how to use the debugger.

can you be more specific? After reading your post i want to tell you press F5 to begin a debug session but i'm sure you don't mean that.

-pete

 

[BoulderBum]

I bet he's talking about when you step into a block that take you to all that assembly code.

Maybe this will help, maybe not:

-hit f9 while on a line to insert or remove a breakpoint (a point you want execution to temporarily stop
-hit f5 to run to the next breakpoint

-hit f10 to "step over" a block of code, line by line, which means that e.g. if a function is called in the current line, that function runs, and your step to the next line

-hit f11 to "step into" a block of code, which means e.g. if a function is called in the current line, the debugger would take you into the function code, which would be anylized line by line

If you get sucked into some confusing assembly code or something (with all the stacks), then it's usually best to just close the assembly code window, and...

-hit shift-f11 to "step out" of the code, and return to the line after the one that was "stepped into"

 

[ADoozer]

hi again, ok sorry i wasnt clear enough. i know how to step through my code, what im looking for info on, is how to interpret the code in the disassembly window. when a program crashes and takes you to the c++ debugger i want to know what/why and how the program crashed.

thanks for your time and sorry for the confusion. If somethings hard to do, its not worth doing - Homer Simpson

 

[LazyMe]

You'll have to learn assembly for that (inspite of your confusing about assembly language)...

Also, this type of debugging won't lead you to very much understanding of exactly what happened. Well, actually it will tell you that, but it won't tell you what happened and where, since there's no such thing as a callstack or variable views in non-debug executables (you need a program database for that).
Greetings,
Rick

 

[ADoozer]

lazyme: thnx, i was hoping that wasnt the answer

do you (or anyone) know what "version"(?!?!) of assembly i should be reading up on, or know of a site/book that has a "hello world" style introduction to assembly? (everything ive read so far throws me in at the deep end)

again thnx for the help/info! If somethings hard to do, its not worth doing - Homer Simpson

 

[palbano]

ADoozer,

that's not what i do! When i get that assembly window the first thing i do is CLOSE IT! Then i open the "Call Stack" window and start looking at what's in there to determine the point of failure in "my" code. You can double click the lines in the call stack window to go directly to that line of code. When your there you can look at variable values etc.

hope that helps
-pete

 

[LazyMe]

Yes, but that's only possible if you're running a debug build of the executable that crashed.

From this line in ADoozer's second post:
when a program crashes and takes you to the c++ debugger i want to know what/why and how the program crashed.
you might assume that he wants to debug not only his debug versioned executables.

I do agree very much though with you on the quick as possible closing of those disassembly windows....

Greetings,
Rick

 

[palbano]

Rick, your correct, as usual... i didn't read the later posts carefully.

.... (pete) LOL

-pete

 

[ADoozer]

ok, you guys are in this forums top experts, so if you dont use it, i wont! LOL

maybe one day ill figure out assembly!

thanks for your help! If somethings hard to do, its not worth doing - Homer Simpson

 

[jgartee]

If you want the reference manuals for assembly, Intel, for example, lets you download the IA-32 Intel Architecture Software Developer's Manual. You would want Volume 2: Instruction Set Reference.

Now, I heartly approve of anyone wanting to learn the assembly language for their platform...nothing but good can come of a deeper understanding. Be aware, however, that when you are attempting to debug "what happened" in a non-debug version of your code, you will be contending with optimizations, inline functions, and all kinds of other stuff that can make it difficult. The first thing you will need to do is generate link maps and listings showing source, assembly, and perhaps machine language to help you in determining where you are in the program and what is going on. In optimized code, this is not trivial!

I do, however, wish you the best of luck! It's bailed me out a few times.

 

[ADoozer]

jgartee: thank you for the info... im currently downloading all 3 volumes (cos im a glutton for punishment LOL).

i understand it wont solve all my problems but its a step on a long a daunting road!!

thank you again!! If somethings hard to do, its not worth doing - Homer Simpson