アプリケーションでExecutionEngineException. そうなったらアプリケーションがクラッシュするはずだと思っていたのですが、クラッシュしません。また、イベント ビューアがアプリケーションが終了したと主張しても、アプリケーションは実行を続けます。問題のあるスレッドが静かに殺されているように見えるだけです。
問題は、例外が発生したときに条件を再現できないことです。疑わしいコードは、例外が発生する前に何千回も実行されます。ログには何もありません。要するに、私たちは困惑しています。
この例外が発生したときにアプリケーションがどのように動作するかを知るために、この例外を自由に生成できるようにしたいと考えています。もちろん、フレームワーク自体によってスローされる必要があり、発行throw new ExecutionEngineExceptionはカウントされません。
だから、私の質問は - どうすれば確実にそれを引き起こすことができますか? コードサンプルを提供してください。
現在 .NET 4 を使用しており、まもなく .NET 4.5 に移行します
MSDN ドキュメントから:
場合によっては、.NET Framework を対象とするアプリケーションが、実行中のアプリケーションまたはシステムの負荷が高い場合、ガベージ コレクション中に ExecutionEngineException 例外をスローすることがあります。この場合、この問題を回避するには、アプリケーションの構成ファイルを変更して同時ガベージ コレクションを無効にします。詳細については、「 方法: 同時ガベージ コレクションを無効にする」を参照してください。
MSDN のドキュメントで提案されている回避策がうまくいかない場合は、ソフトウェアに関する知識に基づいてテストする必要があります。
ここで、実際のアプリケーションの負荷、マルチスレッドの動作、およびメモリ消費をシミュレートするテスト アプリケーションを作成することは 1 つの方法です。おそらく、実際のソフトウェアをテスト ソフトウェアとして使用することをお勧めします (おそらく、追加のデバッグ ロギング + テスト コードを使用して補強します)。 . つまり、残念ながらここにコードサンプルはありません:(
負荷テストを意味のあるものにするには、本番システムと同じではないにしても、ハードウェア/ソフトウェア構成が非常に似ているテスト システムでこれらのテストを実行する必要もあります。そうして初めて、ExecutionEngineException が GC によって引き起こされたのか、それとも破損したランタイムによって引き起こされたのかを知ることができます。
問題を再現しない限り、ExecutionEngineException を簡単に発生させることはできません (実稼働環境でそれを行う必要がある場合でも)。Microsoft には、このような例外が発生したときに完全なメモリ ダンプをキャプチャするのに役立つ DebugDiag などのユーティリティがあります。
また、ダンプ分析により、原因を簡単に突き止めることができます。この例外が発生すると CLR がクラッシュし、ログがそれほど深くなることはないため、ログでわかるとは思わないでください。