Поделиться через


Отладка с помощью символов

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

Символы

Для отладки доступны различные типы символов. К ним относятся символы CodeView, COFF, DBG, SYM, PDB и даже экспорт символов, созданные из таблицы экспорта двоичных файлов. В этом техническом документе рассматриваются только VS.NET и символы формата PDB, так как они являются самым последним, предпочтительным форматом. Они создаются по умолчанию для проектов, скомпилированных с помощью Visual Studio.

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

PDB-файлы создаются при создании проекта с помощью переключателя компилятора / Zi или /ZI (Создание сведений О PDB) вместе с параметром компоновщика /DEBUG (Generate Debug Info). Файлы PDB, созданные компилятором, объединяются и записываются в один PDB-файл, который помещается в тот же каталог, что и исполняемый файл.

По умолчанию PDB-файлы содержат следующие сведения:

  • Общедоступные символы (как правило, все функции, статические и глобальные переменные)
  • Список файлов объектов, ответственных за разделы кода в исполняемом файле.
  • Сведения об оптимизации указателя кадров (FPO)
  • Сведения о имени и типе для локальных переменных и структур данных
  • Сведения о исходном файле и номере строки

Если вы обеспокоены тем, кто использует сведения о PDB-файле, чтобы помочь им выполнить обратный инженер исполняемого файла, вы также можете создать срезированные PDB-файлы, используя параметр компоновщика /PDBSTRIPPED:filename . Если у вас есть PDB-файлы, из которых вы хотите удалить частную информацию, можно использовать средство под названием pdbcopy, которое входит в состав средств отладки для Windows.

По умолчанию файлы PDB с разделимы содержат следующие сведения:

  • Открытые символы (обычно только нестатические функции и глобальные переменные)
  • Список файлов объектов, ответственных за разделы кода в исполняемом файле.
  • Сведения об оптимизации указателя кадров (FPO)

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

Использование символов для отладки

При отладке приложения, завершившегося сбоем, отладчик пытается показать функции в стеке, что привело к сбою. Без PDB-файла отладчик не может разрешать имена функций, их параметры или любые локальные переменные, хранящиеся в стеке. При отладке 32-разрядных исполняемых файлов возникают ситуации, когда даже не удается получить надежные трассировки стека без символов. Иногда можно просмотреть необработанные значения в стеке и определить, какие значения могут быть возвращены адреса, но их можно легко путать с ссылками на функции или данными.

Если функции в текущем стеке компилировались с помощью оптимизации опущенных указателей кадров (/Oy), а если символы отсутствуют, отладчик не может надежно определить, какая функция называется текущей функцией. Это связано с тем, что без сведений об оптимизации указателя кадров (FPO), содержащиеся в PDOB-файлах, отладчик не может полагаться на регистр указателя кадров (EBP) для указания на сохраненный предыдущий указатель кадра и на возвращаемый адрес родительской функции. Вместо этого он догадывается. Иногда он получает его правильно. Тем не менее, он часто получает это неправильно, что может быть вводящим в заблуждение. Если отображается предупреждение о отсутствующих символах или нет загруженных символов, как показано в следующем примере, не доверяйте стеку с этой точки вниз.

SWPerfTest.exe!TextFunction(... ...)    Line 59    C++
d3dx9d.dll!008829b5()
[Frames below may be incorrect and/or missing, no symbols loaded for d3dx9d.dll]
SWPerfTest.exe!main(int argc=, const char * * argv=)  Line 328 + 0x12 bytes     C++
SWPerfTest.exe!__mainCRTStartup() Line 716 + 0x17 bytes    C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x27 bytes

