Common Problems When Creating a Release Build
During development, you will usually build and test with a debug build of your project. If you then build your application for a release build, you may get an access violation.
The list below shows the primary differences between a debug and a release (nondebug) build. There are other differences, but following are the primary differences that would cause an application to fail in a release build when it works in a debug build.
See the /GZ (Catch Release-Build Errors in Debug Build) compiler option for information on how to catch release build errors in debug builds.
Heap layout will be the cause of about ninety percent of the apparent problems when an application works in debug, but not release.
When you build your project for debug, you are using the debug memory allocator. This means that all memory allocations have guard bytes placed around them. These guard bytes detect a memory overwrite. Because heap layout is different between release and debug versions, a memory overwrite might not create any problems in a debug build, but may have catastrophic effects in a release build.
Many of the MFC macros and much of the MFC implementation changes when you build for release. In particular, the ASSERT macro evaluates to nothing in a release build, so none of the code found in ASSERTs will be executed. For more information, see Examine ASSERT Statements.
Some functions are inlined for increased speed in the release build. Optimizations are generally turned on in a release build. A different memory allocator is also being used.
The lack of debugging information removes the padding from your application. In a release build, stray pointers have a greater chance of pointing to uninitialized memory instead of pointing to debug information.
Depending on the nature of certain segments of code, the optimizing compiler might generate unexpected code. This is the least likely cause of release build problems, but it does arise on occasion. For a solution, see Optimizing Your Code.