WPF：WinDbgを使用してWin 7 64で時折高いCPU使用率を伴うアプリケーションのトラブルシューティング

Question

Windows 7 64ビットのみで動作するときにCPU時間の96-99％を時折利用する.NET 3.5 WPFアプリケーションがあります。もちろん、これが起こると、アプリケーション自体も正しく動作しなくなります。これは、Windows 7の64ビット版でのみ発生する別の問題です。

アプリケーションは現在この状態にあり、WinDbgまたは他のデバッグツールを使用してできるだけ多くの情報を取得したいと考えています。これをリアルタイムで手助けできるオンラインの人は誰ですか？

まず第一に、これは私がプロセスエクスプローラから得ることができるものである。添付画像はを示したように、私は開始アドレスを持つそれらの束と40のスレッド数を持っている：

mscorwrks.dll!GetMetaDataInternalInterfaceFromPublic+0x934c. 

程度がありますこれを開始アドレスとして現在表示している24のスレッド。しかし私はこれを私のコードの中の何かに関連付けることはできません。

私は現在、すべてのスレッドを中断しているWinDbgを使用してプロセスに接続しています。それから私は私を与える

!runaway 3 

をした：私は、プロセスを継続するgを発行すると

0:039> !runaway 3 
User Mode Time 
    Thread  Time 
    33:29bc  0 days 0:27:48.711 
    21:2880  0 days 0:26:22.021 
    34:18cc  0 days 0:24:38.873 
    18:2a04  0 days 0:23:56.753 
    23:2618  0 days 0:18:58.947 
    24:27e8  0 days 0:17:36.859 
    30:21d4  0 days 0:17:05.800 
    32:248c  0 days 0:17:04.286 
    35:2b00  0 days 0:16:20.809 
    22:2680  0 days 0:15:37.597 
    5:2a28  0 days 0:15:10.234 
    31:ee4  0 days 0:15:07.348 
    20:20f0  0 days 0:14:32.903 
    17:29ac  0 days 0:14:02.202 
    10:20dc  0 days 0:00:51.152 
    11:2ad0  0 days 0:00:11.247 
    37:2c14  0 days 0:00:06.489 
    38:2f3c  0 days 0:00:01.466 
    25:1db8  0 days 0:00:00.920 
    1:2a84  0 days 0:00:00.452 
    0:1494  0 days 0:00:00.093 
    2:1ba0  0 days 0:00:00.078 
    29:53c  0 days 0:00:00.015 
    27:278c  0 days 0:00:00.015 
    7:8d4  0 days 0:00:00.015 
    4:2620  0 days 0:00:00.015 
    39:215c  0 days 0:00:00.000 
    36:2088  0 days 0:00:00.000 
    28:26e0  0 days 0:00:00.000 
    26:2960  0 days 0:00:00.000 
    19:2a10  0 days 0:00:00.000 
    16:2a70  0 days 0:00:00.000 
    15:24a8  0 days 0:00:00.000 
    14:2208  0 days 0:00:00.000 
    13:2bcc  0 days 0:00:00.000 
    12:2a6c  0 days 0:00:00.000 
    9:1a38  0 days 0:00:00.000 
    8:2a98  0 days 0:00:00.000 
    6:1200  0 days 0:00:00.000 
    3:2af8  0 days 0:00:00.000 
