Нет символов, загруженных для этого документа Visual Studio

Обновлено: 05.07.2024

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

Суббота, 24 сентября 2016 г.

Удаленная отладка: "Точка останова в данный момент не будет достигнута. Для этого документа не загружено никаких символов."

Проблема:

При удаленной отладке точек останова отображается сообщение "Точка останова в данный момент не будет достигнута. Для этого документа не загружены символы".

Решение:

Решение 1. Убедитесь, что файлы PDB создаются для вашей сборки

На удаленном сервере перейдите в проводнике к папке bin вашего проекта. Обычно он находится на диске C: в папке inetpub\wwwroot\TheProject\bin. Убедитесь, что в этой папке есть файлы .PDB. Если их нет, вернитесь в Visual Studio и измените свойства вашего проекта, чтобы включить сгенерированные символы отладки.

Чтобы сделать это в Visual Studio 2015, щелкните проект правой кнопкой мыши и выберите "Свойства". Нажмите «Упаковать/опубликовать в Интернете». Убедитесь, что флажок «Исключить сгенерированные символы отладки» не установлен. Скорее всего, вы захотите сделать это для конфигураций отладки и выпуска.

Если вы выполнили вариант 1, но ошибка по-прежнему возникает, перейдите к варианту 2.

Решение 2. Убедитесь, что у вас одинаковая версия кода локально и на удаленном сервере.

Прежде чем подключаться к процессу, проверьте размер файлов DLL и PDB. Если они разного размера, у вас могут быть разные версии. Это может произойти, если код был построен с использованием двух разных методов. Например, если код был создан локально с помощью Visual Studio, а код на удаленном сервере был создан с помощью управления выпусками.

Выберите Инструменты > Параметры > отладка > Символы. Добавьте новое местоположение файла символов для вашего сервера сборки.
Укажите на папку bin проекта, который вы хотите отлаживать. Если у вас есть несколько проектов, которые вы хотите отладить, добавьте каждую из их папок bin. Это должно выглядеть примерно так, как на снимке экрана ниже.

Теперь подключите отладчик к удаленному серверу и убедитесь, что символы для вашего проекта загружены.

Решение 3. Убедитесь, что вы подключились к нужному процессу

В браузере перейдите на веб-сайт, размещенный на удаленном сервере. Это гарантирует, что процесс будет запущен в IIS. В Visual Studio в окне «Присоединить к процессу» найдите процесс w3wp.exe. Если их несколько, попробуйте подключиться ко всем из них, но вы должны быть в состоянии сказать, какой из них является веб-сайтом, который вам нужен. Если ваши символы загружаются правильно после этой попытки, у вас были правильные файлы DLL и PDB локально и на удаленном сервере, проблема заключалась в том, что Visual Studio подключалась к неправильному процессу.

Это должно выглядеть примерно так, как показано на снимке экрана ниже.

Решение 4. Убедитесь, что локальные и Release Management/MSBuild генерируют идентичные файлы.

Другим решением может быть изменение сборки управления выпуском, чтобы локальная сборка и сборка управления выпуском имели точно такие же настройки, чтобы они генерировали идентичные файлы DLL и PDB. Это не будет рассматриваться в этом посте, потому что это выходит за рамки этого поста. Тем не менее см. раздел «Другие действия, которые можно попробовать» ниже, где приведены инструкции по ручному копированию файлов DLL и PDB с локального компьютера на удаленный сервер, что обеспечит совпадение локальной и удаленной версий. Однако это неправильное решение, и его следует использовать только для устранения неполадок.

Пояснение:

Библиотеки DLL и PDB, сгенерированные из локальной сборки, должны соответствовать файлам на удаленном сервере, на котором выполняется код. Если это не так или Visual Studio не может найти файлы символов, эта ошибка появится в ваших точках останова.

Иногда вы создаете свой проект в Visual Studio и создаете тот же проект с помощью управления выпуском или MSBuild, но файлы DLL и PDB различаются. Это может быть связано с различием конфигураций сборки для Visual Studio и управления выпусками.

Еще что стоит попробовать:

Вручную копировать файлы DLL и PDB с локального компьютера на удаленный сервер.

Создайте проект на локальном компьютере, убедитесь, что в него включены файлы символов (.pdb). Чтобы получить эти файлы символов, попробуйте выполнить сборку в режиме отладки.Если у вас все еще нет файлов символов, щелкните правой кнопкой мыши файл проекта и в разделе «Пакет/публикация в Интернете» снимите флажок «Исключить сгенерированные символы отладки».
Теперь найдите папку bin вашего проекта в проводнике. У вас должен быть свежий набор файлов DLL и PDB в этой папке. «Дата изменения» для любой DLL и соответствующего файла PDB должна быть примерно одинаковой.

