問題タブ [sos]

IE8.0で実行されているSilverlightアプリケーションをデバッグしようとしています。.NETFramework4.0とSilverlight4.0を使用しています。そこで、WindbgをIE実行インスタンスに接続します。IE8では、InternetExplorerの正しいインスタンスに接続する必要があることを理解しています。したがって、ここに添付すると、プロセスでロードされたものとして表示されるdllが表示されます。ご覧のとおり、coreclrがそこにロードされています。

実行可能な検索パスは次のとおりです。ModLoad：00a00000 00a9c000 C：\ Program Files \ Internet Explorer \ IEXPLORE.EXE
ModLoad：77890000 779b8000 C：\ Windows \ system32 \ ntdll.dll
ModLoad：76450000 7652c000 C：\ Windows \ system32 \ kernel32.dll
ModLoad ：76380000 76446000 C：\ Windows \ system32 \ ADVAPI32.dll
ModLoad：779d0000 77a93000 C：\ Windows \ system32 \ RPCRT4.dll
ModLoad：76680000 7671d000 C：\ Windows \ system32 \ USER32.dll
ModLoad：77aa0000 77aeb000 C：\ Windows \ system32 \ GDI32.dll
ModLoad：77590000 7763a000 C：\ Windows \ system32 \ msvcrt.dll
ModLoad：77530000 77589000 C：\ Windows \ system32 \ SHLWAPI.dll
ModLoad：76940000 77451000 C：\ Windows \ system32 \ SHELL32.dll
ModLoad：76530000 76675000 C：\ Windows \ system32 \ ole32.dll
ModLoad：75f60000 76149000 C：\ Windows \ system32 \ iertutil.dll
ModLoad：77750000 77883000 C：\ Windows \ system32 \ urlmon.dll
ModLoad：768b0000 7693d000 C：\ Windows \ system32 \ OLEAUT32.dll
ModLoad：77730000 7774e000 C：\ Windows \ system32 \ IMM32.DLL
ModLoad：77460000 77528000 C：\ Windows \ system32 \ MSCTF.dll
ModLoad：76330000 76339000 C：\ Windows \ system32 \ LPK.DLL
ModLoad： 6be40000 6c8d5000 C：\ Windows \ system32 \ IEFRAME.dll
ModLoad：76220000 76293000 C：\ Windows \ system32 \ comdlg32.dll
ModLoad：72570000 725a3000 C：\ Program Files \ Internet Explorer \ IEShims.dll
ModLoad：74f60000 74f9f000 C：\ Windows \ system32 \ uxtheme.dll
ModLoad：75de0000 75dfe000 C：\ Windows \ system32 \ USERENV.dll
ModLoad：75dc0000 75dd4000 C：\ Windows \ system32 \ Secur32.dll
ModLoad：75430000 7546b000 C：\ Windows \ system32 \ rsaenh.dll
ModLoad：76720000 768aa000 C：\ Windows \ system32 \ SETUPAPI.dll
ModLoad：73e40000 73efb000 C：\ Windows \ system32 \ PROPSYS.dll
ModLoad：762a0000 76324000 C：\ Windows \ system32 \ CLBCatQ.DLL
ModLoad：722c0000 72300000 C：\ Program Files \ Internet Explorer \ ieproxy.dll
ModLoad：6eae0000 6eb33000 C：\ Windows \ system32 \ ACTXPRXY.DLL
ModLoad：77640000 77726000 C：\ Windows \ system32 \ WININET.dll
ModLoad：76370000 76373000 C：\ Windows \ system32 \ Normaliz.dll
ModLoad：76340000 7636d000 C：\ Windows \ system32 \ ws2_32.dll
ModLoad：779c0000 779c6000 C：\ Windows \ system32 \ NSI.dll
ModLoad：75d30000 75d5c000 C：\ Windows \ system32 \ apphelp.dll
ModLoad：74460000 744aa000 C：\ Windows \ system32 \ RASAPI32.dll
ModLoad：74440000 74454000 C：\ Windows \ system32 \ rasman.dll
ModLoad：75bf0000 75c66000 C：\ Windows \ system32 \ NETAPI32.dll
ModLoad：75e90000 75e97000 C：\ Windows \ system32 \ PSAPI.DLL
ModLoad：74170000 741a1000 C：\ Windows \ system32 \ TAPI32.dll
ModLoad： 74430000 7443c000 C：\ Windows \ system32 \ rtutils.dll
ModLoad：74130000 74162000 C：\ Windows \ system32 \ WINMM.dll
ModLoad：740f0000 7412d000 C：\ Windows \ system32 \ OLEACC.dll
ModLoad：75830000 75922000 C：\ Windows \ system32 \ CRYPT32.dll
ModLoad：75990000 759a2000 C：\ Windows \ system32 \ MSASN1.dll
ModLoad：6ffe0000 6ffe6000 C：\ Windows \ system32 \ sensapi.dll
ModLoad：755f0000 755f7000 C：\ Windows \ system32 \ credssp.dll
ModLoad：754c0000 75506000 C：\ Windows \ system32 \ schannel.dll
ModLoad：7512​​0000 75134000 C：\ Windows \ system32 \ wpclsp.dll
ModLoad：759b0000 759c1000 C：\ Windows \ system32 \ SAMLIB.dll
ModLoad：75200000 7520f000 C：\ Windows \ system32 \ NLAapi.dll
ModLoad： 75790000 757a9000 C：\ Windows \ system32 \ IPHLPAPI.DLL
ModLoad：75750000 75785000 C：\ Windows \ system32 \ dhcpcsvc.DLL
ModLoad：759d0000 759fc000 C：\ Windows \ system32 \ DNSAPI.dll
ModLoad：75740000 75747000 C：\ Windows \ system32 \ WINNSI.DLL
ModLoad：75710000 75732000 C：\ Windows \ system32 \ dhcpcsvc6.DLL
ModLoad：755b0000 755eb000 C：\ Windows \ system32 \ mswsock.dll
ModLoad：754b0000 754b5000 C：\ Windows \ System32 \ wshtcpip.dll
ModLoad：709e0000 709e6000 C：\ Windows \ system32 \ rasadhlp.dll
ModLoad：70a40000 70a70000 C：\ Windows \ system32 \ MLANG.dll
ModLoad：75230000 75251000 C：\ Windows \ system32 \ NTMARTA.DLL
ModLoad：76150000 76199000 C：\ Windows \ system32 \ WLDAP32.dll
ModLoad： 756a0000 756a8000 C：\ Windows \ system32 \ VERSION.dll
ModLoad：75690000 75695000 C：\ Windows \ System32 \ wship6.dll
ModLoad：704d0000 704df000 C：\ Windows \ system32 \ napinsp.dll
ModLoad：70490000 704a2000 C：\ Windows \ system32 \ pnrpnsp.dll
ModLoad：704c0000 704c8000 C：\ Windows \ System32 \ winrnr.dll
ModLoad：704b0000 704bc000 C：\ Windows \ system32 \ wshbth.dll
ModLoad：75290000 752a5000 C：\ Windows \ system32 \ GPAPI.dll
ModLoad：757f0000 7582a000 C：\ Windows \ system32 \ slc.dll
ModLoad：6ffc0000 6ffdb000 C：\ Windows \ system32 \ cryptnet.dll
ModLoad：74ef0000 74f05000 C：\ Windows \ system32 \ Cabinet.dll
ModLoad：56070000 563d9000 c：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ coreclr.dll

