2009-05-06 4 views
4

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

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

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

+0

Веселый. См. Также здесь: http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/c5084825-06f2-4859-b9f0-61325bfeacba –

ответ

4

Они делают трассировку стека корректно для родных 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 

Без символов для библиотек DLL для Windows, вы обнаружите, что стек только получает далеко:

mydll.dll 
    mydll.dll 
    some_windows_dll.dll 

, и вы не доберетесь до самого начала.

+0

Это имеет смысл для неуправляемого кода, но в управляемом коде я вижу стек для внешнего кода даже без использования файлов символов.Поэтому я все еще удивляюсь, почему они будут размещать файл символов для System.Web.Mvc, если загрузка символов не дает доступа к исходному коду. –

+0

Для управляемого кода я не знаю. Может ли это позволить вам увидеть значения параметров функции, может быть? – RichieHindle

1

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

Я не мог жить без символов для отладки собственного кода. И source server очень полезен.

+0

Спасибо за ссылку на исходный сервер! К сожалению, он не охватывает все сборки, но он выглядит верным для тех, кого он охватывает. –

2

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

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

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

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

Смежные вопросы