11

リリース用のソリューションを構築していますが、Studio 2010 Professional を使用してアタッチしようとすると、スレッドがスタック情報を表示せず、ブレークポイントを設定できません。

目標は、実行中のプロセスに Visual Studio/JIT Debugger をアタッチできるようにすると同時に、最適化の利点をできるだけ多く実現することです。

私たちの検索のほとんどは「debug:full でコンパイルする」という結果になり、デバッグできるようになりますが、そうではないようです。JIT は実行時にコードを最適化するため、デバッグできないと思います。これは本当ですか？最適化を軽視してデバッグを許可するようにコンパイルして JIT に指示することは可能ですか? (他の最適化を保持しながら)

アップデート

@HansPassantの回答を使用して、モジュールを調べたところ、pdbはバイナリと同じディレクトリにありますが、実際にはデバッグシンボルがロードされていませんでした。私が見たのは、ライブラリが「ユーザーコード」-「いいえ」としてマークされていることです。これはおそらく、自動的にロードされなかった理由です。シンボルを手動でロードし、「just-my-code」を無効にすることで、ブレークポイントを設定してスタックを表示することもできました。

今すぐ質問: コードがユーザー コードとしてマークされていないのはなぜですか? これは正常な動作ですか？これを回避するために、何らかの方法でこれをアセンブリに構成できますか?

4

2 に答える 2

18

最適化されたコードをデバッグすることは、大きな喜びではありません。確かに、ブレークポイントの設定に問題がある可能性があります。メソッドがインライン化されている可能性があります。また、変数が cpu レジスタに格納されるように最適化されている場合、ローカル変数とメソッド引数を検査すると、デバッガが不機嫌になる傾向があります。

ただし、コール スタックを調べることはできますが、インライン化されなかったメソッドがスタック トレースに表示されます。犯しがちな基本的な間違い:

  • デバッガーをアタッチすると、デバッガーの種類を選択するオプションが表示されます。必ず「管理対象」を選択してください。ネイティブ デバッガーはあまり使用されません。
  • 正しいスレッドを見ていることを確認してください。プログラムは任意の場所で壊れる可能性があります。Debug + Windows + Threads を使用して適切なスレッドを選択します
  • コード内のどこかで実際に壊れていることを確認してください。Windows オペレーティング システムの DLL やフレームワーク メソッドの内部にたどり着くのは簡単です。[ツール] + [オプション]、[デバッグ]、[シンボル] を選択し、シンボル サーバーを有効にして、Windows 内で開始されるスタック トレースが正確になるようにします。
  • デバッガーは PDB ファイルを見つけられる必要があります。Debug + Windows + Modules を使用すると、プロセスで読み込まれたアセンブリが表示されます。まず、デバッグしたいものが実際にロードされていることを確認してください。それを右クリックして、「シンボルロード情報」を選択します。PDBファイルを探した場所が表示されます
  • 「自分のコードのみ」オプションは非常に邪魔になる可能性があり、自分のものではないコードのかなりの部分に遭遇する可能性が非常に高くなります。ツール+オプション、デバッグ、一般をクリックして、そのオプションをオフにします。
于 2013-07-16T12:59:43.640 に答える