Теперь найдите папку bin для этого проекта на удаленном сервере. Это должно быть то же самое, что вы добавили в расположение файлов символов, поэтому в нашем примере это \\DevServer\c$\inetpub\wwwroot\TheProject\bin.
Создайте резервную копию этой папки на всякий случай.

Теперь перезапишите папку bin на сервере, скопировав папку bin с локального компьютера на удаленный сервер. Это делается для того, чтобы у вас были одни и те же файлы локально и на удаленном сервере. Это не является хорошим постоянным решением, но если ваши точки останова сработали сейчас, это доказывает, что ваша удаленная отладка настроена в основном правильно и что проблема заключается в различии файлов DLL и PDB между вашим локальным компьютером и удаленным сервером.

Статус символа

Во время отладки в Visual Studio выберите Отладка > Windows > Модули. Это окно может предоставить вам много информации для устранения неполадок. Найдите DLL вашего проекта (TheProject.dll в наших примерах). Если статус символа показывает «Символы загружены». тогда все работает правильно.

Вы можете щелкнуть правой кнопкой мыши запись здесь и выбрать «Загрузить символы», чтобы указать файл символов для использования. Если Visual Studio нравятся выбранные вами файлы символов, символы будут загружены, и ошибка исчезнет.

Я попробовал следующее:

Убедитесь, что конфигурация отладки, флаг отладки и полная информация об отладке установлены для всех сборок.
Удалите все папки bin и obj, а также все DLL-файлы, связанные с проектом, со всей моей машины.
Восстановите проекты, вызвавшие проблему, с нуля.
Перезагрузить.

У меня есть два проекта Windows Forms в решении. Один из них загружает отладочную информацию, другой нет. Оба они ссылаются на сборку, для которой я пытаюсь получить отладочную информацию точно так же, как в файле проекта. Есть идеи?

Я хочу добавить здесь, в основном для себя, когда я вернусь к рассмотрению этого вопроса, что символы не загружаются до тех пор, пока не загружена сборка, а сборка не загружается до тех пор, пока она не понадобится. Если точка останова находится в библиотеке, которая используется только в одной функции в вашей основной сборке, символы не будут загружены (и будет показано, что точка останова не сработала) до тех пор, пока эта функция не будет вызвана.

Во время отладки перейдите к представлению Отладка, Windows, Модули. Это покажет информацию о загруженных модулях и статусе символа. Вы можете щелкнуть модуль правой кнопкой мыши и попытаться загрузить символы из другого места.

Хорошее замечание о сборках, которые не загружаются до тех пор, пока они не потребуются. Отладчик покажет, что точка останова не будет достигнута, но отображение изменится/ваша точка останова БУДЕТ достигнута после загрузки сборки. Дрянный обходной путь этой проблемы пользовательского интерфейса состоял бы в том, чтобы вызвать сборку при запуске программы, чтобы принудительно загрузить сборку.

У меня была такая же проблема, и я заметил, что для этой конфигурации сборки у меня не было true под ней в VS2015, я добавил ее вручную, и она работала нормально.

125 ответов 125

Начните отладку, как только вы достигли точки останова или использовали Отладка > Прервать все , используйте Отладка > Windows > Модули . Вы увидите список всех сборок, загруженных в процесс. Найдите тот, для которого вы хотите получить отладочную информацию. Щелкните его правой кнопкой мыши и выберите Информация о загрузке символа. Вы получите диалоговое окно со списком всех каталогов, в которых он искал файл .pdb для сборки. Сравните этот список с фактическим местоположением .pdb. Убедитесь, что он не находит старый.

В обычных проектах сборка и ее файл .pdb всегда должны быть скопированы средой IDE в ту же папку, что и ваш .exe, т. е. в папку bin\Debug вашего проекта. Убедитесь, что вы удалили один из GAC, если вы играли с ним.

Вопрос касается экспресс-издания, к которому этот ответ, к сожалению, не относится. На самом деле ни один из ответов не работает для меня, я также попытался удалить папку Debug и восстановить ее.

Проверьте, находитесь ли вы не в выпуске, а в отладке.

Сначала попробуйте перестроить проект, щелкнув проект правой кнопкой мыши > Перестроить. Если это не сработает, попробуйте очистить проект (щелкните проект правой кнопкой мыши > очистить)

Если это не сработало, проверьте это:

Щелкните правой кнопкой мыши по вашему проекту
Выберите [Свойства]
Выберите вкладку [Сборка].
Убедитесь, что установлены флажки [Определить константу DEBUG] и [Определить константу TRACE].
Убедитесь, что флажок [Оптимизировать код] не установлен.
Нажмите кнопку [Дополнительно] в нижней части вкладки "Сборка".
Убедитесь, что для параметра [Информация об отладке:] установлено [полное]
Нажмите [OK] и перестройте проект ;-)

(шаг 7 создает файлы .pdb, это символы отладки)

