問題タブ [sos]

メソッド テーブルに格納されている情報を理解しようとしています。これが私のコードです。

これは、オブジェクトがメモリ内でどのように見えるかです

次に、メソッドテーブルをダンプします

これが私が少し混乱しているものです。

1. 最初のフィールドは、オブジェクトのタイプを示します (クラスまたは配列などの場合)。私の理解では、クラスの場合、このフィールドは表示されます0x00040000が、ここでは0x00000000.

2. 2 番目のフィールドは、オブジェクトのサイズです。これは大丈夫です。

3. 3 番目のフィールドの意味は何00050011ですか?

4. これは、継承されたメソッドの数を示し、親オブジェクト クラスのメソッドToString、Equals、GetHashCodeおよびを指しますFinalize。これは正しいです？

私は他の分野を理解していないので、それらについても説明していただければ幸いです。

私は Windbg/SOS を使用しており、マネージ コードを調べています。問題は、コードが難読化されていることです。これらをどのようにデバッグできるか考えていますか?

OSバージョン、サービスパック、.NET Frameworkバージョンなど、ダンプファイルが作成されたホストに関する情報を取得することは可能ですか。

clrdumpを使用してダンプを作成しました。sosを使用して表示する場合、sosをロードしてから！dsoを実行しますが、エラーは次のとおりです。

ただし、モジュールウィンドウには、シンボルがロードされていると表示されます。MSストアから最新のシンボルを入手しましたか？

誰かアイデアはありますか？

ありがとう、

ダレン。

Naveenのブログ（http://naveensrinivasan.com/2010/06/11/piracy-in-net-code-%e2%80%93-part-3-%e2%80%93 ）で提供されているコードサンプルを試しています。 -コードが難読化されている場合でも/。
彼が!u ($ip)コマンドを実行すると、彼は素晴らしい逆アセンブルを取得していますが、同じことを実行しようとすると、逆アセンブルできなかったアンマネージコードにぶつかったようです。

私が間違っているかもしれない何か考えはありますか？

背景: 私は WinDbg が初めてで、初めて実行しようとしています。Windows Server 2008 (x86) 上の IIS 7 でホストされている実行中の ASP.NET 4 サイトから取得し、ローカル コンピューターにダウンロードしたメモリ ダンプを調べたいと考えています。

デバッグ ツールをインストールし、WinDbg を初めて起動して、クラッシュ ダンプを開きました。私はファイルに行きました | シンボル ファイル パスにパスを設定し、*srv*c:\symbols*http://msdl.microsoft.com/download/symbols*すべてのシンボルが読み込まれるのを待ちました。

SOS を読み込もうとしたときに、問題が発生しました。まず、次のコマンドを試しました...

...そして応答を受け取りましたUnable to find module 'mscorwks'。

Web を精査した後、次のコマンドを実行して mscorwks をロードしようとしました...

...そして、「「g」に実行可能なデバッグ対象がありません」という応答を受け取りました

SOS.dll (C:\Windows\Microsoft.NET\Framework\v4.0.30319 から) を WinDbg ディレクトリにコピーしてから、試しました...

...そしてエラーを受け取りました...

どのように進めればよいかよくわかりません。SOS をロードして、このダンプ ファイルを掘り下げたいだけです。どんな助けでも大歓迎です。

参考までに... 64 ビット バージョンの Windows 7 で 64 ビット バージョンの Windbg を使用してダンプ ファイルを開こうとしています。

.netアプリケーションのデバッグの観点から、仮想メモリと物理メモリリークの違いを理解するのに苦労しています。

誰かがこの概念を例を挙げて詳しく説明できますか？どのようにして1つのタイプのリークだけを持ち、他のタイプのリークは持たないのでしょうか。

TIA

Windbg を使用して、VS2010 .net4 アプリケーションで未処理の例外の適切なコールスタックを取得しようとしています。メイン プログラムはコンソール アプリケーションです。この dll は、そのシンボルを適切にロードします。同じディレクトリに、読み込まれない dll+ 一致する pdb があります。

Windowsサーバー2008 R2、64ビット（VSがインストールされていません）でアプリを実行しています。しかし、アプリは 32​​ ビットでコンパイルされました。winX86 デバッガーを使用してプロセスにアタッチしています。

