Hi, I seem to have a problem that I suspect is a written memory (write memory). Some part of my application might write over other's part memory. Maybe over some pointers, leading to a game crash. I need some advices on how to solve it. The strangest thing is that it seems to happen only on someone's computer. Some other users tested it and it never crashed for them. Defenetly not on mine computer, making it very difficult to catch. Only on release version (the debug compiled version does not seem to have the problem or at least it doesn't show it). Only after a wile, not always in the same place. I use VisualStudio6 and DirectX8. I don't have access to the computer that crashes and the guy doesn't have programming knowledge. The only thing to do is to send him builds trying to find where the bug is. I have a guard-unguard system on each function so it reports where the crash occured. But mostly, it is right in the guard debuging callstack list - probably some part of the program overwrite the pointer of this buffer that keeps track of the current functions callstack. The log usually reports something like: Loading map SUCCESSFUL! ... EXCEPTION_ACCESS_VIOLATION at address 0x41284a (write to 0x680) EXCEPTION_ACCESS_VIOLATION at address 0x41284a (write to 0x680) cRender::SetTex < cRndState::Apply < cRndStreamDynamicHW::Draw < cRndStreamDynamicHW::Flush < cIPaint::Flush < cSprite::Draw < EXCEPTION_ACCESS_VIOLATION at address 0x41284a (write to 0x668) EXCEPTION_ACCESS_VIOLATION at address 0x41284a (write to 0x668) EXCEPTION_ACCESS_VIOLATION at address 0x41284a (write to 0x668) EXCEPTION_ACCESS_VIOLATION at address 0x41284a (write to 0x668) The 0x41284a address seems to be in the guard function and my debug callstack pointer is probably set to 0x680 instead of a valid application address. It also seems to be related to the video module (DX8) - the drawing of batched primitives. I changed it to a VertexBuffer with DrawPrimitive instead of system memory and DrawPrimitiveUp. It was flickering for some users, failing to display all the primitives in the batch buffer, like it was damaged? Possible write over? It worked fine on my computer and others too. I don't know if it was related to the write memory or weird driver problem. I might try to create a debug class for arrays, to make sure they are not write out of their boundries, but somehow I doubt it's the cause - it would happen to everybody. Now, if anyone can help me with other sugestions on how to catch a writted memory bug, please do so. Thanks!

The suspected pointer is allocated at the very beginning of the main function and it gets reallocated from time to time if the call stack exceeds an initial size.
The game would not work at all if the pointer would be null at some point.
So until it gets messed up, it has to be just fine.

I was thinking to create a thread and watch it's value to catch the moment it changes, like a watchpoint on memory in the VisualStudio debuger. Anyone has tried something like that?

x86 processors have 4 debug registers which can be configured to break into the debugger when the address held in them is written to or read from.

Google for 'hardware breakpoint'.

Most links say that it's Intel specific, but I've been able to use them on AMD processors as well.

Thanks Nitage,
The hardware breakpoint class seems to be exactly what I need.
Do you know how to continue execution after this EXCEPTION_SINGLE_STEP exception
is rised by the hardware breakpoint (like the continue that the debuger does) ?
I would like to trace info on each such exception, but now it just exits the application on the first occurance.
I have my own exception handler set with _set_se_translator but I dont know what should I write in it to stop the exceptions cascade and continue the execution.
Thanks!

You'll have to run it through the debugger. Try compiling with optimizations on, but with debug information still included.

To continue execution, you have to do all processing in the exception filter, not the __except block...

Here's a good start: http://msdn2.microsoft.com/en-us/library/s58ftw19.aspx

Here's some really advanced information on exception handling, which I think you won't need: http://www.microsoft.com/msj/0197/Exception/Exception.aspx