ハング後にプロセスにアタッチし、ライブ デバッグを実行します。
ハング状態になった後、デバッガー (Visual Studio デバッガーまたは WinDBG) を使用して「プロセスにアタッチ」するだけで、プロセスを「中断」できます。
次に、すべてのスレッドのスタックを調べて、それらが何を行っているかを確認します...特定のスレッドが行っていることでデッドロックが発生していることがわかる場合があります。
SOSEX プラグインで WinDBG を使用する場合は、!dlk コマンドを使用することもできます。これにより、デッドロックが自動的に検出される場合があります。
ガベージ コレクター、ファイナライズ キュー (たとえば、ファイナライザー スレッドをブロックしている可能性があります) などを確認するなど、何が起こっているのかを確認できるデバッガー コマンドは他にもたくさんあります。
プロセスの優先度やプロセッサ アフィニティを変更する
システム全体がハングするとあなたが言ったことを知ったので、これはトリッキー/不可能かもしれません...あなたが試すことができる1つのことは、プロセスの優先度を下げたり、ハングする前にプロセッサアフィニティを設定したりすることです状態...これにより、同じマシンにデバッガーをロードするより良い機会が得られるはずです。理論的には、プロセスを停止するとCPUが独占されるのを防ぐためです。
タスク マネージャーに移動し、プロセスを右クリックしてSet Priority LowまたはSet Affinityを実行します。
優先度を変更すると、実際にはアプリケーションがハングしたり動作が変わったりしないという副作用がある場合があります....しかし、少なくともこれが発生した場合、問題の手がかりが得られます.
それでもハングする場合 (ただしそれほどではない)、デバッガーをほぼ実行できる場合は、プロセスにアタッチして中断することができます。
WinDBG によるカーネル デバッグ
上記がうまくいかない場合は、クラッシュしているマシンに WinDBG をインストールし、カーネル デバッグ モードで起動するように Windows をセットアップしてから、別のマシン (USB、Firewire などで接続) から WinDBG クライアントを使用して通信します。ハングしたマシンのバックエンド デバッグ エンジンを使用すると、システムに侵入してマシンの状態を分析できます。
クラッシュ ダンプ (.dmp) の作成と事後分析
もう 1 つの手法は、クラッシュ ダンプを介してプロセスの状態をキャプチャすることです (タスク マネージャーでプロセス名を右クリックして [ダンプの作成] をクリックするか、他のツールを使用して作成できます)。次に、.dmp ファイルを Visual Studio (File Open を使用) または WinDBG (Open Crash Dump を使用) に読み込むことができます。次に、そのプロセスの特定の状態を確認できます。
これは、ADPlus などのさまざまなツールを使用して自動化できるため、アプリケーションが応答しなくなったときにクラッシュ ダンプが自動的に実行されます。運が良ければ、システムがハングしたシステムにある場合でも、自動化された方法で機能する可能性があります。 ....そうではないかもしれません。
より多くの情報/状態にアクセスできるため、可能であればクラッシュ ダンプよりもライブ デバッグを実行することをお勧めします。
マネージ デバッグ アシスタント
CLR ランタイムを使用して .NET アプリケーションを実行し、追加のチェックを実行して、正しい方法で処理を行っていることを確認することができます。これらのチェックは、マネージド デバッグ アシスタントと呼ばれます。MDA が問題を検出すると、プログラムで例外が発生します。
それらは、「myapplication.mda.config」でいくつかの構成スイッチを使用するか、[デバッグ] メニューの [例外] ダイアログを使用してオンにすることができます (ツリーにはそれら専用のブランチがあります)。それらのいくつかは非常に攻撃的であり、赤いニシンにつながる可能性があるため、すべてをオンにしないでください...各MDAを実際に読んで、チェックが何をしているのかを理解する必要があります。