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

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.

Thanks Daishim.

That is actually what is happening. However, my problem is finding a way to understand that statement:

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

Maybe its a matter of using the Call Stack (which is available in 6) to understand the statement, or maybe it is a matter of having to actually memorize statements such as above to know when you come across.

The training tool I am using made it sound like there was a "break down" procedure that would allow you to disect it and have an idea of what might be going on that helps propel you to the next step in using debugger to find the problem.

running the program, then upon the program crashing and receiving the windows program error message, I select debugger which launches a separate debugging session withing VC - hope that answers the question.

If your debugger is not providing the source code (the code that you wrote, not the generated assembly), then you are attempting to debug without debug information (i.e., in "Release" mode). Debug in Debug mode or enable the generation of debug information for your Release target -- you'll need to look up how, I don't remember how to do it in VC6.

Looking at the disassembly isn't going to be of much help unless you have at least of basic knowledge of assembly and you can figure out what the context is.

"mov dword ptr [edi],edx" is moving some number from the EDX register to what is pointed to by the EDI register; EDI likely contains an address that is invalid. Often, as others have said, this is cause by accessing an array out-of-bounds. The address of the instruction (0x004096A1) suggests (but does not prove) that the operation is relatively early in the exection of your program (probably during initialization, as your observed tests indicate it crashes right as the program starts).

The debugger itself "found" the code that causes the crash because the x86 CPU has a register, EIP, called the "instruction pointer" that keeps track of the address of the executing instruction. When an instruction causes something naughty to occur, the code at and around the address indicated by EIP can be disassembled, yeilding the assembly the debugger is presenting you with. If your project has debug information with it, the debugger can associate that disassembly with your actual source code, which helps you track the errors a lot easier.

You yourself can "find out" that the given assembly means you are trying to access memory you aren't allowed to if you have a basic understanding of assembly: "mov" in an instruction that moves information around from a source to a destination. "Access violation" means what it sounds like; the line that causes an access violation was a "mov" line, so it follows that some part of that move is illegal (either the source location or the destination location). Generally, when you build your project with debug information, you don't need to deal with assembly directly except in the case of some very strange bugs.

Post the code for your entry point (main or WinMain) and the first few functions you call from that point, especially if they load data or otherwise perform array or memory accesses.