http://www.stevestechspot.com/ (32 ビット バージョン)から .net 4 をサポートする sosex をダウンロードしました 。 clr10\sos.dll") のバージョンは 6.12.2.633 です。

次のコマンドを発行しました:
sympath+ "...exe と dll のフォルダー"
.loadby sos clr
.load sosex.dll

!mk を実行すると、次のようになります。

!clrstack を実行すると、次のようになります。

ご覧のとおり、どちらの場合も、xxx.Services.StickyNotes.dll 行を除いて、ファイル名とスタック内の行番号を取得します。

試してみました: .realod /f ""c:...\xxx.Services.StickyNotes.dll" - 同じエラーと
ld "c:...\xxx.Services.StickyNotes.dll"が発生しました。

「c:...\Bin\xxx.Services.StickyNotes.dll」に一致するモジュールはありません

モジュール自体がロードされていないため、pdbをロードしようとさえしないと思います。

この特定の dll が読み込まれない理由がわかりません。SN_Console.exe と SNB_Bridge.dll は、同じディレクトリから問題なくロードされます。（私は例外自体には関心がありません。作成するコードを植えました。問題は、適切なデバッグ環境を設定することです）。

前もって感謝します、 タマール

データ アクセス DLL の読み込みに失敗しました、0x80004005 1) デバッガーの最近のビルド (6.2.14 以降) があること、2) mscorwks.dll のバージョンに一致するファイル mscordacwks.dll がバージョン ディレクトリにあること、3) または、ダンプ ファイルをデバッグしている場合は、ファイル mscordacwks_.dll はシンボル パスにあります。4) ダンプ ファイルと同じアーキテクチャでデバッグしている。たとえば、IA64 ダンプ ファイルは IA64 マシンでデバッグする必要があります。

WPF を使用する混合モードの C++/CLI アプリケーションがあります。お客様からのクラッシュは、ミニダンプとして独自のサーバーに報告されます。

windbg sos-extension から !pe または !clrstack コマンドを使用してミニダンプを調査しようとすると、WPF アセンブリからスタック フレームに関する不完全な情報が得られることがよくあります。

この場合、スタック トレースのデコードも非常に遅くなります。

!sym ノイジーを使用すると、次のメッセージが大量に表示されます。

使った

c:\Windows\System32;SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols

windbg シンボルおよびイメージ パスとして。

私が理解している限り、クラッシュが発生したマシンとデバッガーを搭載したマシンが Windows バージョン、SP の .NET バージョンに関して異なる場合、これは .NET ネイティブ イメージでのみ発生します。主に WPF ネイティブ イメージで見てきました。

この問題を回避するにはどうすればよいですか?

私の最初の質問への更新：

異なる mscordacwks dll バージョンで同様の問題に苦労したことを忘れていました。SOS を使用するには、クラッシュしているコンピューターで使用されていたバージョンの mscordacwks.dll がデバッグ コンピューターに必要です。そこで、さまざまな Windows と SP の組み合わせからこの dll のさまざまなバージョンを収集し、独自のシンボル サーバーに配置することにしました。もちろん、これは非常に厄介です。特別な規則 (mscordacwks_x86_x86_2.0.50727.4952.dll など) に従って名前を付ける必要があるため、なおさらです。

以下の Rick の回答を正しく理解している場合は、参照する .NET アセンブリのネイティブ イメージに対して同様のことを行う必要があります。1 つの例 (WindowsBase.ni.dll) でこれを手動で試しましたが、この dll をシンボル サーバーに簡単に保存できませんでした。symstore がネイティブ イメージを認識していないようです。symstore からのエラー メッセージは次のとおりです。

そのため、それを追加のディレクトリに配置して、シンボルまたはイメージ パスに追加しようとしたところ、SOS は WindowsBase_ni フレームを正しくデコードしました。

しかし、これはすべて面倒な手動セットアップ作業のように思えます: さまざまな .NET バージョンのすべてのネイティブ イメージを取得し (SP とセキュリティ アップデートはどうなるか)、symstore を使用できないため手動でデバッガーをセットアップする...

これが本当に唯一の方法ですか？

顧客の環境を制御できれば、おそらくそれほど問題にはなりません。しかし、大規模なユーザーベース向けに混合モードのアプリケーションを構築している組織にとって、事後分析のデバッグは悪夢のようです。