チェーンコマンドの出力は次のとおりです

0：027> .chain
拡張DLL検索パス：
C：\ Program Files \ Debugging Tools for Windows（x86）\ WINXP; C：\ Program Files \ Debugging Tools for Windows（x86）\ winext; C：\ Program Files \ Debugging Tools for Windows（x86）\ winext \ arcade; C：\ Program Files \ Debugging Tools for Windows（x86）\ pri; C：\ Program Files \ Debugging Tools for Windows（x86）; C：\ Program Files \ Debugging Tools for Windows（x86）\ winext \ arcade; C： \ Program Files \ Common Files \ Microsoft Shared \ Windows Live; C：\ Windows \ system32; C：\ Windows; C：\ Windows \ System32 \ Wbem; c：\ Program Files \ Microsoft SQL Server \ 90 \ Tools \ binn \ ; C：\ Windows \ System32 \ WindowsPowerShell \ v1.0 \; C：\ Program Files \ Microsoft SQL Server \ 100 \ Tools \ Binn \; C：\ Program Files \ Microsoft SQL Server \ 100 \ DTS \ Binn \; C ：\ Program Files \ Microsoft SQL Server \ 100 \ Tools \ Binn \ VSShell \ Common7 \ IDE \; C：\ Program Files \ Microsoft Visual Studio 9.0 \ Common7 \ IDE \ PrivateAssemblies \; C：\ Program Files \ Microsoft Windows Performance Toolkit \; C：\ Program Files \ QuickTime \ QTSystem \; C：\ Program Files \ Windows Live \ Shared
拡張DLLチェーン：
C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ sos.dll：image 4.0.30319.225、API 1.0.0、ビルド済みWed Feb 09 23:49:57 2011
[path：C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ sos.dll]
C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ clr.dll：画像4.0.30319.225、2011年2月9日水曜日23:24:43
[パス：C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ clr.dll]
C：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ coreclr：image 4.0.60129.0、build Sat Jan 29 02:06:01 2011
[パス：C：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ coreclr.dll]
C：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ sos.dll：image 4.0.60129.0、API 1.0.0、ビルド土2011年1月29日02:07:57
[パス：C：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ sos.dll]
C：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ sos：image 4.0.60129.0、API 1.0.0、Sat Jan 29 02 ：07：57 2011
[パス：C：\ Program Files \ Microsoft Silverlight \ 4.0.60129.0 \ sos.dll]
C：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ sos：image 2.0.50727.4421、API1.0。 0、2010年10月25日月曜日01:31:50
[パス：C：\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ sos.dll]
dbghelp：image 6.12.0002.633、API 6.1.6、月曜日2月1日ビルド15:08:26 2010
[パス：C：\ Program Files \ Debugging Tools for Windows（x86）\ dbghelp.dll]
ext：image 6.12.0002.633、API 1.0.0、ビルド済みMon Feb 01 15:08:31 2010
[パス：C：\ Program Files \ Debugging Tools for Windows（x86）\ winext \ ext.dll]
exts：image 6.12.0002.633、API 1.0.0、ビルド済みMon Feb 01 15:08:24 2010
[パス：C： \ Program Files \ Debugging Tools for Windows（x86）\ WINXP \ exts.dll]
uext：image 6.12.0002.633、API 1.0.0、built Mon Feb 01 15:08:23 2010
[path：C：\ Program Files \ Debugging Tools for Windows（x86）\ winext \ uext.dll]
ntsdexts：image 6.1.7650.0、API 1.0.0、built Mon Feb 01 15:08:08 2010
[path：C：\ Program Files \ Debugging Tools for Windows（x86 ）\ WINXP \ ntsdexts.dll]

