Debugger - Knowing your error messages 1

[pghsteelers]

In learning C++ I am at a point of getting to know the debugger in VC 6 (I am switching to 2005 at the end of this project) - anyhow, I posted the below code, that if you compile (0 errors) but try to run, it crashes, giving you an opportunity to run the debugger.

Upon entering you'll receive and error:
"Unhandled exception in Name.exe 0xC0000005: Access Violation."

Now, I know that the memory location is specific to my PC. THe debugger takes you to the violation which in debugger is the line reading:

main_loop:
004096A1 mov dword ptr [edi],edx

My training tool I am using, is telling me that the reason is because of "the exception referring to a memory location way outside the realm of the program, so a rogue pointer in our program is the immediate suspect".

My problem and question is that it doesn't tell me "how" it found the listed lines above to indicated that? So, can anyone help me break this down or give some directing information to help me see how:
main_loop:
004096A1 mov dword ptr [edi],edx

is telling me that I have a reference to a memory location way out of the scope of the program?

Thanks

 

[pghsteelers]

Ah, sorry everyone, realized I forgot to take out of the original post that I was putting up my code. I don't see there really is any reason to since this is about understanding what the debugger is reading to you. Plus it is a compulation of multiple files. So unless someone really needs too, I'll leave the code out.

 

[cpjust]

If you can consistently reproduce this error, try to guess approximately where in the code you are when you do whatever it is that causes the error (i.e. clicking a button...), then put a breakpoint in that code and re-run in debug mode.
You should be able to view the Call Stack and see which functions where called... If you don't hit the breakpoint, move it further up in call stack and try again.
Once it hits the breakpoint, step through the code 1 line at a time until you get the error. Then you'll know exactly where your problem is and you can try to figure out if you're doing something bad with pointers...

 

[uolj]

You don't need to guess where the code is and put a breakpoint. The access violation will cause the debugger to stop at the point where it occurred. Just close the Disassembly window if that doesn't help you and then look at the Call Stack. Find a function that you wrote and double click it to see what code was executing when the access violation occurred. Remember that the triangle marker is sometimes on the next line of code past the current one, so don't get confused.

Once you see where the code is that causes the access violation, then you can look at all the variables to make sure they have been initialized properly or whatever other problems might exist. You can also set the breakpoint then to do better debugging the next time so you can see what the data was before the crash.

 

[ADoozer]

you also have the option of producing a map file.. which is particularly helpful when working with release builds.

(projects->settings: Link tab: generate mapfile)

this way, when you see the error message

"the instruction at 0x???????? referenced memory at 0x????????, etc."

you can use your map file to find the offending function.

see

http://www.codeproject.com/debug/mapfile.asp

for a better description/tutorial

If somethings hard to do, its not worth doing - Homer Simpson

 

[cpjust]

Cool, I was always wondering what a mapfile was, but never really cared enough to look it up. ;-)

 

[ADoozer]

i'd used map files on embedded processors in the past..

but only recently did i learn about the option in vc++.(my users were complaining that "the instruction at 0x???????? referenced memory at 0x????????, etc.".. but had no event logs?!?)

glad it helped

If somethings hard to do, its not worth doing - Homer Simpson