Для чего полезны общедоступные серверы символов Microsoft?

До сих пор я всегда использовал исходный код платформы ASP.NET MVC для отладки ASP.NET MVC. На своем ноутбуке я только что попробовал другой подход, а именно открыть окно «Модули» в VS, пока я отлаживаю и щелкаю правой кнопкой мыши System.Web.Mvc, затем выбираю «Загрузить символы из»> «Серверы символов Microsoft».

Казалось, что VS действительно что-то загружает, так как файл символов для сборки System.Web.Mvc был загружен. Кроме того, все строки, принадлежащие System.Web.Mvc в моем стеке вызовов, изменились с серого на черный. Однако я по-прежнему получаю сообщение об ошибке «Исходный код недоступен» при попытке войти в код, принадлежащий System.Web.Mvc.

Итак, я загрузил символы, но исходного кода все еще нет. Не большая проблема, так как я все еще могу отлаживать его по-старому. Но мне интересно, для чего тогда полезны серверы символов Microsoft?


visual-studio debugging .net symbols
person Adrian Grigore    schedule 06.05.2009    source источник
comment
Веселый. См. также здесь: social.msdn. microsoft.com/Forums/en/vsdebug/thread/   -  person Brent Arias    schedule 15.04.2011

Ответы (3)


arrow_upward
4
arrow_downward

Они обеспечивают правильную работу трассировки стека для собственных библиотек DLL — без символов ваши трассировки стека часто доходят только до ближайшей библиотеки DLL Windows, а затем останавливаются. С символами они продолжаются через библиотеки DLL Winodws. Вы можете видеть имена функций, но не исходный код (очевидно).

При отладке собственной программы 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

и вы не можете увидеть весь путь назад к началу.

person RichieHindle    schedule 06.05.2009
comment
Это имеет смысл для неуправляемого кода, но в управляемом коде я могу видеть стек для внешнего кода даже без использования файлов символов. Поэтому я все еще удивляюсь, почему они размещают файл символов для System.Web.Mvc, если загрузка символов не дает доступа к исходному коду. - person Adrian Grigore; 06.05.2009
comment
Для управляемого кода я не знаю. Возможно, это позволяет вам видеть значения параметров функции? - person RichieHindle; 06.05.2009

arrow_upward
2
arrow_downward

По моему опыту, серверы символов полезны как для управляемой отладки, так и для неуправляемой, поскольку они предоставляют столь необходимые сведения. Другие уже объяснили, почему это важно для нативного кода, поэтому я буду придерживаться управляемого кода.

Я довольно часто отлаживаю управляемый код с помощью WinDbg+Sos, и мне нужно регулярно копаться в нативной части. Помните, что для ОС управляемое приложение ничем не отличается от неуправляемого приложения. В конце концов, управляемое приложение будет вызывать библиотеки DLL Win32. Чтобы проверить их, вам нужны соответствующие символы.

Например. если вам нужно узнать подробности о конкретном управляемом вызове, вам действительно нужно взглянуть на собственный код. Одним из примеров может быть ситуация, когда вы видите Monitor.Enter в управляемом вами стеке. Вы не можете сказать, глядя на сам вызов, был ли вызов только что отправлен или поток действительно ожидает (*). Сбрасывая собственный стек вызовов, вы можете определить, был ли выполнен вызов WaitForMultipleObjects.

(*) Здесь вам помогут флаги состояния команды !threads, но если вам нужны подробности, дамп родного стека по-прежнему очень полезен.

person Brian Rasmussen    schedule 06.05.2009

arrow_upward
1
arrow_downward

Я не нашел, что сервер символов полезен для управляемых библиотек DLL — вы все равно получаете управляемые трассировки стека без них. Я думаю, что основная ценность управляемых символов — это информация о номере строки, но что вы собираетесь с этим делать?

Однако я не мог жить без символов для отладки нативного кода. А исходный сервер действительно очень полезен.

person Tim Robinson    schedule 06.05.2009
comment
Спасибо за ссылку на исходный сервер! К сожалению, он не охватывает все сборки, но выглядит очень полезным для тех, которые охватывает. - person Adrian Grigore; 06.05.2009