Убедитесь, что [Информация об отладке:] установлена на [полный] — исправлено для меня! У меня есть несколько конфигураций, настроенных в моем проекте, новые, которые я добавил, не имели этого набора.

Что-то простое, что можно попробовать. Возможно, вы уже пробовали это. Щелкните правой кнопкой мыши решение в обозревателе решений, выберите «очистить решение», при этом будут удалены все скомпилированные и временные файлы, связанные с решением.

Выполните перестройку решения и повторите попытку отладки.

У меня также были проблемы с точками останова для нескольких проектов в решении — некоторые скомпилированы как x86, некоторые как x64.

Отключите параметр "Только мой код" в настройках "Отладка/Общие".

Просто для ясности: в VS 2017 этот параметр находится в диалоговом окне «Инструмент», «Параметры» на панели «Отладка», «Общие» (точнее, панели «Отладка» нет). Флажок называется «Включить только мой код», а не «Только мой код».

Это также относится к ситуациям, когда вы пытаетесь отладить веб-проект, который является конечной точкой удаленного взаимодействия .NET, работающей на сервере разработки VS и отображающей сообщение "Нет загруженных символов".

Я заметил, что на самом деле не запускал проект, который пытался отлаживать facepalm. Так что обратите внимание и на это, если у вас есть конфигурация запуска с несколькими проектами, убедитесь, что вы включили проект, который пытаетесь отлаживать!

Даже если в раскрывающемся списке выбрано "Отладка":

И в Свойствах проекта > Сборка:

Visual Studio не загружала символы в конкретный проект. Итак, в этом раскрывающемся списке я выбираю «Диспетчер конфигурации» и вижу, что настройки моего веб-проекта неверны:

Затем я установил для него значение "Отладка", и он начал генерировать файл .pdb. НО мне нужно вручную скопировать PDB и DLL и поместить в папку, которую искал VS (вот где мне помог выбранный ответ):

Ключевым для меня было то, что флажок "Развернуть" не был установлен, поэтому pdb не развертывался повторно после сборки

Иногда, несмотря на то, что выдается эта ошибка, точка останова все равно срабатывает, поэтому просто игнорируйте ошибку. Это происходит довольно часто в представлениях веб-приложения MVC, например .cshtml.

На самом деле за это нужно проголосовать где-нибудь вверху. Я потратил много времени на все ответы выше, но на самом деле точка останова была бы достигнута. Просто проверьте :) Кроме того, это было настольное приложение WPF.

Отладка > Windows > Модули, чтобы увидеть, какие модули загружаются, указали мне правильное направление.

Мне удалось исправить ошибку, просто установив для параметра "Присоединить к процессу" значение "Автоматически определять тип кода для отладки", как показано на прикрепленном снимке экрана.

Просто следуйте инструкциям ниже:

Перейти к отладке из строки меню
Нажмите "Присоединить к процессу".
Рядом с параметром "Прикрепить к" нажмите кнопку "Выбрать".
Появится окно выбора типа кода.
Теперь выберите параметр "Автоматически определять тип кода для отладки" и нажмите кнопку "ОК".

Для тех, кто пробовал все на этой странице, я решил проблему, переключившись на "Управляемый код (v4.5, v4.0)"!

Проверьте, отсутствует ли файл .pbd в папке bin/Debug. Если это так, перейдите в «Свойства» вашего проекта, выберите «Сборка», а затем «Дополнительно» внизу. Выберите «полный» в разделе «Информация об отладке» в появившемся новом окне. Это была моя проблема, и она была решена для меня.

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

Решением было снять этот флажок.

Просто проверьте, находится ли ваше решение в режиме выпуска.

Для новичков (таких как я) ваш ответ может быть легко истолкован как "Режим выпуска — это то, что нужно." Я полагаю, вы имели в виду "проверьте, находится ли ваше решение в режиме выпуска и измените его на отладку".

Попробуйте запустить Visual Studio от имени администратора в Windows.

В моем случае я пытаюсь выполнить отладку в режиме релиза. Как только я переведу его в режим отладки. Работает

Отладка -> Параметры -> Общие -> Снимите флажок «Включить только мой код»

Это сработало для меня.

Необходимо включить "Создавать отладочную информацию" в настройках компилятора

Я перепробовал все вышеперечисленное, но ничего не получилось. [Очистить решение и проверить файлы PDB и т. д.]

Даже публикация того же решения не решила проблему.

Затем я вернулся к тому, что обычно делаю (обмануть эту упрямую Visual Studio)

Все, что я сделал, это преднамеренно изменил код и опубликовал решение. Затем я отменил изменение и снова опубликовал его.

Вуаля [файлы PDB избавлены от злых духов].. Не очень удачное решение, но это сработало.. :-|

Проверьте раскрывающийся список «Конфигурация решения». Убедитесь, что вы выбрали Debug , а не Release .

