リリース ビルドでの PDB 分析を向上させるための推奨 VC++ 設定
https://stackoverflow.com/questions/36127
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
より多くの情報を含むより適切な PDB ファイルを生成するために知っておくべき VC++ 設定はありますか?
プロジェクトに基づいてクラッシュ ダンプ分析システムを導入しています クラッシュ.
また、運用ビルド サーバーのソース コードは D:\ にインストールされていますが、開発マシンのソース コードは C:\ にあります。VC++ 設定にソース パスを入力しましたが、クラッシュのコール スタックを調べても、ソース コードに自動的にジャンプしません。開発マシンのソース コードが D:\ にあれば動作すると思います。
解決
「知っておくべきVC++設定はありますか？」
フレーム ポインターの省略を必ずオフにしてください。ラリー・オスターマンのブログには、 歴史的な詳細 fpo とそれがデバッグで引き起こす問題について。
シンボルは正常にロードされました。コールスタックが表示されますが、エントリをダブルクリックしてもソース コードは表示されません。
VS のどのバージョンを使用していますか?(それとも Windbg を使用していますか?) ...VS では、場所が見つからない場合、最初にソースの入力を求めるプロンプトが表示されるはずです。ただし、「見つからなかった」ソースのリストも保持されるため、毎回リストを要求される必要はありません。時々、「見てはいけないリスト」が面倒になることがあります...プロンプトを元に戻すには、ソリューション エクスプローラー/ソリューション ノード/プロパティ/デバッグ プロパティに移動し、下部ペインのファイル リストを編集する必要があります。
最後に、「除去されたシンボル」を使用している可能性があります。これらは、コールスタックを FPO を通過して実行するためのデバッグ情報を提供するために生成された pdb ファイルですが、ソースの場所は (他のデータとともに) 取り除かれています。Windows OS コンポーネントのパブリック シンボルは、ストリップされた pdb です。独自のコードの場合、これらは単に苦痛を引き起こすだけであり、pdb を外部に提供しない限り、価値はありません。このようなひどいストリップされた PDB をどうやって手に入れるでしょうか?-a コマンドで「binplace」を使用すると、それらを取得できる可能性があります。
幸運を！適切なミニダンプストーリーは、実稼働環境のデバッグにとって天の恵みです。
他のヒント
ソースコード管理システムから直接ビルドする場合は、pdb ファイルにファイルの起源の注釈を付ける必要があります。これにより、デバッグ中に正確なソース ファイルを自動的に取得できます。(これは、.Net フレームワークのソースコードを取得するために使用されるのと同じ手順です)。
見る http://msdn.microsoft.com/en-us/magazine/cc163563.aspx 詳細については。SCM として Subversion を使用している場合は、SourceServerSharp プロジェクトをチェックアウトできます。
MS-DOSを使ってみてはいかがでしょうか サブサブ コマンドを使用して、ソース コード ディレクトリを D: に割り当てます。ドライブ。
これは、あなたと同じような問題が発生した後に私が使用した手順です。
a) 構築されたすべての EXE および DLL ファイルを実稼働サーバーにコピーし、それぞれに対応する PDB を同じディレクトリにコピーし、システムを起動し、クラッシュが発生するのを待ちました。
b) すべての EXE、DLL、および PDB ファイルを、ミニダンプ (同じフォルダー内) とともに開発マシン (一時フォルダー) にコピーして戻します。Visual Studio を使用して、そのフォルダーからミニダンプをロードしました。
VS は、最初にコンパイルされた場所でソース ファイルを見つけたので、常にそれらを識別して正しくロードすることができました。あなたと同じように、本番マシンでは使用されたドライブは C: ではありませんでしたが、開発マシンでは C: が使用されていました。
さらに 2 つのヒント:
私がよくやったことの 1 つは、再構築された EXE/DLL をコピーし、新しい PDB をコピーするのを忘れることでした。これによりデバッグ サイクルが台無しになり、VS はコール スタックを表示できなくなりました。
時々、VS で意味をなさないコールスタックが発生することがありました。少し頭を悩ませた後、windbg では常に正しいスタックが表示されるが、VS では表示されないことが多いことがわかりました。理由はわかりません。
興味のある方のために付け加えておきますが、同僚がこの質問に電子メールで返信してくれました。
アルテムはこう書いています。
MinidumpWritedump（）には、完全なプログラム状態、すべてのグローバル変数などを見ることができるより良いクラッシュダンプを行うことができるフラグがあります。コールスタックに関しては、最適化のためにそれらがより良くなる可能性があると思います...最適化をオフにしない限り。
また、インライン関数とプログラム全体の最適化を無効にすることは非常に役立つと思います。
実際、多くのダンプタイプがあります。たぶん、十分な小さいものを選択できますが、まだより多くの情報を持っています http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
これらのタイプはコールスタックに役立ちませんが、表示できる変数の量にのみ影響します。
これらのダンプタイプのいくつかは、使用しているdbghelp.dllバージョン5.1でサポートされていないことに気付きました。しかし、最新の6.9バージョンに更新できますが、MSデバッグツールについてEULAをチェックしました。
Visual Studio はソース ファイルへのパスの入力を求めていますか?そうでない場合は、コールスタックのシンボルがあるとは考えられません。ソース パスの設定は、正確な元の場所をマップしなくても機能するはずです。
Visual Studio の「モジュール」ウィンドウを見ると、シンボルが読み込まれているかどうかを確認できます。
PDB を構築していると仮定すると、PDB 内の情報量を直接制御するオプションはないと思います。デバッグ性を向上させるためにコンパイラによって実行される最適化の種類を変更することもできますが、これによりパフォーマンスが低下します。同僚が指摘するように、インラインを無効にするとクラッシュ ファイル内での内容がより明確になりますが、実行時にはコストがかかります。
アプリケーションの性質にもよりますが、可能であれば完全なダンプ ファイルを使用して作業することをお勧めします。ファイルのサイズは大きくなりますが、プロセスに関するすべての情報が得られます。とにかくどのくらいの頻度でクラッシュしますか:)
Visual Studioは、ソースファイルへのパスを求めていますか？
いいえ。
そうでない場合は、CallStackのシンボルがあるとは思わない。ソースパスの設定は、正確な元の場所をマップすることなく動作する必要があります。
シンボルは正常にロードされました。コールスタックが表示されますが、エントリをダブルクリックしてもソース コードは表示されません。もちろんファイル内で問題の行を検索することもできますが、これは大変な作業です:)
