2

デバッグ時にのみ ExecutionEngineException をスローする C# コードがあります。デバッグなしで Visual Studio から実行する ([デバッグなしで開始] ボタンを押す) と、このコードは正常に動作します。しかし、Visual Studio からデバッグすると、ExecutionEngineException がスローされます。

この問題により、デバッグしようとしているコードが問題のあるコードの後に​​実行されるため、アプリケーションをデバッグできません。

詳細は次のとおりです。

  • Visual Studio 2012 を使用しています
  • メイン アプリケーションは、C# コードを呼び出す C++/CLI アプリケーションです。
  • C# の問題のあるコード行に到達するまで、アプリケーションはしばらく実行されます。
  • 関連するコードは、Entity Framework コンテキストに対するクエリです。
  • Entity Framework 5 を使用しています
  • エンティティが格納されている DB は SQL Server LocalDB (VS2012 に付属するもの) です。

編集

さらに調査すると、実際の問題は System.Data.DataSet のデフォルト コンストラクターに起因するアクセス違反例外であることがわかりますnew DataSet()。

編集 2 この問題を示す小さなアプリケーションを作成しました。ソースコードはここにあります。

コンパイルして、プロジェクトを実行してみてくださいApplication。新しい. Adder.cs_ ExecutionEngineException_ DataSetデバッガーは、マネージド/ネイティブではなく、混在する必要があることに注意してください。

4

1 に答える 1

4

C++/CLI コードがガベージ コレクション ヒープを破損している可能性があります。アンマネージ コードが誤動作する非常に典型的な方法です。これは、オブジェクトを新規作成したときやガベージ コレクターが実行されたときなど、後になって初めて発見されます。したがって、クラッシュするコードは、破損の原因となったコードとはまったく関係がなく、バグがどこにあるのかはまったくわかりません。

これをデバッグする喜びはほとんどありません。通常、コードを徹底的にレビューし、アンマネージ コードで多数の単体テストを行い、それを見つけるために何日ものデバッグを行う必要があります。「デバッグ ビルドでのみクラッシュする」シナリオも非常に一般的です。これは、リリース ビルドにヒープの破損がないことを意味するものではありません。このように失敗するのは少し幸運です。リリース ビルドでヒープの破損が発生すると、デバッグが難しくなります。デバッグアロケーターに投資して、バグを実際にキャッチする必要があり<crtdbg.h>ます。一般に、この問題により、ガベージ コレクタがメモリを管理するための好ましい方法になりました。

お悔やみ申し上げます。幸運を祈ります。

于 2013-01-16T14:33:49.293 に答える