Whenever you get an AV in windows it means that your program tried to access memory that is no longer available to your program. Notice that I said "no longer" available. Many times when you get an AV, it is because you either tried to use a pointer whos object had already been deleted, or a pointer whos object hasn't been created yet.
Luckily for us, the win32 memory architecture uses a seperate address space for every process, so we don't have to worry about overwriting the memory of other programs (this was a frequent problem in win16). This also means that we can actually use the information in the error dialog.
When we get an AV dialog, there will be an address (ie AV at address :?????). Write that address down, rerun the application and open the CPU window. Right click on it and choose go to address. When the dialog comes up, enter the address that the AV just occured at. Now you will be at the instruction that caused the AV.
Since everything in the CPU window is written in Assembly it probably won't meant that much to you; however, if you scroll up a bit you should see which function you are currently in. Now you know what function is causing the AV. Once you know which function caused the AV you can start to set break points within the function.
Unfortunately not everything is as easy as that. Pointer problems can be very hard to debug. As a general rule, all pointers should be set to NULL after the object that they point to is deleted. You also might want to check to see if the pointer is NULL before you use it in the offending function, and if it is, the you can output some debug information to help you pinpoint at what point during the program execution the AV is occuring.
As a last resort you should alse be able to set a data break point on the pointer and check to see when it is set to NULL.