環境: いくつかの Visual C++ プロジェクトを参照する .NET 4.0 ソリューションがあります。ビジュアル スタジオ 2010。
ソリューションをビルドし、結果の .exe を bin ディレクトリから直接実行すると、バグを再現できます。しかし、Visual Studio で「再生」ボタンを押して実行すると (またはプロセスを実行してそれにアタッチすると)、コードをステップ実行でき、すべてが正常に機能します。
参考までに、私が得ている問題は、C++ コードで最も確実に発生しているアクセス違反です。
しかし、より広く言えば、デバッガーをプロセスに接続すると問題が「修正」されるという他の理由があるのではないかと考えています。
MS VS はサンドボックスのように機能します。そのサンドボックスでアプリを起動すると、プログラムはソリューション プロパティ (または VS 設定のみ) からすべての設定を継承します。環境に提供されているすべてのオプションが正しいことを確認してください。それでも問題が解決しない場合は、それらの設定を再確認し、アクセス違反を防ぐことができるものを考え、チェックを外してチェックしてください。
外部 DLL を使用している場合、システムからのものと IDE からのものはバージョンが異なる場合があります。もちろん、どちらの場合でも機能する可能性がありますが、これらの dll 内で何が変更されているかによって、アクセス違反や範囲外のサブクライエントなどの問題が発生する可能性もあります。
Windows アプリの場合は、有効化/無効化を試してくださいLargeAddressAware。
別の OS を搭載した別のマシン用にコンパイルしている場合、ネイティブ OS によるメモリ処理の変更が原因で、非常に頻繁に発生する可能性があります。メモリは、マルチブロック、極端に断片化、またはマルチデバイス化される場合があるため、対象の OS/マシン用に特別に作成されたコンパイルでのみプログラムをコンパイルしてください
デバッグ モードでは、 assert() など、デバッグに直接関連するものを使用します。リリースではなくデバッグで問題が発生した場合、それはマシンでは許容されますが、挿入のデバッグでは許容されないことを意味します。その場合、あなたはうんざりしていますが、他のデバッガーで問題がないように見える場合は、問題が解決され、デバッガーの問題、特にデバッグオプションなしのリリースが機能している場合.
最も面倒な方法 - アクセス違反のアドレスを特定し、参照しているメモリ ウィンドウ内を確認してください。
それ以外の場合は、スニペットを提供して、より多くのことを伝えることができます!
@Mattこれはヒープの問題ではありません。発生する可能性がありますが、非常にまれです。
@Huytardリンクされたdllのプログラムがなければ、それは起こらないはずです。
正しい短い答え。Windows Update を実行します。
正しい長い答え。
ビルド マシンがしばらく更新されておらず、古いバージョンの Visual C++ コンパイラを使用していたことが判明しました。.NET 4 のコンパイラにバグがあり、静的コンストラクターが他のタイプのコンストラクターの前に最初に呼び出されませんでした (リリース モードのみ)。
しかし、ここがキッカーです！Visual Studio デバッガーでプロセスを実行する場合、またはリモート プロセスにアタッチする場合。静的コンストラクターは、想定どおりに最初に呼び出されます。（したがって、デバッグ環境では問題を完全に再現できません-リリースモードでも）コードパスを特定するためにメッセージボックスをあちこちに配置して問題を発見しました。