より多くの情報を含むより良いPDBファイルを生成するために知っておくべきVC++設定はありますか？
プロジェクトcrashrptに基づいたクラッシュダンプ分析システムがあります。
また、本番ビルドサーバーのソースコードはD：\にインストールされていますが、開発マシンのソースコードはC：\にあります。VC ++設定にソースパスを入力しましたが、クラッシュのコールスタックを調べても、ソースコードに自動的にジャンプしません。開発マシンのソースコードがD：\にあれば、うまくいくと思います。
2942 次
7 に答える
5
「知っておくべきVC++設定はありますか？」
フレームポインタの省略を必ずオフにしてください。Larry ostermanのブログには、 fpoとそれがデバッグで引き起こす問題に関する歴史的な詳細があります。
シンボルが正常にロードされました。コールスタックが表示されますが、エントリをダブルクリックしてもソースコードが表示されません。
使用しているVSのバージョンは何ですか？（またはWindbgを使用していますか？）... VSでは、場所が見つからない場合、最初にソースの入力を明確に要求する必要があります。ただし、「見つからなかった」ソースのリストも保持されるため、毎回要求されることはありません。見ないリストが面倒な場合があります...プロンプトを元に戻すには、ソリューションエクスプローラー/ソリューションノード/プロパティ/デバッグプロパティに移動し、下部ペインのファイルリストを編集する必要があります。
最後に、「ストリップされたシンボル」を使用している可能性があります。これらは、FPOを通過するコールスタックをウォークするためのデバッグ情報を提供するために生成されたpdbファイルですが、ソースの場所は（他のデータとともに）削除されています。Windows OSコンポーネントのパブリックシンボルは、削除されたpdbです。あなた自身のコードの場合、これらは単に苦痛を引き起こし、外部にpdbを提供しない限り、それだけの価値はありません。これらの恐ろしいストリップされたpdbの1つをどのように持っていますか？-aコマンドで「binplace」を使用すると、それらが存在する可能性があります。
幸運を！適切なミニダンプストーリーは、本番デバッグの天の恵みです。
于 2008-09-01T21:41:59.600 に答える
2
ソースコード管理システムから直接ビルドする場合は、pdb ファイルにファイルのオリジンで注釈を付ける必要があります。これにより、デバッグ中に正確なソース ファイルを自動的に取得できます。(これは、.Net フレームワークのソースコードを取得するために使用されるのと同じプロセスです)。
詳細については、 http://msdn.microsoft.com/en-us/magazine/cc163563.aspxを参照してください。Subversion を SCM として使用している場合は、SourceServerSharp プロジェクトを確認できます。
于 2008-10-19T00:35:55.330 に答える
1
これは、あなたと同様の問題が発生した後に使用した手順です。
a）ビルドされたすべてのEXEファイルとDLLファイルを本番サーバーにコピーし、それぞれに対応するPDBを同じディレクトリに配置してシステムを起動し、クラッシュが発生するのを待ちました。
b）すべてのEXE、DLL、およびPDBファイルをミニダンプ（同じフォルダー内）とともに開発マシン（一時フォルダー）にコピーバックしました。Visual Studioを使用して、そのフォルダーからミニダンプをロードしました。
VSは、最初にコンパイルされたソースファイルを見つけたため、常にそれらを識別して正しくロードすることができました。あなたと同じように、本番マシンでは使用されたドライブはC：ではありませんでしたが、開発マシンではそうでした。
さらに2つのヒント：
私がよく行ったことの1つは、再構築されたEXE / DLLをコピーし、新しいPDBをコピーするのを忘れることでした。これによりデバッグサイクルが台無しになり、VSはコールスタックを表示できなくなります。
時々、VSでは意味をなさないコールスタックを取得しました。いくつかの頭痛の種の後、私はwindbgが常に正しいスタックを表示することを発見しましたが、VSはしばしば表示しませんでした。理由はわかりません。
于 2008-10-19T01:36:01.013 に答える
1
MS-DOS substコマンドを使用して、ソースコードディレクトリをD：ドライブに割り当てることができます。
于 2008-08-30T17:02:35.183 に答える
0
誰かが興味を持っている場合は、同僚がこの質問に電子メールで返信しました。
Artemは書いた：
MiniDumpWriteDump（）には、すべてのグローバル変数などを含む完全なプログラム状態を確認できるクラッシュダンプを改善できるフラグがあります。呼び出しスタックに関しては、最適化のために改善できるとは思えません...多分いくつかの）最適化をオフにします。
また、インライン関数とプログラム全体の最適化を無効にすることは非常に役立つと思います。
実際、多くのダンプタイプがあります。おそらく、十分に小さいものを選択できますが、それでも詳細情報があります http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
ただし、これらのタイプはコールスタックには役立ちませんが、表示できる変数の量にのみ影響します。
これらのダンプタイプの一部は、使用しているdbghelp.dllバージョン5.1ではサポートされていないことに気付きました。最新の6.9バージョンに更新することもできますが、MSデバッグツールのEULAを確認しました。最新のdbghelp.dllは引き続き再配布できます。
于 2008-08-30T17:24:48.733 に答える
0
Visual Studioはソースファイルへのパスの入力を求めていますか？そうでない場合は、コールスタックのシンボルがないと見なされます。ソースパスの設定は、正確な元の場所をマップしなくても機能するはずです。
Visual Studioの[モジュール]ウィンドウを見ると、シンボルが読み込まれているかどうかがわかります。
PDBを構築していると仮定すると、PDB内の情報量を直接制御するオプションはないと思います。コンパイラによって実行される最適化のタイプを変更してデバッグ能力を向上させることができますが、これにはパフォーマンスが低下します。同僚が指摘しているように、インラインを無効にすると、クラッシュファイルで物事がより明確になりますが、実行時にコストがかかります。
アプリケーションの性質に応じて、可能であればフルダンプファイルを使用することをお勧めします。ファイルは大きくなりますが、プロセスに関するすべての情報が提供されます...そしてとにかくクラッシュする頻度はどれくらいですか:)
于 2008-08-30T17:34:25.030 に答える
0
Visual Studio はソース ファイルへのパスを要求していますか?
いいえ。
そうでない場合は、コールスタックのシンボルがあるとは見なされません。ソース パスの設定は、正確な元の場所をマッピングしなくても機能するはずです。
シンボルが正常に読み込まれました。コールスタックが表示されますが、エントリをダブルクリックしてもソース コードに移動しません。もちろん、問題の行をファイルで検索できますが、これは大変な作業です:)
于 2008-08-30T17:49:23.980 に答える