DLL(リリースモードでビルドされた)と対応するPDBファイルがある場合、そのDLLに含まれるクラス/メソッドをデバッグ(ステップイン)することは可能ですか?
もしそうなら、必要なステップ/構成は何ですか(例えば、PDBファイルをどこに置くか)?
編集:
PDBファイルがDLL(単純なコンソールテストアプリケーションのbin/debugディレクトリ内)と同じ場所にある場合、DLLがロードされます([出力]ウィンドウと[モジュール]ウィンドウにも)が、それでもそのDLLのメソッドにステップインできません。
これはコンパイラの最適化の結果でしょうか(Michaelが彼の回答で説明したように)?
私はついに、リリース構成に組み込まれているDLL)のデバッグで問題が発生する原因を見つけました。
まず第一に、それは基本的に期待通りに動作します。つまり、DLL組み込みのrelease-configurationと対応するPDBファイルがある場合、そのDLLに含まれるクラス/メソッドをデバッグできます。
私が最初にこれを試したとき、残念ながら、DebuggerStepThroughAttributeを持つクラスのメソッドにステップインしようとしました。例:
[System.Diagnostics.DebuggerStepThrough]
public class MyClass {
public void Test() { ... }
}
その場合、もちろんデバッガーからメソッドにステップインすることはできません(期待どおり/意図したとおり)。
したがって、すべてが意図したとおりに機能します。ご回答ありがとうございます。
Pdbは通常(少なくとも私にとっては)dllの隣にある場合に検出されます(intellisense xmlファイルの場合と同様)。
あるいは;モジュールがロードされた後、ブレークポイントが必要になります...
ブレークポイントで、「モジュール」ウィンドウを表示します(Ctrl + D、M-またはデバッグ->ウィンドウ->モジュール)。 dllの「Loadsymbolsfrom」、「Symbolpath」などを右クリックします。
通常、リリースビルドのデバッグは、デバッグバージョンのデバッグよりもはるかに困難です。一般に、x86アセンブラーについてある程度理解している必要があり、逆アセンブリウィンドウを確認するのに時間がかかる可能性があります。コンパイラを最適化したリリースビルドでは、大幅なインライン化と命令の並べ替えが行われる可能性があるため、これが実際に使用しているコード行を把握する唯一の方法になる傾向があります。さらに、デバッガーが変数の値を正しく報告できないことがよくあります。変数の値を知る必要があり、デバッガーが正しいかどうかわからない場合は、逆アセンブリウィンドウに移動して、メモリの場所を見つけるか、その場所にあるレジスタを登録します。
PdbファイルはSymbolServerに保存できます。良いチュートリアルについては Symbol Serverのセットアップ をチェックしてください。ビルドマシンでビルドするすべての製品はシンボルをシンボルサーバーに公開するため、WinQualから受け取ったクラッシュダンプをいつでもデバッグできます。