1

私は.NET3.5WPFアプリケーションを使用しており、Win 7 64ビットでのみ実行している場合にCPU時間の96〜99％を使用することがあります。もちろん、これが発生すると、アプリケーション自体も正しく機能しなくなります。これは、64ビットバージョンのWindows7でのみ発生する別の問題です。

アプリケーションは現在この状態にあり、WinDbgまたはその他のデバッグツールを使用して、可能な限り多くの情報をキャプチャしたいと思います。これをリアルタイムで支援できるオンラインの人はいますか？

まず、これは私がProcess Explorerから取得できるものです。添付の​​画像が示すようここに画像の説明を入力してくださいに、スレッド数は40で、開始アドレスを持つスレッド数がたくさんあります。

mscorwrks.dll!GetMetaDataInternalInterfaceFromPublic+0x934c.

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

そのため、現在、すべてのスレッドを一時停止しているWinDbgを使用するプロセスに接続しています。それから私はしました

!runaway 3

それは私に与えます：

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

gプロセスを続行するために発行すると、

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

プロセスは中断されたままです。どうすれば続行できますか？

4

3 に答える 3

2

まず、シンボルを修正する必要があります。windbgを取り付けたら、次の手順を実行します。

.symopt + 0x100; .symfix c：\ websym; .reload

私の推測では、スレッド39は挿入されたデバッガスレッドであるため、gを押した後にそのブレーク命令を1回取得しても問題ありません。あなたがそれを複数回得るならば、それから問題があります。

ただし、gを押す前に、！runaway出力の最初のスレッド（この場合は33）に切り替えてください：〜33s

次に、正しい.NETデバッガ拡張dllをロードします。.NET 4より前の場合は、次のようにします。

.loadby sos.dll mscorwks

.NET 4以降の場合：

.loadby sos.dll clr

次に、これを実行して、管理対象スタックを確認します。

！clrstack

次に、gを押して数秒間実行し、再度侵入してから、！clrstackを再度発行します。スレッド33が何をしているのかを理解するために、数回繰り返します。ブレークするたびに、！clrstackを発行する前にスレッド33に戻す必要があることに注意してください。

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

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

マーク

于 2012-04-16T19:12:19.710 に答える
0

clrの例外は、プロセスの続行を妨げているものだと思います。「sxiclr」を使用してこれらの例外を抑制し、続行します

于 2012-04-17T11:38:20.527 に答える
0

簡単なトリックは、CPU使用率が高いときにハングダンプのグループ（1分間隔）をキャプチャし、それらをWinDbgで分析することです。暴走を使用すると、どのスレッドがCPUの大部分を消費しているかを確認し、その呼び出しスタックをチェックして考えられる原因を特定できます。

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

于 2012-04-17T13:04:51.350 に答える