Параметр «Начать отладку, отладка + Windows + модули» отсутствует в выпуске Microsoft Visual Studio Express 2013.

Снятие флажка «Использовать режим управляемой совместимости» в параметрах инструментов «Отладка» устраняет эту проблему.

Только веб-приложения (IIS Express):

Щелкните правой кнопкой мыши IIS Express Tray и закройте IIS.
Чистое решение

Чистое решение и восстановление
Убедитесь, что конфигурация настроена на отладку.
Убедитесь, что файл PDB находится в папке Debug.
В меню "Отладка" нажмите "Включить все точки останова".

Ни один из этих ответов не решил мою проблему. Я попробовал еще одну вещь, основанную на том факте, что проект с остановкой на самом деле не был загруженным проектом. Я обнаружил, как написал Ханс Пассант, что .dll, где я хочу остановить отладчик, и связанные файлы .pdb копируются рядом с файлом .exe. У этих файлов более старая дата, поэтому я подумал, что они не обновлялись во время выполнения. Я удалил их вручную, Visual Studio создал еще одну пару и поместил эту новую пару рядом с .exe. Теперь точки останова работают!

Возможно, Visual Studio не может копировать и ЗАМЕНЯТЬ существующие файлы (.dll и .pdb) рядом с .exe, поскольку там есть другой. Поэтому, если бы я удалил вручную, VS мог бы создать новый рядом с .exe.

Я думаю, что другие изменения (проверки и т. д. - из других ответов) что-то вызвали, и Visual Studio скопировала и заменила dll и pdb из папки проекта в папку рядом с exe, так что это было решение.

Я думаю, что основная причина проблемы заключается в том, что Visual Studio использует другой файл во время выполнения, а не файл из проекта, с остановкой.

Файлы базы данных программы (.pdb), также называемые файлами символов, сопоставляют идентификаторы и операторы в исходном коде вашего проекта с соответствующими идентификаторами и инструкциями в скомпилированных приложениях. Эти файлы сопоставления связывают отладчик с исходным кодом, что позволяет выполнять отладку.

При сборке проекта из интегрированной среды разработки Visual Studio со стандартной конфигурацией сборки отладки компилятор создает соответствующие файлы символов. В этой статье описывается, как управлять файлами символов в среде IDE, например:

Для получения подробной информации о файлах символов см. следующее:

Как работают файлы символов

Файл .pdb содержит отладочную информацию и информацию о состоянии проекта, которая позволяет выполнять добавочное связывание конфигурации отладки вашего приложения. Отладчик Visual Studio использует файлы .pdb для определения двух ключевых элементов информации при отладке:

Имя исходного файла и номер строки для отображения в интегрированной среде разработки Visual Studio.
Где в приложении остановиться для точки останова.

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

Отладчик загружает только те файлы .pdb, которые точно соответствуют файлам .pdb, созданным при сборке приложения (то есть исходному .pdb файлы или копии). Это точное дублирование необходимо, потому что макет приложений может измениться, даже если сам код не изменился. Дополнительные сведения см. в разделе Почему Visual Studio требует, чтобы файлы символов отладчика точно соответствовали двоичным файлам, с помощью которых они были созданы?

Для отладки кода вне исходного кода вашего проекта, например кода Windows или стороннего кода, который вызывает ваш проект, необходимо указать расположение файлов .pdb внешнего кода (и, при необходимости, исходный код файлы), которые должны точно соответствовать сборкам в вашем приложении.

Где отладчик ищет символы

При отладке проекта в интегрированной среде разработки Visual Studio отладчик автоматически загружает файлы символов, которые он может найти по умолчанию.

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

Отладчик ищет файлы символов в следующих местах:

Папка проекта.

Расположение, указанное внутри библиотеки DLL или исполняемого файла (.exe).

По умолчанию, если вы создали DLL или файл .exe на своем компьютере, компоновщик помещает полный путь и имя связанного файла .pdb в файл DLL или .exe. Отладчик проверяет, существует ли файл символов в этом месте.

Та же папка, что и файл DLL или .exe.

Любые местоположения, указанные в параметрах отладчика для файлов символов. Сведения о добавлении и включении местоположений символов см. в разделе Настройка местоположений символов и параметров загрузки.

Любая локальная папка кэша символов.

Указанные сетевые, интернет- или локальные серверы символов и местоположения, например серверы символов Microsoft, если они выбраны. Visual Studio может загружать файлы символов отладки с серверов символов, реализующих протокол symsrv. Visual Studio Team Foundation Server и средства отладки для Windows — это два инструмента, которые могут использовать серверы символов.

Серверы символов, которые вы можете использовать, включают:

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

Сторонние серверы символов. Сторонние поставщики приложений и библиотек для Windows могут предоставлять доступ к серверу символов через Интернет.

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

