リリース ビルド作成時によくある問題

  • [アーティクル]

開発時には、通常、プロジェクトのデバッグ ビルドを使用してビルドとテストを行います。 その後、リリース ビルド用にアプリケーションをビルドすると、アクセス違反が発生する場合があります。

次の一覧は、デバッグとリリース (非デバッグ) ビルドの主な相違点を示しています。 他にも違いがありますが、アプリケーションがデバッグ ビルドで動作するのにリリース ビルドで失敗する原因となるような主な相違点は次のとおりです。

デバッグ ビルドでリリース ビルド エラーをキャッチする方法の詳細については、/GZ (デバッグ ビルドでのリリース ビルド エラーのキャッチ) コンパイラ オプションを確認してください。

ヒープ レイアウト

ヒープ レイアウトは、アプリケーションがデバッグでは動作するがリリースでは動作しない場合の明らかな問題の約 90% で、その原因になります。

デバッグ用にプロジェクトをビルドするときは、デバッグ メモリ アロケーターを使用しています。 これは、すべてのメモリ割り当ての周囲にガードバイトが配置されていることを意味します。 これらのガードバイトにより、メモリの上書きが検出されます。 ヒープ レイアウトはリリースとデバッグのバージョンで異なるため、メモリの上書きによってデバッグ ビルドでは問題が発生しないかもしれませんが、リリース ビルドには致命的な影響が生じる可能性があります。

詳細については、「メモリ上書きを確認する」と、デバッグ ビルドを使用したメモリ上書きのチェックに関する記事を参照してください。

コンパイル

MFC マクロの多くと MFC 実装の大部分は、リリース用にビルドするときに変更されます。 特に、ASSERT マクロはリリース ビルドでは何も評価されないので、ASSERT で見つかったコードは実行されません。 詳細については、ASSERT ステートメントの調査に関する記事を参照してください。

一部の関数は、リリース ビルドの高速化のためにインライン化されます。 最適化は、一般にリリース ビルドで有効になっています。 別のメモリ アロケーターも使用されています。

ポインターのサポート

デバッグ情報がないと、アプリケーションから埋め込みが削除されます。 リリース ビルドでは、無効なポインターがデバッグ情報を指すのではなく、初期化されていないメモリを指す可能性がより高くなります。

最適化

コードの特定のセグメントの性質によっては、最適化コンパイラによって予期しないコードが生成されることがあります。 これは、リリース ビルドの問題の原因として最も可能性が低いですが、時々発生します。 解決策については、「コードの最適化」を参照してください。

関連項目

リリース ビルド
リリース ビルドの問題の解決