問題タブ [sos]

SOSの！SyncBlkコマンドによって生成された出力の説明を探しています。

特に、「MonitorHeld」の列には有用な説明が見つかりませんでした。この列は、一連のクラッシュダンプの高い値を示しています。

例：

「MonitorHeld」列の「99」を誰かが説明できますか？

このコマンドの完全なリファレンスドキュメントへのリンクはありますか？

ありがとう、アレックス

次のsosコマンドを使用して、実行中のaspアプリケーション（Windows XP 4 GBマシンでホストされている）の特定のタイプのすべてのインスタンスを列挙しました。

これは、gcgen2で指定されたタイプのすべてのオブジェクトを列挙します。

オブジェクトの平均サイズは約500KBのようで、オブジェクトは約2000個あります。これだけで約1GBのメモリが追加されますが、タスクマネージャのaspプロセスメモリには約700MBしか表示されません。もう1つのポイントは、使用している他のロードされたオブジェクトを考慮していないことです。

また、上記のオブジェクトはすべて、ガベージコレクションされないルートオブジェクトです。このコマンドが間違っているかどうか、またはsosが返すサイズのこの不一致について他の説明があり、タスクマネージャーに何が表示されているかわからない場合は、

よろしくお願いします、
BharathK。

タイトルはちょっとそれをすべて言います。通常のSOSコマンド！bpmdは、名前がないとあまり効果がありません。

私が持っていたいくつかのアイデア：

• すべてのメソッドをダンプし、対応するMethodDescが見つかったら ！bpmd-mdを使用します
  • 私の知る限り、実際の使用法では実用的ではありません。ダンプを匿名の型/メソッドに制限するマクロを作成したとしても、それらを区別する明確な方法はありません。
• リフレクターを使用してMSIL名をダンプします
  • 動的アセンブリやReflection.Emitを処理する場合は役に立ちません。Visual Studioがそのようなシナリオ内でローカル変数を読み取れないことが、私が最初にWindbgに目を向けた理由です...
• VSにブレークポイントを設定し、ヒットするのを待ってから、非侵襲的なトリックを使用してWindbgに変更します
  • VSからデタッチしようとすると、（アプリとともに）ハングします。これは、マネージデバッガーが標準の「ハード」デバッガーではなく、スレッドインジェクションによる「ソフト」デバッガーであるためだと思います。または、Silverlightに固有のVSバグである可能性があります（私が最初に遭遇したのはほとんどありません）。
• 匿名メソッドを呼び出すことがわかっている他の場所にブレークポイントを設定してから、シングルステップで
  • 私のバックアップ計画ですが、このQ＆Aでより良い方法が明らかになった場合は、それに頼りたくありません。

VisualStudio で SOS.dll を使用して C# プログラムをデバッグしています。プログラムは以下の通りです。

デバッグ コマンドは!DumpStackObjectsです。

Visual Studio のイミディエイト ウィンドウで「!dso」コマンドを入力すると、結果は次のようになります。

OS スレッド ID: 0xf6c (3948)

ESP/REG オブジェクト名

なんで何もないの？引数 i とローカル変数 j が必要だと思いました。

素朴な疑問に答えていただきありがとうございます...

WeakReference によってのみ保持されていると思われるオブジェクトがあります。私は SOS と SOSEX を使用してその参照所有者を追跡しましたが、どちらもこれが事実であることを確認しました (私は SOS の専門家ではないため、この点で間違っている可能性があります)。

WeakReferences の標準的な説明は、GC がスイープを行うときにそれらを無視するというものです。それにもかかわらず、私のオブジェクトは GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced) の呼び出しに耐えます。

WeakReference でのみ参照されるオブジェクトがそのコレクションを生き残ることは可能ですか? 私が強制できるさらに完全なコレクションはありますか? それとも、オブジェクトへの唯一の参照が弱いという私の信念を再検討する必要がありますか?

更新と結論

根本的な原因は、オブジェクトをロックしている参照がスタックにあったことです。なぜ SOS も SOSEX もその参照を示さなかったのかは不明です。ユーザーエラーは常に可能性があります。