問題は、sosをロードしようとすると、次のエラーが発生することです。

0：027> .loadby sos coreclr
0：027>！threads
ランタイムDLL（clr.dll）が見つかりませんでした。0x80004005
拡張コマンドで何かを行うには、clr.dllが必要です。

私がここで間違っていることについて何か考えはありますか？

COM 相互運用を行い、いくつかのネイティブ ライブラリ API を呼び出す .net アプリケーションがあります。これらの API の 1 つが予期しないデータを返し、頭痛の種になっています。マネージ API の戻り値を強制する方法を探しています。これは私の問題を解決するつもりはありませんが、いくつかのことを絞り込むのに役立ちます. 以下で少し単純化しています。

これらすべてを念頭に置いて、マネージ クラスの名前が MyClass で、ParentMethod() と ChildMethod() の 2 つのメソッドがあるとします。ParentMethod は、これらのネイティブ API を内部的に呼び出す ChildMethod を呼び出します。ChildMethod 自体は bool を返します。

Windbg 経由でアプリに侵入した後、最初に !dumpheap -type MyClass コマンドを実行すると、次の出力が得られました

0:027> !dumpheap -type MyClass
アドレス MT サイズ
0ac7e7e4 04ac5030 100
合計 0 オブジェクト
統計:
MT カウント TotalSize クラス名
04ac5030 1 100 MyNamespace.MyClass
合計 1 オブジェクト

次に、このクラスのメソッドのアドレスを取得しようとして、次のコマンドを実行しました。

