問題タブ [windbg]

windbg ユーザー モードのリモート デバッグ セッションを開始するためのお気に入りのテクニックは何ですか? 他の手法よりもこの手法を好む理由は何ですか? （長所短所）

Windows ヘルプ ファイルのデバッグ ツールの「リモート デバッグ」セクションに記載されているように、windbg を使用してユーザー モードのリモート デバッグを実行するには、少なくとも 4 つの異なる方法があります。

1. ターゲットでアプリを実行し、ホストwindbgからアタッチします
2. ホストのwindbgでremote.exeを使用して、ターゲットでアプリを起動します
3. 「スマートクライアント」ホストのwindbgに、ターゲットで実行されているプロセスサーバーを介してターゲットでアプリを起動させます
4. オプション「-server」を使用してターゲットマシンでwindbgインスタンスを実行し、サーバーを自動的に起動してから、2番目のマシンからサーバーに接続します。

コンピューターのデバッグの複雑さを学び始めたばかりの人間として、Windbg でダンプのスタック テキストを読み取る方法を一生理解できません。それらをどのように解釈するか、またはどのようにそれを行うかについて、どこから始めればよいかわかりません。この哀れな魂に道を教えてくれる人はいますか？

すなわち（私が実際に手元に持っている唯一のダンプ）

問題が Nvidia ディスプレイ ドライバに関係していることはわかっていますが、知りたいのは実際にスタックを読み取る方法です (たとえば、b69dd8f4 とは何ですか?) :-[

Win32 プロダクション プロセスでのデッドロックによる明らかなハングをデバッグするための手順とテクニックは何ですか。この目的で WinDbg を使用できると聞きましたが、これを実現する方法について明確なヒントを教えてください。

過去8時間ほど追跡/解決しようとしてきた厄介なスタックオーバーフローがあり、アドバイスが必要だと思うところまで来ました。

詳細: 興味深いことに、通常の winforms アプリケーションのコンテキストで呼び出された場合、このコードは問題なく動作しますが、私はソフトウェアの Web ベース バージョンを作成する任務を負っています。 IIS で実行されている ASPX ページ。私が最初にしたことは、アタッチして、Visual Studio を介して通常の .NET デバッグを試みることでした。例外の時点で、コール スタックは比較的浅く (コードの約 11 フレームの深さ)、スタック オーバーフローの通常の疑い (不適切な再帰、自己呼び出しコンストラクター、例外ループ) を見つけることができませんでした。

だから私は、windbg と SOS を分解することに自分自身を辞任しました。何時間も遊んだ後、役に立つデータがいくつかあると思いますが、それを分析する助けが必要です。

最初は、スタック オーバーフローが発生する直前に壊れていた !dumpstack です。

そこにはたくさんのものがありますが、私の（確かに限られた）スタック分析知識ではループを示しているものは何もありません。ただし、この次のセクションには何らかの価値があると思います。これは、同じブレークポイントで取得した !dumpstackobjects です。

^^ この投稿に合わせるために、上記の一部を切り取る必要がありましたが、このまま続くと想像してみてください ^^

カスタム コードの詳細は無視してください。これはすべて私には過剰に思えますが、私はスタックの専門家ではありません。上記のスタック オブジェクト (1500 以上あります) のほとんどは関数パラメーターではないため、そこに属していないと思います。以下は、スタック上でこれらすべての項目を生成する種類のコードの例です (このような大量のコードが実行されます)。

私は VB の専門家でもありません (このコードは、私が通常は使用しないアプリケーションの別の部分からのものです) が、このようなコードでスタックがいっぱいになるのは正常ですか? 誰かが洞察を持っている場合、またはこの種のものに関する情報を含むリソースの方向性を教えてくれる場合は、大歓迎です. ご覧いただきありがとうございます。

別のプロセスまたは WinDBG 内部から .NET プロセスでガベージ コレクションをトリガーする方法はありますか?

ネイティブ/マネージド境界を越えて移動するときにコレクションを強制するマネージド デバッグ アシスタントがあり、AQTimeにはこれを行うことを示唆するボタンがあるようですが、その方法に関するドキュメントが見つかりません。

GDI をリークしていると思われるアプリケーションのクラッシュ ダンプがあります。アプリは XP で実行されており、WinDbg に読み込んで確認しても問題ありません。以前は、Gdikdx.dll 拡張機能を使用して Gdi情報を確認していましたが、この拡張機能は XP または Vista ではサポートされていません。

WinDbg で GDI オブジェクトの使用法を見つけるためのポインタはありますか。

または、失敗したプログラム (およびそのストレス テスト スイート) にアクセスできるので、XP および Vista (または Windows 2000 のターゲットではありません) 用の「ライブ」デバッグ ツールを知っていれば、実行中のシステムで再現できます。 .

Microsoft Debugging Tools for Windowsに同梱されているLoggerツールを使用したいと考えています。ただし、Vista ではビルトインの Vista アプリケーションでもクラッシュします。

また

この問題は、管理者権限の有無にかかわらず、コマンド プロンプトからツールを実行すると発生します。バージョン 3.01 (2008 年 3 月 20 日) を使用しています。

Logger の出力ウィンドウに最後に表示されるのは、「Verbose log Enabled」です。

デバッガーをアタッチすると、次のコール スタックで "アクセス違反書き込み場所 0x000000" エラーが発生したことがわかります。

誰もこの問題に遭遇し、それを修正する方法を知っていますか?

WinDbgと Visual Studio デバッガーを使用する主な理由は何ですか?

また、Visual Studio デバッガーの完全な代替品として一般的に使用されているのか、それとも必要が生じたときにそれ以上のものとして使用されているのでしょうか。

マネージド/アンマネージド環境 (Visual Studio と ReSharper) が混在しており、CCW または RCW リークが疑われます。現在割り当てられているすべてのラッパーをダンプして、ソース/ターゲットを特定する方法はありますか? WinDbg、SOS、SOSEx があるので、!syncblk コマンドで RCW と CCW の合計数を確認できます。私はただオブジェクトを見たいだけなので、オブジェクトに対して !gcroot を呼び出して、そうでなければ容疑者を調べることができます。

私は、Windbg が Windows プラットフォーム用の非常に強力なデバッガーであることを認識しており、時々それについて新しいことを学びます。仲間の Windbg ユーザーは、彼らのマッド スキルの一部を共有できますか?

ps: 気の利いたコマンドを探しているわけではありません。これらはドキュメントに記載されています。Windbg を使用すると想像もつかないことを行うためのヒントを共有してみませんか? たとえば、windbg の下でプロセスが実行されているときにメモリ割り当てに関する統計を生成する方法。