非常に大規模な ASP.NET アプリケーションでメモリ リークの可能性を追跡しようとしています。このツールをライブ環境で使用する前に、WinDBG に慣れようとしています。
http://humblecoder.co.uk/uncategorized/spotting-a-memory-leak-with-windbg-in-netという非常に役立つ記事の指示に従いました。ASP.NET プロセスの「メモリ ダンプ」ファイルを作成し、記事で指定されているようにデリゲートがメモリ リークを引き起こしていることを示すことができました。この記事の「次は記号が必要です」という段落を参照します。File\Symbol File Path を使用してシンボル ファイルを追加しませんでした。WinDBG で実行しても、アプリケーションをデバッグして記事の残りの手順を実行できるようです。ASP.NET アプリケーションではシンボル パスは不要ですか?
.NETアセンブリには、すべてのメソッドの名前とそのパラメーターを含むメタデータが含まれているため、管理対象スレッドの読み取り可能なスタックトレースを取得するためにシンボルは必要ありません。
シンボルが提供できることの1つは、各ステートメントのファイル名と行番号です。これにより、スタックトレースのどのフレームが、ソースコードのどの行に対応しているかをより簡単に把握できます。
Michael が言うように、ほとんどの関連情報は実行時にメタデータとして利用できるため、マネージ コードにシンボルは厳密には必要ありませんが、ネイティブ コードを掘り下げている場合は、シンボルがあると非常に便利です。
.symfix多くのシナリオでは、WinDbg に Microsoft のパブリック シンボル サーバーを使用するように指示するだけで済みます。これにより、コード内のすべての CLR および Win32 固有の呼び出しのシンボルにアクセスできるようになります。.reloadパスを設定する場合は忘れずに実行してください。
コードに Microsoft 以外のネイティブ アセンブリも含まれている場合は、対応する PDB ファイルの場所をシンボル パスに追加する必要があります。.sympathそのためにコマンドを使用します。
シンボルの読み込みをトラブルシューティングするには、!sym noisyコマンドを使用します。
詳細については、こちらを参照してください。