Настроить расположение файлов символов и параметры загрузки

По умолчанию отладчик проверяет наличие символов в различных местах. См. раздел Где отладчик ищет символы.

На странице Инструменты > Параметры > Отладка > Символы вы можете:

Укажите и выберите пути поиска файлов символов.

Укажите серверы символов для компонентов Microsoft, Windows или сторонних производителей.

Укажите модули, для которых вы хотите или не хотите, чтобы отладчик автоматически загружал символы.

Изменяйте эти параметры во время активной отладки. См. раздел Загрузка символов во время отладки.

Чтобы указать расположение символов и параметры загрузки:

В Visual Studio откройте Инструменты > Параметры > Отладка > Символы (или Отладка > Параметры > Символы).

В разделе Расположение файлов символов (.pdb)

Чтобы добавить новое местоположение сервера символов,

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

Чтобы добавить новое местоположение сервера символов VSTS,

Чтобы изменить порядок загрузки символов, используйте Ctrl+Up и Ctrl+Down или значки со стрелками вверх и вниз.

Чтобы изменить URL-адрес или путь, дважды щелкните запись или выберите ее и нажмите F2.

Чтобы удалить запись, выберите ее, а затем выберите значок -.

(Необязательно) Чтобы повысить производительность загрузки символов, в разделе Кэшировать символы в этом каталоге введите путь к локальной папке, в которую серверы символов могут копировать символы.

Не помещайте локальный кэш символов в защищенную папку, например C:\Windows, или во вложенную папку. Вместо этого используйте папку для чтения и записи.

Для проектов C++, если у вас установлена переменная среды _NT_SYMBOL_PATH, она переопределит значение, установленное в символах кэша в этом каталоге.

Укажите модули, которые вы хотите, чтобы отладчик загружал из файлов символов (.pdb) при запуске.

Выберите Загрузить все модули, если они не исключены (по умолчанию), чтобы загрузить все символы для всех модулей в местоположении файла символов, за исключением специально исключенных модулей. Чтобы исключить определенные модули, выберите Указать исключенные модули, выберите значок +, введите имена исключаемых модулей и нажмите кнопку ОК.

Чтобы загружать только указанные вами модули из расположений файлов символов, выберите Загружать только указанные модули. Выберите Указать включенные модули, щелкните значок +, введите имена модулей, которые необходимо включить, а затем нажмите кнопку ОК. Файлы символов для других модулей не загружены.

Выберите ОК.

Другие варианты символов для отладки

Вы можете выбрать дополнительные параметры символа в Инструменты > Параметры > Отладка > Общие (или Отладка > Параметры > Общие):

Загрузить экспорт DLL (только собственный)

Загружает таблицы экспорта DLL для C/C++. Дополнительные сведения см. в разделе Таблицы экспорта DLL. Чтение информации об экспорте DLL связано с некоторыми накладными расходами, поэтому загрузка экспортных таблиц по умолчанию отключена.Вы также можете использовать dumpbin /exports в командной строке сборки C/C++.

Включить отладку на уровне адреса и Показать дизассемблирование, если исходный код недоступен

Всегда показывает разборку, если исходные файлы или файлы символов не найдены.

Включить поддержку исходного сервера

Использует исходный сервер для отладки приложения, если на локальном компьютере нет исходного кода или файл .pdb не соответствует исходному коду. Исходный сервер принимает запросы на файлы и возвращает фактические файлы из системы управления версиями. Исходный сервер запускается с помощью библиотеки DLL с именем srcsrv.dll для чтения файла .pdb приложения. Файл .pdb содержит указатели на репозиторий исходного кода, а также команды, используемые для извлечения исходного кода из репозитория.

Вы можете ограничить команды, которые srcsrv.dll может выполнять из файла приложения .pdb, перечислив разрешенные команды в файле с именем srcsrv.ini< /эм>. Поместите файл srcsrv.ini в ту же папку, что и srcsrv.dll и devenv.exe.

Произвольные команды могут быть встроены в файл .pdb приложения, поэтому обязательно поместите в файл srcsrv.ini только те команды, которые вы хотите выполнить. Любая попытка выполнить команду, отсутствующую в файле srcsvr.ini, приведет к появлению диалогового окна подтверждения. Дополнительные сведения см. в разделе Предупреждение системы безопасности: отладчик должен выполнить ненадежную команду.

Проверка параметров команды не выполняется, поэтому будьте осторожны с доверенными командами. Например, если вы указали cmd.exe в файле srcsrv.ini, злоумышленник может указать параметры cmd.exe, которые сделают его опасно.

Выберите этот элемент и нужные дочерние элементы. Разрешить исходному серверу сборки с частичным доверием (только для управляемых) и всегда выполнять команды ненадежного исходного сервера без запроса могут увеличить риски безопасности.

Параметры символа компилятора