Kernel Mode Time 
    Thread  Time 
    11:2ad0  0 days 0:00:03.650 
    10:20dc  0 days 0:00:02.230 
    33:29bc  0 days 0:00:00.686 
    34:18cc  0 days 0:00:00.577 
    21:2880  0 days 0:00:00.327 
    18:2a04  0 days 0:00:00.327 
    24:27e8  0 days 0:00:00.280 
    35:2b00  0 days 0:00:00.249 
    1:2a84  0 days 0:00:00.218 
    30:21d4  0 days 0:00:00.156 
    22:2680  0 days 0:00:00.140 
    5:2a28  0 days 0:00:00.140 
    37:2c14  0 days 0:00:00.124 
    23:2618  0 days 0:00:00.109 
    2:1ba0  0 days 0:00:00.109 
    25:1db8  0 days 0:00:00.093 
    20:20f0  0 days 0:00:00.093 
    17:29ac  0 days 0:00:00.093 
    0:1494  0 days 0:00:00.078 
    7:8d4  0 days 0:00:00.062 
    32:248c  0 days 0:00:00.046 
    3:2af8  0 days 0:00:00.046 
    31:ee4  0 days 0:00:00.031 
    8:2a98  0 days 0:00:00.031 
    38:2f3c  0 days 0:00:00.015 
    27:278c  0 days 0:00:00.015 
    16:2a70  0 days 0:00:00.015 
    15:24a8  0 days 0:00:00.015 
    39:215c  0 days 0:00:00.000 
    36:2088  0 days 0:00:00.000 
    29:53c  0 days 0:00:00.000 
    28:26e0  0 days 0:00:00.000 
    26:2960  0 days 0:00:00.000 
    19:2a10  0 days 0:00:00.000 
    14:2208  0 days 0:00:00.000 
    13:2bcc  0 days 0:00:00.000 
    12:2a6c  0 days 0:00:00.000 
    9:1a38  0 days 0:00:00.000 
    6:1200  0 days 0:00:00.000 
    4:2620  0 days 0:00:00.000 

、私は

0:039> g 
(2944.1d6c): Break instruction exception - code 80000003 (first chance) 
mscorlib_ni+0x367240: 
000007fe`f8337240 cc    int  3 

を取得し、プロセスが中断したまま。どうすればいいですか？

Answer 1

最初にシンボルを修正する必要があります。あなたがwindbgのを添付した後、次の操作を行います。

.symopt + 0x100を、.symfixのC：\ websym; .reload

私の推測では、それがブレーク命令を取得するには大丈夫ですので、そのスレッド39が注入され、デバッガスレッドです一度gを打った後。あなたが何度もそれを得るなら、問題があります。

しかしグラムを打つ前に、このような暴走出力に最初のスレッド（あなたのケースでは33）に切り替える：！〜33S

そして、正しい.NETデバッガ拡張DLLをロードします。もし前に、.NET 4、実行します。

.loadby sos.dll mscorwks

.NET 4以降がない場合：

.loadby sos.dll CLR

今見てこれを行います管理スタック：！！

clrstack

は、その後再び発行し、再びに侵入、それは数秒間実行してみましょうclrstack、グラムを打ちます。スレッド33が何をしているのかを理解するために、何度か繰り返します。留意するたびに、！clrstackを発行する前にスレッド33に戻る必要があります。

管理スタックが表示されない場合は、kbを発行してネイティブスタックを表示します。

また、そのスレッドの例外を管理しているかどうかを確認することもできます。 ！peはあなたのためにそれを行います（そのスレッドに切り替えた後）。すべての管理例外オブジェクトをダンプすることもできます。私はコマンドがdumpalexceptionsだと思うが、ヘルプを使って（！helpを使って）確実にチェックする。メモ.NETは起動時に3つの例外オブジェクトを事前に割り当てます。これは（ほとんどの場合）！dumpalexceptionsの出力で無視できます（メモリ不足の状況に関係します）。

マルク・

Answer 2

私はCLRの例外は、そのプロセスを継続からあなたを何を停止していると思います。 は「SXI CLR」でこれらの例外を抑制し、簡単なトリックは、CPUの使用率が高いときにハングダンプ（1分間隔）のグループをキャプチャし、その後のWinDbgでそれらを分析することである

Answer 3

を続けます。暴走を使用すると、どのスレッドがほとんどのCPUを消費しているのかを確認し、コールスタックを調べて考えられる原因を突き止めることができます。

あなたがしたことはライブデバッグと呼ばれ、初心者にとっては簡単ではありません。