詳細情報を含むより良いPDBファイルを生成するために知っておくべきVC++設定はありますか？リリースビルドでのPDB解析の改善のための推奨VC++設定
私はプロジェクトcrashrptをもとの場所でクラッシュダンプ解析システムを持っています。 \、私の開発マシンは、Cのソースコードを持っています：
また、私の生産ビルドサーバーはDにインストールされているソースコードを持っている\。 VC++の設定でソースパスを入力しましたが、クラッシュの呼び出しスタックを調べると、自動的にソースコードにジャンプしません。私は私の開発マシンのソースコードがD：\にあればそれはうまくいくと思います。
あなたはDにソースコードのディレクトリを割り当てるには、MS-DOS substコマンドを使用しようとする可能性があなたはフレームポインタをオフにしていることを確認し、「私が知っておくべきすべてのVC++の設定があります」検査。 Larry ostermanさんのブログにfpoに関するthe historical detailsとデバッグで発生する問題があります。
シンボルが正常にロードされました。コールスタックが表示されますが、項目をダブルクリックしてもソースコードには移動しません。
使用しているVSのバージョンは何ですか？ （または、あなたはWindbgを使っていますか？）... VSでは、場所を見つけることができなければ、初めてソースを求めるプロンプトが表示されます。しかし、それはまた、 '見つからなかった'ソースのリストを保持しているので、毎回あなたにそれを尋ねることはありません。表示されないリストは痛みです...プロンプトを戻すには、ソリューションエクスプローラ/ソリューションノード/プロパティ/デバッグプロパティにアクセスし、下のペインでファイルリストを編集する必要があります。
最後に、「ストリップされたシンボル」を使用している可能性があります。これらは、FPOを過ぎてコールスタックを歩くためのデバッグ情報を提供するために生成されたpdbファイルですが、（他のデータとともに）ソースの場所が取り除かれています。 Windows OSコンポーネントのパブリック・シンボルは、pdbsを削除したものです。あなた自身のコードでは、これらは単に痛みの原因となり、あなたがpdbsを外部に提供していない限り、価値がありません。あなたはこれらのひどい破棄されたpdbsのどれを持っていますか？ "binplace"を-aコマンドで使用すると、それらを持っている可能性があります。
幸運を祈る！適切なミニダンプストーリーは、プロダクションデバッグのための神です。
：ドライブ。誰もが興味を持っている場合は
は、同僚は、電子メールを介して私にはこの質問に答えた：
アルテム書いた：
より良いクラッシュを行うことができますMiniDumpWriteDump（） へのフラグがあります が コールスタックに関しては、私はあなたが（おそらくいくつかを）回していない限り、彼らがために最適化のより良い ... することができ疑うなど、完全なプログラムの状態を見て optimizatioをすべてのグローバル変数と を許可することをダンプns off。
また、インライン の機能を無効にして、全体のプログラム の最適化がかなり助けになると思います。
実際には、多くのダンプの種類があり、 多分あなたは十分に一つの小さな を選ぶことができるが、これらのタイプは、しかし、コールスタック に役立つことはありません、まだ http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
の詳細情報を持つことは、彼らは唯一の量に影響を与えます表示される変数は です。
私たちが使用しているdbghelp.dll バージョン5.1では、 はサポートされていません。 MSデバッグツール - 最新版 dbghelp.dllはまだ に再配布されています。
Visual Studioは、ソースファイルへのパスの入力を要求されていますか？そうでなければ、それはコールスタックのためのシンボルを持っているとは思わない。ソースパスを設定すると、元の場所を正確にマッピングする必要がなくなります。
シンボルが読み込まれているかどうかは、Visual Studioの[モジュール]ウィンドウで確認できます。あなたはPDBを構築していると仮定すると、
その後、私は直接PDBの情報量をコントロールするいずれかのオプションがあるとは思いません。コンパイラによって実行される最適化のタイプを変更してデバッグ性を向上させることはできますが、パフォーマンスが低下します。同僚が指摘するように、インラインを無効にするとクラッシュファイルが明瞭になりますが、
私は、彼らが大きくされている可能な場合は、完全なダンプファイルでの作業をお勧めしますが、あなたのプロセスに関するすべての情報を与える...と頻度、それはとにかくクラッシュん:)
でしょう、あなたのアプリケーションの性質に応じて、ソースファイルへのパスが であることをVisual Studioから確認していますか？
号
そうでない場合は、それはそれは、コールスタックのシンボル を持っているとは思いません。ソース のパスを設定すると、元の正確な場所である をマップする必要はありません。
シンボルが正常にロードされました。コールスタックが表示されますが、項目をダブルクリックしてもソースコードには移動しません。私は、問題の行のためのファイルで、コース検索のことができますが、これは大変な作業です:)
あなたのソースコード管理システムから直接ビルドする場合、pdbファイルにファイルの原点を注釈付けする必要があります。これにより、デバッグ中に正確なソースファイルを自動的に取得できます。 （これは.Netフレームワークのソースコードを取得するために使用されるものと同じです）。
詳細については、http://msdn.microsoft.com/en-us/magazine/cc163563.aspxを参照してください。 SCMとしてSubversionを使用する場合は、SourceServerSharpプロジェクトをチェックアウトすることができます。
これは私があなたに似たいくつかのトラブルの後に使用された手順です：
a）に建設されたすべてのEXE & DLLファイル、その同じディレクトリにPDBに対応して、それぞれが、開始本番サーバーにコピーシステムを起動し、クラッシュが発生するのを待っていました。
b）すべてのEXE、DLL & PDBファイルを（同じフォルダ内の）ミニダンプとともに開発マシン（一時フォルダ）にコピーします。 Visual Studioを使用して、そのフォルダからミニダンプをロードします。
VSはソースファイルが最初にコンパイルされた場所を見つけたので、常にそれらを識別して正しく読み込むことができました。あなたと同じように、プロダクションマシンで使用されたドライブはC：ではなく、開発マシンで使用されていました。
つ以上のヒント：
私がやったことの一つは、多くの場合、EXE/DLLの再構築をコピーし、新しいPDBをコピーし忘れていました。これは、デバッグサイクルを台無しにし、VSは私にコールスタックを表示することはできません。
時々、VSで意味をなさないコールスタックを取得しました。いくつかの頭痛の後、私はwindbgは常に私に正しいスタックを表示することが分かったが、VSはしばしばしないだろう。理由を知らない。