デバッグとリリースの両方のモードでコードをコンパイルすると成功します。デバッグモードは実行されて正常に動作しますが、リリースモードを実行すると、「アプリケーションを正しく起動できませんでした0x80000003」と表示されます。
このエラーとは何ですか。また、デバッグモードは正常に機能しますが、解放されないのはなぜですか。デバッグ用とリリース用のDLLは、同じディレクトリ名「bin」にあります。両方のモードの「lib」も同じディレクトリに配置されます。
私はそれを多くの方法で解決しようとしましたが、成功しませんでしたか？この問題を解決する方法を教えてください。ありがとう。
デバッグモードは正常に機能するがリリースされない理由
あるビルドが機能し、別のビルドが機能しない理由はたくさんあります。データ構造の形状とサイズは#ifdef、コンパイラが異なるコードを出力するため、またはコンパイラが出力するコードが異なるために異なる可能性が#ifdefあります。また、コンパイラが出力するコードのような構造またはコードのために、実行されるコードが異なる可能性があります。
バグのあるコードがある場合は、これが問題になる可能性があります。配列の長さ（または構造体のサイズなど）を誤って計算するバグがあるとします。ポインタ演算を実行し、そのポインタを使用してメモリにデータを書き込みます。間違った場所に書き込んでいるだけです。その間違いがあなたのプログラムを壊すかどうかは、あなたが上書きしたメモリに何があったかに依存するかもしれません。
運が良ければ、バグの直後に実行されるコードにとって上書きした内容が重要だったため、プログラムはほぼすぐにクラッシュします。少し運が良ければ、バグから遠く離れた場所でコーディングすることが重要だったため、プログラムのまったく別の部分でプログラムがクラッシュします。本当に運が悪ければ、数年後、まったく関係のない変更によってメモリ内で物事が移動するまで、プログラムはまったくクラッシュしません。そのため、突然上書きすることが重要になります。
時々 Heisenbugsと呼ばれるものの他の考えられる原因がたくさんあります
このエラーは何ですか
0x80000003のようなエラーを探す場所の1つは、使用しているSDK（Visual Studio 2010に付属しているファイルまたは後でインストールしたファイル）にあるWinError.hファイルです。WinError.hを見ると、それE_INVALIDARGがと定義されていることがわかります_HRESULT_TYPEDEF_(0x80000003L)。
何がそのエラーを返しているのか、なぜそれがそのエラーを返しているのか、あるいはあなたの0x80000003が実際にはE_INVALIDARGであるのかについて十分にわかっていないので、それは必ずしも役に立ちません-それは同じ値を持つ他のエラーである可能性があります、または、E_INVALIDARGなどを誤用しているコードの一部。
もう1つの可能性は、0x80000003がスローされるハードコードされたブレークポイント例外である可能性があります。おそらく、プログラムが例外をスローしてクラッシュすることだけが理にかなっている「これは決して起こらない」場所の1つに到達したためです。NtStatus.h（WinError.hを見つけたのと同じ場所）を見ると、次のようにSTATUS_BREAKPOINT定義されていることがわかります。((NTSTATUS)0x80000003L)
この問題を解決する方法
秘訣は、0x800000003の原因（およびコード内のどこで発生しているのか）を把握して、発生している理由を絞り込むことです。おそらくそれは例外ですが、なぜ結論に飛びつくのですか？
デバッグビルドを実行するのと同じように、デバッガー内でリリースビルドを実行できます。つまり、リリースターゲットを使用してコードをビルドし、F5キーまたは[デバッグ]|[デバッグ]を押します。デバッグを開始します。出力ウィンドウを見ると、エラーの解釈に役立つ情報が表示される場合があります。
デバッグ|を使用することもできます 例外メニューを使用して、値80000003の新しいWin32例外を追加し、処理されていないときに中断するのではなく、スローされたときに中断するように設定します。そうすれば、その例外がスローされたときにデバッガーで停止する必要があります（実際にスローされた場合）。
もちろん、デバッガー内でプログラムを実行するだけでも問題が発生しないように変更するのに十分である可能性があります。