問題タブ [pdb-files]

アプリケーションがクラッシュし、その結果、Windows プラットフォームでクラッシュ ダンプが生成されます。exeとdllファイルをお客様に送ります。顧客から user.dmp と drwtsn32.log ファイルが送られてきました。しかし、顧客は対応する pdb ファイルを持っていません。顧客は dll と exe ファイルを持っているだけです。そのため、この user.dmp ファイルを Windbg に添付すると、シンボルが取得されません。では、シンボルを取得するにはどうすればよいでしょうか。pdb ファイルを顧客に送信する必要がありますか? はいの場合、クラッシュが発生したときにこれらの pdb ファイルをどうする必要がありますか? 私は 3 つの異なるマシンを使用します: a) ビルド マシン、c) 顧客のテスト マシン、c) 私自身のデバッグ マシン (ビルド マシンとは異なります)。デバッグ用マシンにwindbgをインストールします。すべての pdb ファイルをビルド マシンからデバッグ マシンにコピーできます。私にお知らせください、

ありがとうコンコン

.NETアプリケーションでデバッグ情報（pdb）が生成され、実行時にアプリケーションの速度が低下しますか？それとも、アプリケーションがクラッシュしたときにのみ機能しますか？

私たちの夜間のビルド プロセスは、対応する画像ファイルとは数時間異なる PDB ファイルを生成するなど、長い間機能していませんでした。その後、問題を修正しました。

ただし、シンボル サーバーの使用を開始したいのですが、これらの年齢が一致しない pdb ファイルを使用する必要があるため、使用できません。この問題を回避するには、windbg で .symopt +0x40 メソッドを使用します。つまり、すべての pdb ファイルを手作業で整理する必要があり、何年にもわたるリリースの後、それが積み重なっていきます。

windbg が pdb の経過時間をマークするために使用するメカニズムを変更し、強制的にイメージ ファイルと一致させる方法を探しています。ユーティリティChkMatchは同様のことを行いますが、pdb 署名用です。開発者はページで「ChkMatch は、実行可能ファイルと PDB ファイルの署名が異なるが同じ年齢である場合、それらを一致させることができます (PDB 署名と年齢の詳細については、この記事を参照してください)。年齢が異なる場合、ツールは作成できません。ファイルが一致します。」

hexeditor の内部を調べたところ、年齢に対応するビットのように見えるものさえ見つかりましたが、動作させることができなかったので、内部でさらにいくつかのトリックを引き出す必要があります。

何か案は？

編集:これが役立つかどうかはわかりませんが、私の特定のケースでは、PDBファイルも再作成する不要なdllの再リンクによって年齢差が発生しました。ただし、ビルド プロセスでは、元の dll (再リンク前) と再リンク後の pdb が格納されていました。そういう状況をどうにか手で再現しようと思いました。つまり、DLL の再リンクを強制しますが、どちらの場合も pdb を保存します。次に、2 つのファイルのバイナリ比較を実行して、それらがどのように変更されたかを確認できます。おそらく、これを自動的に行う何らかのパッチソフトウェアを実行しますか? コントロール ケースで正確に何が変更されたかを確認することで、会社のビルド プロセスで保存された DLL と PDB に同じことを行うことができるでしょうか?

編集：私はそれを理解しました!!!! 最初の回答に対するコメントの 1 つを参考に、「文書化されていない Windows 2000 の秘密: プログラマーズ クックブック」という書籍の PDF へのリンクを調べました。また、著者は pdb ファイル形式について詳しく説明しています。前に言ったように、私はすでに pdb を 16 進エディタにロードしており、年齢と署名を一致させたように見えるようにいくつかのビットをひっくり返しましたが、うまくいきませんでした。さて、W2k secrets book のユーティリティを使用して pdb を含まれているストリームに「爆発」させた後、ストリーム 3 に age への別の参照が隠されていることがわかりました!!!!!!!! それもひっくり返したら、windbgで一致しました。これは巨大です!!!! どうもありがとう....シンボル サーバー HERE I COME!

DLL（リリースモードでビルドされた）と対応するPDBファイルがある場合、そのDLLに含まれるクラス/メソッドをデバッグ（ステップイン）することは可能ですか？

その場合、必要な手順/構成（PDBファイルを配置する場所など）は何ですか？

編集：

DLLと同じ場所（単純なコンソールテストアプリケーションのbin / debugディレクトリ）にPDBファイルがある場合。DLLのシンボルが（[出力]ウィンドウと[モジュール]ウィンドウに）ロードされていることはわかりますが、それでもそのDLLのメソッドにステップインすることはできません。

これはコンパイラの最適化の結果でしょうか（Michaelが彼の回答で説明したように）？

-g オプションを使用してデバッグ シンボルを生成できることはわかっています。ただし、シンボルはターゲット ファイルに埋め込まれます。gcc は、結果の実行可能ファイル/ライブラリの外でデバッグ シンボルを生成できますか? Windows VC++ コンパイラの .pdb ファイルのように。

.NET PDB ファイルを実サーバーに保持する際にセキュリティ上の問題はありますか?

例外のスローにはもう少し時間がかかることはわかっていますが、通常の実行中に誰が例外をスローするのでしょうか? :-)

しかし、セキュリティの観点からは？問題はありますか？

デバッガー (または CLR 例外ハンドラー) は、pdb を使用してリリース モードで例外が発生した行を表示できますか?

リリース モードのコードは最適化されており、「元の」コードの順序とロジックに常に従うとは限りません。

また、リリース モードであっても、デバッガーがコードを 1 ステップずつナビゲートできることも驚くべきことです。最適化により、ナビゲーションが非常に不快になります。

その2点を明確にしていただけますか？

従来のwin32exe/ dllファイルからコード（データではありません！）を抽出する必要があります。コードセグメントのコンテンツを抽出するだけではこれを実行できないことは明らかです（コードセグメントにはデータ（ジャンプテーブルなど）も含まれているため）。コンパイラの助けが必要です。

* .mapファイルは素晴らしいですが、関数のアドレスしか含まれていません。つまり、私ができる最も安全な方法は、そのアドレスから開始し、最初のリターン/ジャンプ命令まで処理することです（関数の一部にデータが記載されている可能性があるため）

* .pdbファイルの方が優れていますが、このような情報を抽出するためにどのツールを使用すればよいかわかりません-DbgHelpとDIA SDKを調べました。後者は適切なツールのようですが、あまり単純ではありません。 。だから私の質問/質問：

1. ご存知のように、コード/データの位置（アドレス+長さ）に関する情報は、DbgHelpを介してのみ抽出できますか？
2. DIA SDKが唯一の方法である場合、そのような情報を取得するために何を呼び出す必要がありますか？（COMのものはかなり重いです）
3. 他に方法はありますか？

もちろん、私の懸念は、そもそもVisual Studio、C /C++ソースのコンパイルに関するものです。

ヒントをありがとう。

WindowsVS2005のデバッグでコンパイルされたC++アプリケーションの.pdbプログラムデータベースがあります。DIA SDKを使用して関数名を検索しましたが、シンボルのファイル名を取得できないようです。

オンにする必要のあるスイッチはありますか？これは機能しますか？！