0:027> !dumpmt -md 04ac5030
EEClass: 04ac1b20
モジュール: 04ac49c8
名前: MyNamespace.MyClass
mdToken: 02000002
ファイル: MyAssemblyName、Version=1.0.0.0、Culture=neutral、PublicKeyToken=null
BaseSize: 0x64
ComponentSize: 0x0
VTable のスロット: 61
IFaceMap の IFace の数: 4
MethodDesc テーブル
エントリ MethodDesc JIT 名
04b20270 04ac4f​​d0 JIT MyNamespace.MyClass..ctor()
04b20230 04ac4f​​fc JIT MyNamespace.MyClass..cctor()
04acc081 04ac4f​​d8 なし MyNamespace.MyClass.ParentNameMethod()
04acc085 NONE Myac4fe4 .MyClass.ChildMethod()
04b202c0 04ac4f​​f0 JIT MyNamespace.MyClass.InitializeComponent()

Naveen のブログ エントリで、同じ方向に沿って何かを行うためのテクニックについて説明しているのを見つけましたが、ここから具体的にどのような手順を踏めばよいのかわかりませんでした。どんな助けでも大歓迎です。

Windbg/SOS を使用して、スタック上のローカル変数の値を変更することは可能ですか? もしそうなら、どのように？

使用しているメモリリークを追跡しています

!dumpheap -stat !dumpheap -mt !gcroot

ただし、 !gcroot は何も表示しません。これは、オブジェクトに参照がなく、収集されていないことを意味すると考えていました。しかし、私は 100% の自信があるわけではありません。

IOException別のプロセスで使用されているため、ファイルを削除できないことに注意して、定期的に を発生させるテストをデバッグしています。プロセスは確かに私のテスト ハーネスであり、プロセス内の他のスレッドは、期待したときにそのファイル リソースを破棄していないのではないかと思います。

どのスレッドが妨害ロックを保持しているかを判断するために使用できるツールはありますか? スレッドを特定できれば、そのコール スタックを調べて、少なくともリソースがまだ破棄されていない理由を特定することができます。SOS デバッグ ツールは有望に見えますが、私の調査からかなりの量の当て推量を取り除く機能は見当たりません。

1 つの考えとしては、ネイティブ OS スレッド ID を識別し、SOS を介してマネージド スレッド ID にマップすることができます。どうすれば前者を達成できますか？

私の .net ベースのアプリケーションはクアッドコア マシンで実行されていますが、!eeheap -gc コマンドを実行すると、次のように表示されます。

GC ヒープ数: 1

アプリケーションが 4 つのプロセッサすべてを使用していないということですか? なぜこれが起こっているのか、この動作をどのように変更できるのか考えていますか?

.net マネージド アプリケーションが、InterOP を介してアンマネージド コンポーネントと相互作用するとします。メモリの問題をデバッグする必要がある場合。管理されていないコンポーネントが正確にどこにメモリを割り当てますか? GCで使用されているのと同じヒープですか(私は疑問です)、それとも他の領域ですか? Windbg のデバッグを行っていますが、!dumpheap のような SoS コマンドを介してアンマネージ コンポーネントによる割り当てを確認できるかどうか疑問に思っています。

以下は、オブジェクト 0330e9a8 の gcroot を確認したものです。そのルートは、そのタイプが「RefCnt」のハンレであることがわかりました。

実際の参照カウントを取得するにはどうすればよいですか。そして、どのオブジェクトがその参照を取得したかをどのように知ることができますか?

c# 4.0 で記述された Windows サービスで、プロセスがクラッシュしたときにダンプを保存するように gflags.exe(Global Flags) を設定します。

しかし、windbg でクラッシュ ダンプを開くと、 0:00> が表示されます。私は windbg が苦手で、Tess のブログで、クラッシュ ダンプを開くと、例外が発生したスレッド ID が表示されるはずだと書かれていたことを思い出しましたが、表示されるのは 0:00>... で、!pe には有用な結果がありません。

!dumpheap -stat を使用すると、いくつかのオブジェクトしか表示されませんでした。このダンプを分析するにはどうすればよいですか? 助けてくれてありがとう。

Windbg からマネージ メソッドを呼び出すことはできますか? に相当する.NETはあります.callか? または、それを使用してマネージド メソッドを呼び出す方法は?

Visual Studio Debugger を使用する可能性がない実稼働 (pdb なしのリリース) のプロセスにライブ セッションとしてアタッチすることに興味があります。