Whenever I encountered the access conflict means that your program tries to access the memory that cannot be obtained for your program. Please note that I have used "No Longer". In many cases, access conflicts are because they are trying to reference the pointer of the already released object or the pointer to the object that has not been created.
Fortunately, in the Win32 memory structure, each process has a separate address space, so we don't have to worry about overwriting other programs (this is often encountered in Win1). This also illustrates that now (actual "can utilize the information in the Error dialog.
When we encounter access to the conflict dialog, there will be an address (for example: Access Violation at address: ?????). Make a note of this address, return to the application, open the CPU window, right click in the CPU window to select Goto Address. When the dialog box appears, enter the place that has just visited the conflict, you have arrived in an instruction that caused access to conflicts.
Although all of the CPU window written in assembly language, this is not important to you. If you take the scroll bar up, you can see the function you currently. Now, you know which function causing access to conflicts. Once you know the function that causes access to conflicts, you can set up breakpoints in this function.
Unfortunately, not all things are so easy, the pointer error is sometimes very difficult to find, the total rule is when the object points to the pointer is released, and these pointers are set to null, you may still want to hate it Check if it is NULL before using the pointer, if you can output some of the tired information to help you identify which pointer has caused access errors when the program is running.
As the last means, you need to set up a data break point at that pointer to check when it is NULL.