При сборке проекта из интегрированной среды разработки Visual Studio со стандартной конфигурацией сборки отладки C++ и управляемые компиляторы создают соответствующие файлы символов для вашего кода. Вы также можете установить параметры компилятора в коде.

Чтобы задать параметры компилятора для конфигураций сборки в Visual Studio, см. статью Установка конфигураций отладки и выпуска.

Параметры C/C++

Файл .pdb для C/C++ создается при сборке с использованием /ZI или /Zi. В Visual C++ параметр /Fd присваивает имя файлу .pdb, который создает компилятор. Когда вы создаете проект в Visual Studio с помощью IDE, параметр /Fd устанавливается для создания файла .pdb с именем

Если вы создаете приложение C/C++ с помощью make-файла и указываете /ZI или /Zi без использования /Fd, компилятор создает два файла .pdb:

VC .pdb, где представляет версию компилятора Microsoft C++, например VC11.pdb

В файле VC .pdb хранится вся отладочная информация для отдельных объектных файлов, и он находится в том же каталоге, что и make-файл проекта. Каждый раз при создании объектного файла компилятор C/C++ объединяет отладочную информацию с файлом VC .pdb. Таким образом, даже если каждый исходный файл включает общие файлы заголовков, такие как , определения типов из этих заголовков сохраняются только один раз, а не в каждом объектном файле. Вставленная информация включает информацию о типе, но не включает информацию о символах, такую как определения функций.
В файле
.pdb хранится вся отладочная информация для файла .exe проекта, и он находится в подкаталоге \debug.
Файл

.pdb содержит полную информацию об отладке, включая прототипы функций, а не только информацию о типе из VC .pdb.

Как VC .pdb, так и

Файлы

.pdb допускают добавочные обновления. Компоновщик также встраивает путь к файлам .pdb в создаваемый им файл .exe или .dll.

Таблицы экспорта DLL

Используйте команду dumpbin /exports, чтобы просмотреть символы, доступные в таблице экспорта библиотеки DLL. Символическая информация из таблиц экспорта DLL может быть полезна для работы с сообщениями Windows, процедурами Windows (WindowProcs), COM-объектами, маршалингом или любой библиотекой DLL, для которой у вас нет символов. Символы доступны для любой 32-битной системной DLL. Вызовы перечислены в порядке вызова, при этом текущая функция (наиболее глубоко вложенная) находится вверху.

Прочитав выходные данные dumpbin /exports, можно увидеть точные имена функций, включая небуквенно-цифровые символы.Просмотр точных имен функций полезен для установки точки останова для функции, поскольку имена функций могут быть усечены в другом месте отладчика. Дополнительные сведения см. в разделе dumpbin/exports.

Веб-приложения

Загружать символы во время отладки

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

Работа с символами в окне "Модули"

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

Чтобы отслеживать или изменять расположение или параметры символов во время отладки:

Чтобы открыть окно "Модули", во время отладки выберите "Отладка" > "Окна" > "Модули" (или нажмите Ctrl + Alt + U).
В окне "Модули" щелкните правой кнопкой мыши заголовки "Статус символа" или "Файл символов" или любой модуль.
В контекстном меню выберите один из следующих вариантов:

Использование страниц без загрузки символов/без загрузки исходного кода

Существует несколько способов, с помощью которых отладчик может проникнуть в код, в котором отсутствуют символы или исходные файлы:

Перейти к коду.
Взлом в код из точки останова или исключения.
Переключиться на другую цепочку.
Измените фрейм стека, дважды щелкнув фрейм в окне стека вызовов.

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

Чтобы использовать страницу документа "Нет символов загружено" для поиска и загрузки отсутствующих символов:

Если отладчик находит файл .pdb после выполнения одной из опций и может получить исходный файл, используя информацию в файле .pdb, он отображает источник. В противном случае отображается страница «Нет загруженного источника», на которой описывается проблема со ссылками на действия, которые могут ее решить.

Чтобы добавить пути поиска исходных файлов в решение:

Вы можете указать места, в которых отладчик ищет исходные файлы, и исключить определенные файлы из поиска.

Выберите решение в обозревателе решений, а затем выберите значок "Свойства", нажмите клавиши ALT+ВВОД или щелкните правой кнопкой мыши и выберите "Свойства".

Выберите исходные файлы отладки.

В разделе Каталоги, содержащие исходный код, введите или выберите местоположения исходного кода для поиска. Используйте значок "Новая линия", чтобы добавить дополнительные местоположения, значки со стрелками вверх и вниз, чтобы изменить их порядок, или значок X, чтобы удалить их.

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

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

Если вы используете Visual Studio для отладки своего кода, вы привыкнете к тому, что он волшебным образом загружает правильные символы при отладке запущенного процесса. На самом деле, вы можете так привыкнуть к этому, что вам может не прийти в голову, что загрузка символов — это то, что должен делать отладчик, не говоря уже о том, что в некоторых ситуациях вам приходится делать это вручную.

