4

これまで、ASP.NET MVC のデバッグには常に ASP.NET MVC フレームワーク ソースを使用してきました。私のラップトップでは、デバッグ中にVSで「モジュール」ウィンドウを表示し、System.Web.Mvcを右クリックしてから、「シンボルの読み込み」>「Microsoftシンボルサーバー」を選択するという別のアプローチを試しました。

System.Web.Mvc アセンブリのシンボル ファイルが読み込まれたと報告されたため、VS は実際に何かを読み込んだように見えました。また、コール スタックの System.Web.Mvc に属するすべての行がグレーから黒に変わりました。ただし、System.Web.Mvc に属するコードにステップインしようとすると、「ソース コードが利用できません」というエラー メッセージが表示されます。

そのため、シンボルをロードしましたが、まだソース コードはありません。古い方法でデバッグできるので、大きな問題ではありません。しかし、Microsoft Symbol Server は何に役立つのでしょうか?

4

3 に答える 3

4

これにより、スタック トレースがネイティブ DLL に対して適切に機能するようになります。シンボルがないと、スタック トレースは多くの場合、最も近い Windows DLL までしか到達せず、その後停止します。シンボルを使用すると、Winodws DLL を介して続行されます。関数名は表示されますが、ソース コードは表示されません (明らかに)。

ネイティブ Windows プログラムをデバッグすると、次のようなスタック トレースが表示されることがよくあります。

  mydll.dll
  mydll.dll
  some_windows_dll.dll
  some_windows_dll.dll
  some_other_windows_dll.dll
  some_other_windows_dll.dll
  myexe.exe
  myexe.exe

Windows DLL のシンボルがなければ、スタックはここまでしか取得できないことがわかります。

  mydll.dll
  mydll.dll
  some_windows_dll.dll

最初から最後まで見ることはできません。

于 2009-05-06T10:24:39.540 に答える
2

私の経験では、シンボルサーバーは、必要な詳細を提供するため、マネージドデバッグとアンマネージドデバッグの両方に役立ちます。他の人は、これがネイティブコードにとって重要である理由をすでに説明しているので、マネージコードに固執します。

私はWinDbg+Sosを使用してマネージコードのデバッグをかなり行っており、定期的にネイティブ部分を掘り下げる必要があります。OSにとって、管理対象アプリケーションは非管理対象アプリケーションと同じであることに注意してください。最終的に、管理対象アプリケーションはWin32dllを呼び出します。それらを検査するには、適切な記号が必要です。

たとえば、特定のマネージドコールの詳細を確認する必要がある場合は、実際にネイティブコードを確認する必要があります。1つの例はMonitor.Enter、管理対象スタックに表示される場合です。呼び出しが発行されたばかりなのか、スレッドが実際に待機しているのか（*）は、呼び出し自体を見てもわかりません。ネイティブの呼び出しスタックをダンプすることで、WaitForMultipleObjectsへの呼び出しが発行されたかどうかを確認できます。

（*）!threadsコマンドの状態フラグはここで役立ちますが、詳細が必要な場合は、ネイティブスタックのダンプが非常に役立ちます。

于 2009-05-06T11:12:05.430 に答える
1

シンボル サーバーがマネージド DLL に役立つとは思いませんでした。シンボル サーバーがなくても、マネージド スタック トレースを取得できます。管理シンボルの主な値は行番号情報だと思いますが、それをどうするつもりですか?

しかし、ネイティブ コードをデバッグするためのシンボルなしでは生きられませんでした。ソースサーバーは非常に便利です。

于 2009-05-06T10:37:41.800 に答える