1

WPF と Entity Framework の上で実行される大規模なビジネス アプリケーションがあります。問題は、過去 2 週間にわたって問題が発生しており、その原因を特定できないことです。

例外は DispatcherUnhandledException によってトラップされており、例外から (電子メール経由で) 取得している情報は次のとおりです。

mscorlib: Value cannot be null.
   at System.Threading.Monitor.ReliableEnter(Object obj, Boolean& lockTaken)
   at System.Threading.Monitor.Enter(Object obj, Boolean& lockTaken)
   at System.Data.EntityClient.EntityConnection.ChangeConnectionString(String newConnectionString)
   at System.Data.EntityClient.EntityConnection.Dispose(Boolean disposing)
   at System.ComponentModel.Component.Finalize()

例外は、1 日に 4 ～ 5 回「ランダムに」スローされ、20 人以上のユーザーのうちの 1 人からのみスローされます。問題がわかりません!. スタック トレースからは多くの情報が得られず、問題を再現できません。

これはスレッドで発生していると思いますが、多くの BackgroundWorkers と非同期のものがあるため、例外の原因となっているスレッドを特定できません!

では、例外に関する詳細情報を取得するにはどうすればよいですか??

編集：

InnerExceptions はありません。

また、例外は数分間隔でスローされ、次に数時間間隔でスローされます。たとえば、11:41、11:46、11:51 で、18:03、18:07、18:11 まで正常に実行され、例外はスローされません。 . この分間隔が発生する瞬間もランダムであり、サーバーやネットワークの負荷とは関係ありません。

4

3 に答える 3

3

これはおそらくガベージ コレクション スレッドの一部として発生しているようです。スタックの一番下にある Finalize 呼び出しがヒントであり、おそらく EntityConnection.Dispose(false); を呼び出しています。

問題の性質は非決定論的です。あなたの環境で何かが変わって、今それが起こっているかもしれません。

ファイナライザーでは、他のマネージド オブジェクトにアクセスするのは本当に安全ではありません。ChangeConnectionString はおそらくマネージド オブジェクトをロックとして使用しようとしているように見えますが、GC スレッドにある場合、オブジェクトは既にクリーンアップされている場合があります。これを行っているのは、おそらく EntityConnection のバグです。

ファイナライザーを実行させるのではなく、コンポーネントで Dispose を呼び出すことで、これを回避できるはずです (ブロックを使用してそれらを囲むことは、これを確実にするための優れた方法です)。ただし、コールスタックを使用すると、問題の原因となっているコンポーネントの性質について多くを語ることは困難です。

ローカルの再現を取得したい場合は、Finalize をオーバーライドするクラス (~MyComponent() など) で EntityConnections にアクセスしている Component オブジェクトをサブクラス化し、それに例外をスローしてみてください。そうすれば、GC がこれらのオブジェクトをクリーンアップした場合にクラッシュが発生します。

于 2012-06-08T22:34:34.490 に答える