Во многих случаях можно продолжать отладку без символов, так как проблема находится в расположении с точными символами, и вам не нужно смотреть на функции дальше вниз по стеку вызовов. Даже если библиотека, которая находится в стеке вызовов, не имеет доступных PDF-файлов, если они были скомпилированы с указателями кадров, отладчик должен иметь возможность правильно угадать в родительских функциях. Начиная с Windows XP с пакетом обновления 2 все dll-файлы и исполняемые файлы Windows компилируются с отключенным FPO, так как это делает отладку более точной. Отключение FPO также позволяет профилировщикам выборки ходить по стеку во время выполнения с минимальным влиянием на производительность. В версиях Windows до Windows XP с пакетом обновления 2 (SP2) все двоичные файлы операционной системы требуют сопоставления файлов символов, содержащих сведения О FPO, чтобы обеспечить точную отладку и профилирование.

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

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

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

Получение нужных символов

Visual Studio и другие отладчики Майкрософт, такие как WinDbg, обычно настраиваются для простой работы, если вы создаете приложение и выполняете отладку на своем компьютере. Если вам нужно предоставить исполняемый файл другому пользователю, если у вас есть несколько версий DLL или EXE-файла на компьютере, или если вы хотите точно отлаживать приложение, использующее Windows или другие библиотеки, например DirectX, необходимо понять, как отладчики находят и загружают символы. Отладчик использует либо путь поиска символов, указанный пользователем, который находится в разделе "Параметры\Отладка\Символы" в Visual Studio, либо переменную среды _NT_SYМБOL_PATH. Как правило, отладчик выполняет поиск соответствующих PDF-файлов в следующих расположениях:

  • Расположение, указанное в библиотеке DLL или в исполняемом файле.

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

  • PDF-файлы, которые могут присутствовать в той же папке, что и DLL-файл или исполняемый файл.

  • Все папки локального кэша символов.

  • Все серверы символов общей папки локальной сети.

  • Все серверы символов Интернета, такие как сервер символов Майкрософт.

Чтобы убедиться, что у вас есть все PDF-файлы, необходимые для точной отладки, установите средства отладки для Windows. 32 и 64-разрядные версии можно найти в средствах отладки для Windows.

Полезное средство, установленное с этим пакетом, — symchk.exe. Это может помочь определить отсутствующие или неправильные символы. Это средство имеет большое количество потенциальных параметров командной строки. Ниже приведены два из наиболее полезных и часто используемых.

Проверьте, соответствует ли заданный DLL-файл или ФАЙЛ .exe и PDB в той же папке.

"c:\Program Files\Debugging Tools for Windows\symchk" testing.dll /s .

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1

Параметр /s . указывает симчк искать символы только в текущей папке, а не искать на серверах символов.

Проверьте, имеют ли все библиотеки DLL и исполняемые файлы в наборе папок соответствующие PDF-файлы.

"c:\Program Files\Debugging Tools for Windows\symchk" *.* /r

Параметр /r задает симчк для рекурсивного перемещения по папкам, чтобы проверка, что все исполняемые файлы имеют соответствующие PDF-файлы. Без параметра /symchk использует текущую _NT_SYМБOL_PATH для поиска символов на любом частном или локальном сервере или на серверах символов Майкрософт. Средство symchk ищет только символы исполняемых файлов (EXE, DLL и аналогичные). Не удается использовать дикие карта поиска символов для файлов, отличных от исполняемых файлов.

Как работает symchk

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

Вы также можете использовать служебную программу DUMPBIN, которая поставляется с VS.NET для отображения путей символов, которые выполняются в поиске, и чтобы узнать, найдены ли файлы символов, соответствующие заданному DLL или исполняемому файлу. Например:

DUMPBIN /PDBPATH:VERBOSE filename.exe

Серверы символов

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

Библиотеки DLL и исполняемые файлы также доступны на сервере символов Майкрософт. Это позволяет отлаживать сбои и проверять код для файлов операционной системы, которые могут не существовать на компьютере. Если отладчик встречает исполняемый файл или библиотеку DLL, которая не существует в системе, используемой для отладки, она автоматически запрашивает как символы, так и копию двоичного файла с серверов символов Майкрософт. Это полезно при отладке компонента, имеющего множество версий ( например, msvcrt.dll), и необходимо проверить код для версии, которая не существует на компьютере. Это также помогает отлаживать мини-дампы, созданные в операционной системе, отличной от системы, используемой для отладки.