Но если вы привыкли отлаживать аварийные дампы для программного обеспечения, которое было выпущено в дикой природе, подключая отладчик к удаленным процессам, выполняющим развертывание, созданное CI, или использовали другие, более ручные системы отладки, такие как gdb или WinDbg, тогда вы гораздо лучше поймете, что отладчик должен загружать правильные символы, чтобы он мог понять все двоичные данные, из которых состоит работающая (или, скорее всего, аварийно завершающая) программа.

К счастью для большинства из нас, Visual Studio действительно хорошо справляется с автоматической загрузкой символов (в частности, с автоматической загрузкой правильных символов), так что в большинстве случаев вы даже не замечаете, что задание делается, неважно, что он делает это правильно. Если ваша система непрерывной интеграции и пути к символам Visual Studio настроены правильно, система будет работать, что позволит вам просмотреть всю глубину аварийного дампа любой версии вашего программного обеспечения, которое было развернуто.

А если нет? Что делать, если вы столкнулись с ужасным экраном «Символы не загружены»? И почему, когда вы указываете Visual Studio на dll или pdb, которые, как вы уверены, нужны, он отказывается их загружать? Что ж, давайте приоткроем завесу и посмотрим, как работает магия загрузки символов и отладки аварийного дампа.

Для этого глубокого погружения я буду использовать Hex Editor Neo Free, хотя вы можете использовать другие инструменты, такие как CFF Explorer или любой другой шестнадцатеричный редактор или PE Explorer, чтобы сделать то же самое. Кроме того, я должен отдать должное этому сообщению Олега Стародумова, которое помогло мне расшифровать многое из того, что отсутствует в официальной документации.

Шаг 1. Поиск подходящего модуля

Что происходит, когда вы получаете минидамп, загружаете его в Visual Studio и начинаете отладку? При отладке полного дампа памяти или при подключении к работающему процессу Visual Studio может напрямую проверять загруженные модули (исполняемый исполняемый файл и любые загруженные библиотеки DLL). В минидампе сохраняется только имя модуля и дополнительная информация в структуре MINIDUMP_MODULE. Visual Studio извлекает имя, метку времени и размер изображения и будет использовать все три, чтобы попытаться найти правильный модуль в хранилище символов. Он также будет использовать эту информацию для проверки любого модуля перед его загрузкой.

Давайте загрузим файл dmp и самостоятельно найдем эти данные, чтобы попытаться отладить неудачную загрузку (если вы хотите попробовать и у вас нет под рукой минидампа, вы можете создать его, щелкнув правой кнопкой мыши любой процесс в на панели «Сведения» диспетчера задач и выбрав в меню «Создать файл дампа»). Используя Hex Editor Neo, сделайте следующее:

VS использует конкатенацию TimeDateStamp и SizeOfImage в качестве уникального ключа для поиска в хранилище символов, а затем проверяет оба этих значения в любом двоичном модуле, который пытается загрузить. Это первая часть проверки того, что VS не загружает неправильные символы для сеанса отладки.

Шаг 2. Загрузка модуля

Теперь мы можем посмотреть, где Visual Studio ожидает найти двоичный модуль, который она пытается загрузить. Перейдите в хранилище символов (место, где ваша сборка CI выдает символы) и найдите подкаталог с именем модуля, который вы ищете — в нашем случае это папка с именем d3d11.dll. Если у вас нет хранилища символов для просмотра, вы можете посмотреть в своем локальном кэше символов, который обычно находится в %LOCALAPPDATA%\Temp\SymbolCache, поскольку он хранит кэшированные символы и двоичные файлы в том же формате. В папке d3d11.dll мы видим несколько папок с шестнадцатеричными значениями в качестве имен. Мы ищем то, которое является конкатенацией двух значений, которые мы нашли ранее: TimeDateStamp и SizeOfImage (обратите внимание, что для SizeOfImage наименее значащий байт опущен). В нашем случае это дает нам FECB8D5ED03600, и мы видим, что там есть нужная нам папка.

Когда эта папка отсутствует, Visual Studio запрашивает расположение двоичного файла. Теперь мы можем открыть модуль и найти совпадающую информацию внутри двоичного файла, что Visual Studio использует для проверки того, что он действительно нашел правильный двоичный модуль. Именно невыполнение этого шага приводит к наибольшей нервотрепке, когда вы указываете Visual Studio на файл, который, по вашему мнению, ему нужен, а он просто отказывается его загружать! По крайней мере, теперь вы будете знать, почему он не загружается (и если вы действительно хотите заставить его загрузиться, то вы будете знать, какой фрагмент файла нужно отредактировать, чтобы заставить его загрузиться)!