根本原因を診断する過程で、私はいくつかの実験を行い、第 2 世代オブジェクトへの WeakReferences が驚くほど長い間存続できることを実証しました。ただし、WRd 第 2 世代オブジェクトはGC.Collect(GC.MaxGeneration, GCCollectionMode.Forced) では存続しません。

マネージド アプリケーションのクラッシュ ダンプを開き、スタック トレースを取得するプロセスを自動化しようとしています。Windgb は時々動作しますが、ダンプを処理するマシンがダンプが発生したマシンと実質的に同一でない限り、正しいバージョンの sos.dll をロードするのは悪夢です。

一方、Visual Studio は単純に作業を行います。ダンプを開き、すぐに表示されるウィンドウに移動して、次のように入力します。

そして、すべてがうまく機能します。

Visual Studio でこのプロセスをスクリプト化できますか? そうでない場合、windbg と同じ Visual Studio で使用されるバックエンド デバッガーはありますか?

以前に回答されたことは知っていますが、少し違う質問をしたいと思います。

Visual Studio Debug Watchウィンドウで評価できるGC.GetAliveInstancesOf（）を実装するための考えられる方法はありますか？Sasha Goldsteinは、この記事で1つの解決策を示していますが、クエリを実行するすべてのクラスが特定の基本クラスから継承する必要があります。

このメソッドはデバッグ中にのみ使用したいので、GCが実行時にメモリ内のオブジェクトのアドレスを変更する可能性があることを強調します。

1つのアイデアは、SOSの！dumpheap –typeコマンドを何らかの方法で利用し、一時変数を作成してSOSによって出力されたメモリアドレスを指すようにするための魔法のトリックを実行することです。

誰かがうまくいく解決策を持っていますか？

Silverlight の SOS に関する Microsoft または非公式のドキュメントはありますか。いくつかの Web 投稿を除いて、MSDN でドキュメントを見たことはありません。SOS の CLR バージョンの公式ドキュメントでさえ見つけるのが難しいようです。この古い記事では、Windows SDK に含まれている sos.htm ファイルについて言及していますが、もう存在しないようです。SOS を使用して Silverlight をデバッグするためのヒントはありますか? 次のブログ記事を見つけましたが、さらに詳しい情報を探しています。

http://davybrion.com/blog/2009/08/finding-memory-leaks-in-silverlight-with-windbg/
http://www.ningzhang.org/2008/12/19/silverlight-debugging-with- windbg-and-sos/
http://debuggingblog.com/wp/2009/07/07/windbg-extension-sos-in-clr-40net-framework-40-ctp-net-runtime-dll-renamed-and- sos-commands-just-got-richer/
http://www.netfxharmonics.com/label/debugging
http://blogs.msdn.com/b/tess/archive/2008/08/21/debugging-silverlight-applications -with-windbg-and-sos-dll.aspx
http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-および-gcroot-to-diagnose-a-net-memory-leak.aspx
http://blogs.msdn.com/b/delay/archive/2009/03/09/controls-are-like-diapers-you-don-t-want-a-leaky-one-implementing-the-weakeevent- pattern-on-silverlight-with-the-weakeeventlistener-class.aspx

sos を使用して、特定のクラスのメソッド テーブル エントリ リストを取得できます。

しかし、sos がテーブル エントリを a と一致させる方法がわかりませんMethodDesc。メモリ内のメソッド テーブルを突いても、JIT スタブを指すエントリ値しか得られません。そこから sを取得する方法がわかりませんMethodDesc。誰にもアイデアはありますか？

PresentationHost.exeのライブプロセス（ダンプではない）をデバッグしています。以前は正常に機能していましたが、数日前に突然上記のエラーメッセージが表示されました。！スレッド、！pe、事実上すべてのSOSコマンドが機能しません。

私が覚えているのは、エラーが発生する前にVisualStudio2010と.NETFramework4.0をインストールしたことだけです。それは関係がありますか？

アップデート：

私自身、自分が抱えていた問題を再現することはできません。おそらく、64ビットデバッガーを使用して32ビットプロセスをデバッグしていたか、.NET 2.0SOSを使用して.NET4プロセスをデバッグしていたか、またはその逆、あるいはビットネスとDLLバージョンの両方の組み合わせをデバッグしていました。

この質問は有効でない可能性があることをお詫び申し上げます。