Корпорация Майкрософт публикует все PDB-файлы для всех операционных систем и других распространяемых компонентов, таких как пакет SDK DirectX, на его внешнем доступном сервере символов. Это упрощает отладку приложения, использующего эти библиотеки DLL или исполняемые файлы. Сервер символов Майкрософт можно использовать для разрешения символов вместе с любыми локальными символами для компонентов, созданных на компьютере.

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

Чтобы использовать сервер символов, укажите путь поиска в переменной среды, которая вызывается _NT_SYМБOL_PATH. Отладчики и современные средства, такие как WinDbg, NTSD или Visual Studio, автоматически используют этот путь для поиска символов.

При поиске символов отладчик сначала выполняет локальный поиск. Затем он выглядит на серверах символов. Когда он находит соответствующий символ, он передает файл символа в локальный кэш. Символы для типичного диапазона DLL или исполняемого файла от 1 до 100 МБ размера. Таким образом, при отладке процесса, включающего множество БИБЛИОТЕК DLL, может потребоваться некоторое время для разрешения всех символов и их передачи в локальный кэш.

Использование сервера символов Майкрософт

Сервер символов Майкрософт позволяет получить все последние символы, включая символы для исправленных или обновленных файлов. Сервер символов Майкрософт доступен по адресу https://msdl.microsoft.com/download/symbols.

Доступ к серверу символов можно получить одним из следующих способов:

  • Введите адрес сервера напрямую. В Visual Studio в меню "Сервис" выберите "Параметры", а затем выберите "Отладка" и выберите "Символы".

  • Используйте переменную среды _NT_SYМБOL_PATH. Мы рекомендуем этот метод.

    Это используется всеми средствами отладки. Она также используется Visual Studio и декодируется при открытии Visual Studio. Поэтому, если изменить его, необходимо перезапустить Visual Studio.

    Эта переменная среды позволяет указать несколько серверов символов, например внутренний частный сервер символов. Кроме того, он позволяет указать каталог локального кэша для хранения PDF-файлов для всех символов, которые вы ищете с серверов символов, как внутри, так и через Интернет.

Синтаксис переменной _NT_SYМБOL_PATH:

srv*[local cache]*[private symbol server]*https://msdl.microsoft.com/download/symbols

Замените [локальный кэш] именем каталога на компьютере, в котором требуется хранить кэш любых символов, например %SYSTEMROOT%\Symbols или c:\symbols.

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

Чтобы использовать только сервер символов Майкрософт вместе с локальным кэшем символов, чтобы ускорить доступ через Интернет, используйте следующий параметр для _NT_SYМБOL_PATH:

srv*c:\symbols*https://msdl.microsoft.com/download/symbols

Другие параметры _NT_SYМБOL_PATH можно найти в файле справки, который установлен с пакетом Средств отладки Майкрософт для Windows.

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

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

Чтобы избежать даже небольшой задержки, можно запустить отладчик один раз, чтобы кэшировать все символы локально с сервера символов Майкрософт. Затем измените _NT_SYМБOL_PATH, чтобы удалить сервер символов Майкрософт. Если исполняемые файлы не изменяются, проверка для исполняемых файлов, которые не имеют символов, не потребуют запроса через Интернет, так как у вас есть локальные кэшированные копии всех символов, необходимых на сервере символов Майкрософт.

Получение символов вручную

Если отладчик настроен правильно, он автоматически загружает любые символы, необходимые для локального кэша или с сервера символов. Если вы хотите получить символы только для одного исполняемого файла или для папки исполняемых файлов, можно использовать симчк. Например, если вы хотите скачать символы для файла d3dx9_30.dll в папке Системы Windows в текущий каталог, можно использовать следующую команду:

"c:\Program Files\Debugging Tools for Windows\symchk" c:\Windows\System32\d3dx9_30.dll /oc \.

