アプリから送信されたいくつかのクラッシュ ダンプを調べるために、windbg を使用しています。私が目にしているクラッシュと、特定のサード パーティの DLL がプロセスに読み込まれていることとの間には、何らかの相関関係があるようです (不安定な Winsock LSP だと思います)。将来この種の分析を容易にするために、Microsoft 以外のモジュールのリストを表示するだけの windbg スクリプトはありますか? これにより、クラッシュ間のパターンがより明確になります。私は "lm D sm" を使っていますが、今手動でリストを調べるのは面倒です。
ありがとう！
シンボル パスを Microsoft のシンボル サーバーに設定して (および MS シンボルのみをロードして)、"lm e" を使用してみてください。これにより、WinDbg は、ロードされていないモジュールを含む、あらゆる種類のシンボル「問題」を含むすべてのモジュールのリストを表示します。
これを機能させるための鍵は次のとおりです。
そこから、「lm」の他のオプションを追加して、フルパスなどの情報を取得できます。
cdb を使用してデバッガーのスクリプトを作成すると、stdout に出力されます - クラッシュ ダンプを開き、ロードされたモジュールのリストを出力してから終了します。その後、お気に入りのテキスト操作ツールを使用できます (ヒント: その名前は Perl です ;) )リストを検索します。
編集: 追加情報を追加するために、cdb は WinDbg のコマンドライン バージョンです。どちらも同じエンジンを使用していますが、フロントエンドが異なるだけです。
これを行う方法は、Windows インストール用デバッグ ツールの CLR10 ディレクトリからsos.dllを実行することです。
.load clr10\sos
!sam c:\temp\modules
Windows エクスプローラーでディレクトリ c:\temp\modules を開きます。ヘッダー列を右クリックして、会社の列を追加します。次に、会社を分類し、「Microsoft Corporation」の会社の DLL を「Microsoft」という別のサブディレクトリに移動します。
ディレクトリに残っている DLL は、通常、サード パーティまたはカスタム開発されたコードです。
ありがとう、アーロン
少し前に、この問題を正確に解決するための小さなコマンドライン アプリを作成しました。