Если вам интересно, откуда берутся все эти папки, они создаются с помощью инструмента под названием SymStore, который можно запустить непосредственно из сборки CI или из задачи PublishSymbols в TFS/Azure DevOps. Дополнительную информацию смотрите в конце этого поста.

Мы снова открываем файл в HexEditorNeo, но на этот раз вместо того, чтобы смотреть на необработанный шестнадцатеричный код, мы можем использовать панель просмотра структуры (возможно, вам придется включить расширенный режим, чтобы увидеть это), чтобы изучить заголовки PE. Вы также можете использовать другой инструмент, такой как CFF Explorer, чтобы сделать это. Теперь мы просто переходим к dos_header → e_lfanew → FileHeader → TimeDateStamp, чтобы прочитать значение TimeDateStamp. Нажав на нее, мы попадем в соответствующее место в шестнадцатеричном редакторе, что позволит нам легко проверить соответствие шестнадцатеричного значения.

Затем мы переходим к dos_header → e_lfanew → OptionalHeaderSelector → OptionalHeader → SizeOfImage, чтобы прочитать значение SizeOfImage.Снова щелкнув по нему, мы перейдем к соответствующей части двоичного файла, чтобы мы могли напрямую сравнить шестнадцатеричные значения и проверить совпадение.

Если вы были вынуждены пересобрать модуль, чтобы он соответствовал историческому аварийному дампу, это значение должно совпадать, а отметка времени будет другой. Просто измените TimeDateStamp во вновь созданном двоичном файле, чтобы он соответствовал ожидаемому значению (или отредактируйте файл дампа, чтобы он соответствовал вновь созданному модулю), и Visual Studio загрузит ваш новый двоичный файл, а затем извлечет вновь созданные символы!< /p>

Наконец, напоминание о том, что если мы отлаживаем активный процесс или полный дамп памяти, то Visual Studio может напрямую проверять модуль в памяти, поэтому эти первые два шага не требуются, и мы можем сразу перейти к следующему шагу. .

Шаг 3. Поиск подходящего pdb

Как только мы загрузим правильный модуль, все станет немного проще. Это связано с тем, что Visual Studio перешла от работы с сигнатурами, полученными из заголовков модулей общего назначения, к работе с явной отладочной информацией. В этом случае мы начинаем с поиска в DebugDirectory части заголовков PE, которая содержит ссылку на точную версию символов, которую Visual Studio хочет загрузить.

Снова мы можем использовать вкладку Просмотр структуры или другой обозреватель структуры PE, чтобы исследовать DebugDirectory, и теперь мы ищем хранящиеся там необработанные данные. Итак, мы переходим к DebugDirectory → AddressOfRawData → Data → data и нажимаем на него, чтобы перейти в соответствующее место в главном шестнадцатеричном редакторе. Мы видим, что этот раздел начинается с волшебной строки «RSDS», за которой следуют 16 байтов GUID, за которыми следует значение возраста (обычно «1») в виде uint32 и, наконец, исходный путь к файлу символов. Запишите эти значения, и теперь мы можем использовать их для загрузки правильных символов! В этом примере байты: F82BEBBA3FFA9C4D84643895BFA0295E для GUID и 01000000 для возраста.

Шаг 4. Загрузка правильных символов

Если вы отлаживаете процесс на машине, на которой был создан двоичный файл, все немного проще, поскольку мы только что нашли путь, ведущий непосредственно к файлам символов для загрузки! Но что, если бинарный файл был собран на другой машине, скажем, на CI-сервере? Что ж, опять Visual Studio обратится к хранилищу символов.

Бьюсь об заклад, вам интересно, загрузит ли Visual Studio эти символы вслепую или сначала подтвердит, что они действительно являются правильными символами для запущенного процесса. Вы, конечно, правы — есть последний шаг проверки, прежде чем Visual Studio действительно будет использовать символы, которые она только что нашла (или, если оба вышеуказанных поиска дадут пустое место, файл символов, который вы только что попросили загрузить из файла диалог). Visual Studio подтверждает, что это правильные символы, ища GUID внутри самого файла PDB. Судя по моим беглым исследованиям, он хранится в файле по смещению 0x0000500C с возрастом 0x00005008. Однако достаточно просто использовать шестнадцатеричный редактор и найти весь набор байтов, составляющих GUID (в данном случае F82BEBBA3FFA9C4D84643895BFA0295E). Если он нигде в файле не совпадает, то это точно не те символы!

Заключение и дополнительная литература

Вот как Visual Studio делает свое волшебство и сопоставляет символы с минидампом. Будем надеяться, что теперь, если один из этих шагов не сработает (из-за поврежденного файла, сбоя хранилища символов или каких-либо других махинаций с CI), вам будет чем заняться при попытке диагностировать проблему!

Для получения дополнительной информации об индексации исходного кода и символах серверов прочитайте эту статью на CodeProject

Читайте также: