24

重複の可能性：
競合状態/デッドロックを見つけるためのC＃/。NET分析ツール

デッドロックしてハングしていると思われるアプリケーションをデバッグしています。ただし、これは数日ごとにのみ発生し、コンピューターでは発生しないため、デバッガーを接続できません。実行中のアプリケーションにクエリを実行し、どのメソッド/ロック/デッドロックが発生しているかを調べるために使用できるユーティリティまたはメソッドはありますか？

更新：通常、アプリケーションは顧客の場所で実行されており、私はマシンにアクセスできません。また、大量のソフトウェアをインストールするように依頼することに完全に満足しているわけではありません。

4

7 に答える 7

24

WinDbgを使用して、アプリケーションのスレッドを検査できます。これがあなたができることの簡単な計画です。

  • アプリケーションがハングした場合は、WinDbgファイルをマシンにコピーします。
  • WinDbgをプロセスにアタッチするか、ADPlusを使用してプロセスのハングダンプを取得します。ADPlusを選択した場合は、WinDbgにダンプをロードします。
  • WinDbgからsos.dllをロードして、マネージコードを検査できるようにします。
  • !threadsコマンドはアプリケーション内のすべてのスレッドを表示し、コマンド!clrstackはそれらが何をしているかを表示します。~e!clrstackすべてのスレッドの呼び出しスタックをダンプするために使用します。ロックを示しているので、Waitメソッドの呼び出しを探します。
  • この!syncblkコマンドは、どのスレッドがさまざまなロックを保持しているかについての情報を提供します。
  • 特定のスレッドが取得しようとしているロックを見つけるには、スレッドに切り替えてスタックオブジェクトを調べます（!dso）。ここから、スレッドが取得しようとしているロックを見つけることができるはずです。

明確化：WinDbgは定期的なインストールを必要としません。ファイルをコピーするだけです。また、ハングダンプを取得する場合は、必要に応じて別のマシンでデバッグを続行できます。

追加：Sosexには、!dlk多くの状況でデッドロックを自動的に識別するコマンドがあります。常に機能するわけではありませんが、機能する場合はすべての機能を実行するため、これを最初に選択する必要があります。

于 2009-02-03T19:11:05.543 に答える
9

通常のlock＆Monitor.Enterアプローチを使用して一部のデータをロックする代わりに、「TimedLock」構造を使用することもできます。このTimedLockは、ロックをタイムリーに取得できなかった場合に例外をスローします。また、解放しなかったロックがある場合は警告を表示することもできます。

IanGriffithsによるこの記事が役立つかもしれません。

于 2009-02-03T19:25:11.507 に答える
7

並行プログラミングのタイムアウトは恐ろしい考えです。これは非決定論につながり、したがって再現できない動作につながります。CHESSなどのデッドロック検出ツールを使用してみてください。さらに良いことに、ロックフリー アルゴリズムで使用されるロックの数を最小限に抑えるか、ロックを完全に回避してプログラムをシングル スレッドのコンパートメントに分割し、キューを使用してコンパートメント間でデータを渡します (メッセージ パッシング/アクターの同時実行としてよく知られています)。

于 2010-03-08T19:10:30.167 に答える
1

http://blogs.technet.com/askperf/archive/2007/06/15/capturing-application-crash-dumps.aspxの終わりには、少なくともVistaでは、タスクを使用して実行中のプロセスのクラッシュダンプを取得できると書かれています。マネジャー。

于 2009-02-03T18:53:38.967 に答える
1

あなたは実際にそこに非常に興味深い問題を抱えています。あなたができることがいくつかあります：

適切なロガーを使用する: マルチスレッド エラーを再現する方法の 1 つは、実行されたアクションとそれらを実行したスレッドを出力するロガーを使用することです。ロガーを追加できれば、これはかなり簡単な解決策です。

FSP を使用する: FSP を使用してマルチスレッド システムを定義します。このようにして、エラーを見つけるために実行できるプロセスの有限状態マシンを作成できます。このソリューションは、より数学的なソリューションです。

私があなたに与える2つの解決策/手順は、英国のユニバーシティとアメリカのユニバーシティの間のマルチスレッド開発へのアプローチの主な違いです。英国の教授は、プログラムを作成する前に、FSP を使用してシステムにエラーがないことを証明しようとします。アメリカ人は、正しく動作することを証明するためにテストすることを好みますが、それは好みの問題です。

この本を読むことを強くお勧めします: Jeff Magee and Jeff Kramer: Concurrency: State Models and Java Programs, Wiley, 1999

于 2009-02-03T19:08:35.423 に答える
0

これは非常に興味深い問題であり、数日おきにしか発生しないため、苦痛です。CodeProject でこの記事を見つけました。それはあなたにとっての始まりかもしれません。

古い学校のアプローチは、大量のメッセージをログに記録し、ログファイルを使用してそれがいつ発生したかを検出しようとすることです。:)

于 2009-02-03T19:01:39.650 に答える
0

ここでの回答に加えて、一般的にスレッド プログラミングで役立つもう 1 つのことは、開発ボックスがマルチプロセッサ マシンであることを確認することです。特に、デッドロックは (通常) はるかに確実に再現されます。

于 2009-02-03T21:42:29.983 に答える