다음을 통해 공유


Common Problems When Creating a Release Build

 

The latest version of this topic can be found at 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.

  • Heap Layout

  • Compilation

  • Pointer Support

  • Optimizations

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

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.

For more information, see Check for Memory Overwrite and Use the Debug Build To Check for Memory Overwrite.

Compilation

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.

Pointer Support

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.

Optimizations

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.

See Also

Release Builds
Fixing Release Build Problems