Средство symchk имеет много других вариантов использования. Дополнительные сведения см. в статье symchk /?, а также см. в документации по средствам отладки Майкрософт для Windows.

Настройка сервера символов

Настройка сервера символов очень проста. Это полезно по следующим причинам:

  • Чтобы сэкономить пропускную способность или ускорить разрешение символов для вашей компании, команды или продукта. Внутренний сервер символов в локальном файловом ресурсе в сети кэширует все ссылки на внешние серверы символов, такие как сервер символов Майкрософт. Локальный или внутренний сервер символов можно быстро получить доступ ко многим людям одновременно. Поэтому она сохраняет пропускную способность и задержку, которую могут создавать повторяющиеся запросы символов.
  • Хранение символов для старых сборок, версий или внешних выпусков приложения. Сохраняя символы для этих сборок на сервере символов, к которому можно легко получить доступ, можно отлаживать сбои и проблемы в этих сборках на любом компьютере с отладчиком и подключением к локальному серверу символов. Это особенно полезно при отладке мини-дампов, созданных исполняемыми файлами, которые вы не создали самостоятельно, то есть сборки, созданные другим программистом или компьютером сборки. Если символы для этих сборок хранятся на сервере символов, у вас будет надежная и точную отладку.
  • Чтобы сохранить символы в актуальном состоянии. При обновлении компонентов, таких как компоненты ОС, измененные Обновл. Windows или пакетом SDK DirectX, можно по-прежнему отлаживать с помощью всех последних символов.

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

Например, если вы настроили общую папку на \\mainserver\symbols, члены команды задайте _NT_SYМБOL_PATH следующим образом:

Srv*c:\symbols*\\mainserver\symbols*https://msdl.microsoft.com/download/symbols

Как извлекаются символы, файлы и папки отображаются в общем каталоге \\mainserver\symbols, а также в отдельных кэшах в каталоге c:\symbols.

Обычно это все, что участвует в настройке и использовании собственного сервера символов или сервера символов Майкрософт.

Добавление символов на сервер символов

Чтобы добавить, удалить или изменить файлы в общей папке сервера символов, используйте средство symstore.exe. Это средство входит в состав пакета Microsoft Debugging Tools для Windows. Полная документация по серверам символов, инструменту symstore и символам индексирования включается в пакет средств отладки для Windows.

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

Например, чтобы индексировать рекурсивно все символы в C:\dxsym\Extras\Symbols\Symbols, полученные из пакета SDK DirectX за октябрь 2006 года, на общую папку сервера символов с именем \\mainserver\symbols, можно использовать следующую команду:

"c:\Program Files\Debugging Tools for Windows\symstore" add /f "C:\dxsym\Extras\Symbols\*.pdb"
/s \\mainserver\symbols /t "October 2006 DirectX SDK " /r

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

Рекомендации

  • Настройте собственный файловый ресурс сервера символов для вашей команды, компании или продукта.
  • Настройте _NT_SYМБOL_PATH указывать на локальный кэш, на частный сервер символов и на сервер символов Майкрософт.
  • Если отладчик не может загружать символы для отлаживаемого компонента, обратитесь к владельцу компонента, чтобы запросить символы , по крайней мере срезаемой PDB.
  • Настройте автоматическую систему сборки для индексирования символов на частном сервере символов для каждой создаваемой сборки. Убедитесь, что распространяемые сборки являются сборками, созданными этим процессом. Это гарантирует, что символы всегда доступны для отладки проблем.
  • Настройте сервер символов, чтобы разрешить отладчикам получать доступ к исходному коду для определенного модуля непосредственно из системы управления версиями на основе Visual Source Сейф или Perforce. Если исходные сведения и символы файла для выпущенной версии игры индексируются, разработчики, имеющие доступ к серверу символов, могут выполнять полную отладку на уровне источника сообщаемых проблем без сохранения сред сборки или старых версий исходных файлов на своих компьютерах разработки. Чтобы настроить сервер символов, чтобы разрешить индексирование исходных сведений о файле, см. документацию по исходному серверу.