Can you repro you problem with a small, complete program that you can post here?
But the problem is how to eliminate the cause of the exception, rather than handle it, I'd hope?
You do know that debug builds often initialize memory with special patterns to make it easier to spot what memory is used for when debugging? For example, the Visual C++ debug CRT uses the following patterns:
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack) |
So even when you don't initialize memory, the compiler or heap does it for you in the debug build.
But in the release build, unininitialized memory is full of random values. Which means unitialized variables, etc cause more havoc in release builds than debug builds.
What you need to do is:
(a) make sure all variables are initialized to a meaningful value, usually zero (inc. null-ing of unused pointers.)
(b) make sure no buffers overrun
(c) make sure you protect all pointers against dereferencing when null
Andy
Magic number (programming)
http://en.wikipedia.org/wiki/Magic_number_(programming)