2

現在、.NETアプリケーションでのアプリケーションのハングを修正することに取り組んでいます。いくつかの調査の結果、windbgは、アプリケーションがハングしたときにアプリケーションで何が起こっているかについての洞察を提供できることがわかりました。

ユーザーシステムにぶら下がっているアプリケーションに続いて、windbgを使用してさらに情報を収集しました。

まず、GUI / STAスレッドを特定しました（CorExeMainを探しています）

0:011> ~*
   0  Id: 1488.314 Suspend: 1 Teb: 7ffdf000 Unfrozen
      Start: mscoree!_CorExeMain_Exported (79004ddb) 
      Priority: 0  Priority class: 32  Affinity: 3

私は次のことに気づきました：

0:000> k
ChildEBP RetAddr  
0012eb2c 7c90df2c ntdll!KiFastSystemCallRet
0012eb30 7c809574 ntdll!NtWaitForMultipleObjects+0xc
0012ebcc 7e4195f9 KERNEL32!WaitForMultipleObjectsEx+0x12c
0012ec28 7752ebd6 USER32!RealMsgWaitForMultipleObjectsEx+0x13e
0012ec50 77557237 ole32!CCliModalLoop::BlockFn+0x80
0012ecc4 79f9e14d ole32!CoWaitForMultipleHandles+0xcf
0012ece4 79f9e0b4 mscorwks!NT5WaitRoutine+0x51
0012ed50 79f9e018 mscorwks!MsgWaitHelper+0xa5
0012ed70 79f4c664 mscorwks!Thread::DoAppropriateAptStateWait+0x28
0012edf4 79f4c6f9 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
0012ee44 79f15a68 mscorwks!Thread::DoAppropriateWait+0x40

windbgの使用経験は限られていますが、私が行った調査から、WaitForMultipleObjectsはイベントを待機している可能性があることを示しているという印象を受けます。これが原因である可能性があるかどうか誰かに教えてもらえますか？

私が受け取ったいくつかの警告があり、環境が正しく設定されていないのではないかと思います。

0012ee44 79f15a68 mscorwks!Thread::DoAppropriateWait+0x40
*** WARNING: Unable to verify checksum for C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\6d667f19d687361886990f3ca0f49816\mscorlib.ni.dll
0012ef48 792b68af mscorwks!WaitHandleNative::CorWaitOneNative+0x156

と

0012f2ac 03af4dea USER32!DispatchMessageW+0xf
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f2c8 7b1d8d2e 0x3af4dea

イベントを待っているアプリケーションについて私が考えた理由があるかどうか、または調査する価値のある考えられる原因や領域について誰かがすぐに考えているかどうかを誰かが提案できますか？

また、Son of Strikeをフォローアップする価値があるかどうか疑問に思っていますか？

4

1 に答える 1

3

管理対象スレッドのネイティブコールスタックを見ています。その待機は、.NETの内部の一部です。何が起こっているのかを理解するために深く掘り下げていることに気付くかもしれませんが、実際に懸念しているのは、アプリケーションの管理された状態です。

これを行うには、sosエクステンションをwindbgにロードします。これは、windbgの本来の性質と.NETの間のギャップを埋めます。

この拡張機能をロードするコマンドは、.NET Frameworkのバージョンによって異なりますが、次のようになります。

.loadby sos clr

...またはおそらく...

.loadby sos mscorwks

そこから、sosが提供するエクスポートを使用して.NETアプリケーションをデバッグできます。開始点として、マネージドコールスタックが必要になります。これにより、コードのどこでハングが発生しているのかがわかります。

!clrstack

MSDNには、sos拡張機能が提供するものに関する優れたリファレンスがあります。 http://msdn.microsoft.com/en-us/library/bb190764.aspx

于 2012-11-22T19:12:47.997 に答える