Microsoft windows debugging symbols что это за программа

Установка Debugging Tools for Windows

Debugging Tools for Windows — Инструменты отладки кода операционных систем Windows. Представляют собой набор свободно распространяемых программ от Microsoft, предназначенных для отладки кода пользовательского режима и режима ядра: приложений, драйверов, служб, модулей ядра. В состав инструментария входят отладчики консольного и GUI- режимов, утилиты для работы с символами, файлами, процессами, утилиты для обеспечения удаленной отладки. Инструментарий содержит в себе утилиты, с помощью которых можно находить причины сбоев в различных компонентах системы. Debugging Tools for Windows с определенного момента недоступны для скачивания в форме автономного дистрибутива и входят в состав Windows SDK (Windows Software Development Kit). Набор инструментальных средств Windows SDK, в свою очередь, доступен в виде части программы подписки MSDN или же может быть свободно загружен в качестве отдельного дистрибутива с сайта msdn.microsoft.com. По заявлению разработчиков, последняя и самая актуальная версия Debugging Tools for Windows содержится именно в Windows SDK.

Debugging Tools for Windows обновляются и выкладываются в публичный доступ достаточно часто и процесс этот никак не зависит от выпуска операционных систем. Поэтому, периодически проверяйте наличие новых версий.

Давайте теперь посмотрим, что же, в частности, позволяют нам средства Debugging Tools for Microsoft Windows:

• Отлаживать локальные приложения, службы (сервисы), драйвера и ядро;
• Отлаживать по сети удаленные приложения, службы (сервисы), драйвера и ядро;
• Отлаживать работающие приложения в режиме реального времени;
• Анализировать файлы дампов памяти приложений, ядра и системы в целом;
• Работать с системами на базе архитектур x86/x64/Itanium;
• Отлаживать программы пользовательского режима и режима ядра;

Доступны следующие версии Debugging Tools for Windows: 32-bit x86, Intel Itanium, 64-bit x64. Нам потребуются две из них: x86 либо x64.

Доступны несколько способов установки Debugging Tools for Windows, в данной же статье мы будем рассматривать лишь основные из них:

• Установка посредством web-инсталлятора.
• Установка Debugging Tools for Windows с ISO-образа Windows SDK.
• Установка Debugging Tools for Windows непосредственно из пакетов dbg_amd64.msi / dbg_x86.msi .

Остается неясен еще во какой момент, зачем мне инсталлировать отладочный инструментарий на компьютер? Зачастую ведь сталкиваешься с ситуацией, когда вмешательство в рабочую среду крайне нежелательно! И уж тем более что инсталляция нового продукта, то есть внесение изменений в реестр/файлы системы, может быть совершенно недопустима. Примерами могут служить критически-важные сервера. Почему бы разработчикам не продумать вариант с портабельными (portable) версиями приложений, не требующих установки?
От версии к версии процесс установки пакета Debugging Tools for Windows претерпевает некоторые изменения. Давайте теперь перейдем непосредственно к процессу установки и рассмотрим способы, которыми можно установить инструментарий.

Установка Debugging Tools for Windows при помощи web-инсталлятора

Переходим на страницу Архив Windows SDK и находим раздел под названием Windows 10 и ниже пункт «Windows 10 SDK (10586) и эмулятор устройства с Windows 10 Mobile (Майкрософт) (версия 10586.11)».

Щелкаем по пункту УСТАНОВИТЬ ПАКЕТ SDK . После щелчка скачиваем и запускаем файл sdksetup.exe , который и инициирует процесс онлайн-установки Windows SDK. На начальном этапе инсталятор проверит наличие в системе установленного пакета .NET Framework последней версии (в данный момент это 4.5). Если пакет отсутствует, что будет предложена установка и по окончании выполнена перезагрузка станции. Сразу после перезагрузки, на этапе авторизации пользователя, стартует процесс инсталляции уже непосредственно Windows SDK.

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

После завершения инсталляции Debugging Tools for Windows расположение файлов отладки при данном методе инсталляции у нас будет следующим:

• 64-битные версии: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
• 32-битные версии: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86

* где x.x — определенная версия комплекта разработки;
Заметили, что версии 8 и выше, пути инсталляции заметно отличаются от классических для всех предыдущих версий средств отладки?

Огромным плюсом данного способа установки Debigging Tools for Windows является установка версий отладочных средств сразу всех архитектур.

Установка Debugging Tools for Windows с ISO-образа Windows SDK

Данный метод подразумевает установку Debugging Tools for Windows с использованием полного инсталляционного образа Windows SDK (Software Developers Kit). До определенного времени, скачать образ ISO для соответствующей системы можно было на странице Архив Windows SDK. Однако, в данный момент, получить ISO-образ SDK можно через запуск web-инсталлятора sdksetup.exe , и выбора пункта Download the Windows Software Development Kit в стартовом окне инсталлятора:

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

Соответственно, на странице необходимо подобрать требуемый дистрибутив, для меня (да и думаю для многих) в данный момент это «Пакет Windows SDK для Windows 7 и .NET Framework 4» и чуть ниже нажать на ссылку «Получить ISO-образ DVD-диска».

При работе с сайтом msdn.microsoft.com советую воспользоваться браузером Internet Explorer, поскольку были замечены случаи неработоспособности конкурирующих продуктов!

Далее у нас имеется выбор между тремя вариантами образа:

Соответственно, необходимо выбрать исключительно по необходимости. Обычно разрядность Debugging Tools for Windows совпадает с разрядностью системы. У меня исследуемые системы, в основном, 64-битные, поэтому я в большинстве случаев скачиваю образ для 64-битной системы GRMSDKX_EN_DVD.iso .
Затем, после скачивания образа, нам необходимо с имеющимся ISO-образом как-то работать. Традиционным способом является, конечно же, запись компакт-диска, но ведь это достаточно долгий и иногда затратный метод. Предлагаю воспользоваться бесплатными утилитами по созданию в системе виртуальных дисковых устройств. Лично я для этой цели предпочитаю пользоваться программой DEAMON Tools Lite. У кого-то могут быть и другие предпочтения, более прямые или легковесные утилиты, на вкус и цвет, как говорится.. После инсталляции DAEMON Tools Lite, я просто щелкаю два раза на файл образа GRMSDKX_EN_DVD.iso и в системе у меня появляется новый виртуальный компакт диск:

Уже затем двойным щелчком активирую автозагрузку и запускаю инсталляцию Windows SDK:

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

Все именно так, на скриншоте отмечено две опции: «Windows Performance Toolkit» и «Debugging Tools for Windows». Выбирайте обе, потому как Windows Performance Toolkit Вам непременно пригодится в работе! Далее, после нажатия кнопки «Next» инсталляция продолжается в обычном режиме. И в конце вы увидите надпись «Installation Complete».
По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

• Для версии x86: C:\Program Files (x86)\Debugging Tools for Windows (x86)
• Для версии x64: C:\Program Files\Debugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать оконченной.

Установка Debugging Tools for Windows через .msi файл

В случае возникновения проблем при инсталляции Debugging Tools for Windows двумя предыдущими способами, у нас в запасе остается еще один, самый надежный и проверенный временем, выручавший, так сказать, не раз. Когда-то, до интеграции в Windows SDK, Debugging Tools for Windows были доступны в виде отдельного инсталлятора .msi, который и сейчас можно найти, однако уже в недрах дистрибутива Windows SDK. Поскольку у нас на руках имеется уже ISO-образ Windows SDK, то мы можем не монтировать его в систему, а просто открыть при помощи всем уже хорошо знакомого архиватора WinRAR, ну или любого другого продукта, работающего с содержимым ISO-дисков.

После открытия образа нам необходимо пройти в каталог «Setup», находящийся в корне и далее выбрать одну из директорий:

• Для установки 64-битной версии: \Setup\WinSDKDebuggingTools_amd64 и распаковать из этого каталога файл dbg_amd64.msi .
• Для установка 32-битной версии: \Setup\WinSDKDebuggingTools и распаковать из этого каталога файл dbg_x86.msi .

Далее, запускаем распакованный только что .msi файл и стартуем установку Debugging Tools for Windows.

По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

• Для версии x86: C:\Program Files (x86)\Debugging Tools for Windows (x86)
• Для версии x64: C:\Program Files\Debugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать выполненной.

Дополнительные сведения

Не знаю с чем это связано, быть может с моей невнимательностью, но после инсталляции Отладочных средств для Windows, инсталлятор не прописывает в системную переменную пути Path путь к каталогу с отладчиком. Это накладывает определенные ограничения на запуск различных отладочных задач напрямую из консоли. Поэтому, в случае отсутствия пути, я самостоятельно прописываю в окне Переменные среды путь к отладочным средствам:

• C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
• C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

* В вашем случае пути могут отличаться как по причине использования ОС другой разрядности, так и по причине использования SDK другой версии.

Утилиты пакета Debugging Tools for Windows могут работать в качестве переносных приложений, достаточно просто скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии на рабочем сервере. Но не забывайте учитывать разрядность системы!! Если Вы даже произвели полную инсталляцию пакета на критически-важную систему, то работать можно начинать прямо после инсталляции, перезагрузка не требуется.

Состав Debugging Tools for Windows

И теперь напоследок приведем состав Debugging Tools for Windows:

Источник

Отладочные символы

Что же послужило отправной точкой к написанию этого, надо заметить, достаточно узконаправленного материала? В основном желание разобраться в пока еще не до конца мною понятом процессе отладки кода, к изучению особенностей которого я в своё время приступил. Весь круг вопросов по этой теме пока еще даже в полной мере не сформировался, просто на определенном этапе стало очевидно, что не до конца осознана роль отладочных символов. До момента углубленного изучения данной темы, у меня сложилось довольно сумбурное мнение на предмет того, что основное предназначение отладочных символов — это процесс отладки, иными словами поиск проблем в программном обеспечении. Со временем, благодаря пусть даже поверхностной работе с отладочными средствами, удалось понять, что существует некая, достаточно важная составляющая отладки, именуемая отладочными символами или символами отладки, без которой вывод того же стека вызовов может превратиться в набор малопонятных адресов памяти. Чтобы подробнее разобраться в данном вопросе, давайте сделаем экскурс в прошлое. Дело в том, что когда то процесс исследования кода и вовсе не подразумевал использование каких бы то ни было сторонних файлов, облегчающих восприятие получаемого исходного кода. Исследователь видел перед собой всего-лишь «голые» адреса памяти, используемые вызовами, переменными, смещениями различных операций.

При изучении абсолютного большинства программного обеспечения, написанного для операционной системы Windows, никакой вспомогательной информацией, кроме самого исследуемого бинарного исполняемого файла, специалист не располагает. Конечно же, это создает определенные, надо сказать порой довольно ощутимые, неудобства. Но это типичная, я бы даже сказал нормальная ситуация для стороннего программного обеспечения, автором которого является третья сторона, ведь нигде не регламентировано предоставление конечному пользователю дополнительной информации помимо бинарных файлов пакета. Совсем другое дело, когда вопрос касается кода самой операционной системы Windows, где процесс исследования может помочь обнаружить ошибки в коде критичных системных модулей, или, хотя бы, получить ответ на вопрос, почему возникла та или иная ошибка. Ведь, как все мы знаем, исходный код Windows сокрыт от посторонних глаз, и по аналогии с миром Linux Вы не сможете так вот запросто получить листинг того или иного системного модуля. В свете всего этого, вопрос о предоставлении какой бы то ни было дополнительной отладочной информации, позволяющей облегчить изучение кода, является неким консенсусом между закрытостью и желанием пойти навстречу своим пользователям.

Так вот, до определенного времени никакие дополнительные файлы, облегчающие процесс отладки, исследователям кода не предоставлялись.

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

Эти данные абсолютно не применимы в ходе выполнения программы, но крайне полезны в процессе её отладки. Люди, которые не по наслышке знакомы с программированием, могут подтвердить, что компилятор, конвертируя исходный код программы в машинный код, выбрасывает имена функций. Другими словами, в получившемся исполняемом модуле Вы не увидите никаких имен. Единственный вариант получить связь между адресами и именами, это сгенерировать файл отладочных символов. Однако отладочные символы, в большинстве случаев, по умолчанию не генерируются, а могут быть созданы лишь при указании дополнительных опций компиляции.
Если пояснить данное понятие простым языком, то отладочные символы требуются (что очевидно по названию), для удобства отладки кода, а именно с целью понять что есть что в структуре изучаемого приложения.
В общем случае, в файле отладочных символов хранятся:

• Имена и адреса точек входа для функций;
• Местоположение и имена локальных переменных;
• Адреса и имена глобальных переменных;
• Информация по типам для переменных, структур и прч.;
• Объявление классов;
• Информация о нумерации строк в исходном файле и файле символов. На основании этого машинные коды могут быть сопоставлены с исходным текстом, в случае его наличия.
• соответствие между именами функций и соответствующими им адресами памяти

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

• быть представлена блоком данных, встроенным в бинарный исполняемый файл, то есть находиться внутри исполняемого файла. Не лучший способ хранения отладочных символов, поскольку иногда размер исполняемого файла может существенно увеличиваться.
• быть размещена в виде отдельного внешнего файла, находящегося либо в директории с бинарным файлом, либо в специализированной независимой директории. Подобный способ размещение символов наиболее универсален.
• вовсе отсутствовать. То есть не создаваться на этапе компиляции и/или сборки. В большинстве случаев так и происходит 🙂

Для конкретной версии исполняемого кода компилятор создает свой уникальный файл символов.

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

Нужны ли символы

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

Честно говоря, результат меня удивил. На момент ошибки мы имеем довольно скудную информацию о сбое, такую как адрес возникновения ошибки и стек вызовов момента падения. Отладчик пытается выполнить автоматический разбор стека, и что же получается, мало того, что отладчик при отсутствии отладочных символов не может сопоставить имена и параметры функций, так он еще и не может правильно выполнить трассировку стека вызовов момента падения. Выходит, что без символов становится практически невозможно (в некоторых случаях) проследить последовательность вызовов функций, и в дополнение осложняется понимание того, какой именно модуль вызвал ошибку. Именно так! Всё только что сказанное актуально для ситуации с 32-битным кодом, поскольку:

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

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

Распространение

Понятное дело, что если возникло желание символы официально предоставлять, то их необходимо каким-то образом распространять, для того, что бы конечные потребители программного продукта имели возможность (при остром на то желании конечно же) этот самый продукт отлаживать, то есть в случае возникновения ошибок иметь возможность быстро находить вероятную причину возникновения. Каким же образом отладочные символы предоставляют своей целевой аудитории? До некоторых пор разработчики, перед которыми стояла задача предоставления отладочных символов своим клиентам, передавали подобную информацию для своих продуктов на оптических носителях, дисках CD/DVD. Исключением не стала и операционная система Windows, которая может поставляться с отладочными символами, традиционно размещаемыми на дополнительном диске дистрибутива, либо в составе Driver Development Kit ( DDK ). Однако, с определенного времени популярным стал метод распространения символов через сеть Интернет. В сети для этой цели Microsoft размещает собственные сервера символов, которые и предоставляют отладочные символы, однако, чтобы работать с сервером символов, необходимо использовать специализированный протокол обмена.

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

Многие компоненты, разрабатываемые корпорацией Microsoft, такие как файлы, входящие в состав операционных систем, офисных приложений и прочих продуктов, компилируются вместе с символами, которые затем распространяются через сервер символов Microsoft (Microsoft Symbol Server). Сервер символов представляет собой онлайновый репозиторий публичных символов для продуктов Microsoft, который доступен для запроса посредством протокола HTTP по визуально-неотображаемому пути (URL):

Это доступное в сети Интернет хранилище всех символов для всех публичных продуктов, выпущенных Microsoft за последние несколько лет. Огромный плюс предоставления отладочных символов онлайн заключается в том, что все отладчики Microsoft (независимые как WinDbg , KD и поставляемые в составе продуктов, как MS Visual Studio Debugger), а так же ряд сторонних отладочных средств, теперь имеют возможность автоматически загружать символы непосредственно с сервера в зависимости от версии отлаживаемого двоичного кода. Представляется, сколько времени можно сэкономить по сравнению с ситуацией, когда Вы в ручном режиме вынуждены подцеплять символы именно той версии модуля, которую вы отлаживаете в данный момент.

Стоит отметить, что на сервере символов Microsoft предоставляют только публичные символы, то есть «урезанную» информацию по структуре бинарного кода. Исключение составляют некоторые типы в файле ntdll.dll и модули ядра.

Публичные и приватные символы

Как Вы уже поняли, информация в файлах символов может отличаться по степени полноты. По умолчанию, символьные файлы, генерируемые C/C++ компоновщиком, содержат довольно много информации об исполняемом файле, обычно больше, чем большинство разработчиков программного обеспечения готовы предоставлять своим клиентам. В связи с этим, после создания удаляют информацию по приватным символам из PDB -файлов и получают на выходе то, что называют публичными символами (public symbols) или обрезанными символами (stripped symbols). Эти «обрезанные» публичные символы не могут быть использованы для отладки в режиме исходного текста, потому что исходного текста в них попросту нет, как нет и информации по номерам строк в исходном файле. Публичные символы, так же, не включают информацию для помощи по отображению параметров большинства функций, информацию по локальным переменным, типам локальных переменных. Тем не менее, они содержат достаточно информации для ключевых отладочных сценариев, что зачастую является достаточным. Таким образом, можно сделать утешительный вывод:

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

Символьные файлы, распространяемые корпорацией Microsoft, включают в себя исключительно публичные функции, глобальные переменные и их типы данных, то есть являются публичными. В противоположность этому, некоторые разработчики программного обеспечения (Mozilla) распространяют полную отладочную информацию (публичные символы и приватные символы). Приватные (полные, закрытые) символы (private symbols) содержат значительно больше информации, включающей в себя путь и номера строк исходного кода, имена и типы параметров функций и переменных.

Формат PDB

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

• Файлы .COFF , содержащие данные в формате Common Object File Format (COFF);
• Файлы .CV , содержащие данные в формате CodeView. Формат хранения символов от Microsoft. Устаревший;
• Файлы .SYM (Symbols). Устаревший формат;
• Файлы .DBG (Debug), содержащие данные в формате COFF (Common Object File Format). Довольно распространенный формат, совместимый с большим количеством старых отладчиков. Однако, не может содержать информацию по строкам исходного кода;
• Файлы .PDB (Program Database), содержащие данные в формате MSF (Multi-Stream Files). Современный продвинутый формат, разработанный Microsoft. Может содержать намного больше информации, чем .dbg.

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

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

PDB файл служит для:

• Сопоставления идентификаторов, созданных в исходных файлах для классов, методов и другого кода, с идентификаторами, которые используются в скомпилированных исполняемых файлах;
• Сопоставления операторов в исходном коде с машинными инструкциями в исполняемом файле;
• Определения адреса памяти любой переменной, функции или строки кода.
• Определения по имени функции, переменной и номера строки кода, адреса памяти.

Для проверки совместимости между бинарным файлом и файлом символов PDB компоновщик вносит в них GUID (глобальный уникальный идентификатор), которые должны быть идентичны в обоих файлах. Если они различаются, отладчики довольно часто отказываются подключать символы. Файл отладочных символов также содержит оригинальный путь к исходным файлам и, при необходимости, адрес сервера системы управления версиями, откуда можно эти исходные файлы получить.
В настоящее время у Microsoft наиболее распространен формат PDB версии 2 (MS Visual Studio 6.0) и PDB 7.0 (MS Visual Studio 7.0+). Данные форматы, в силу своей архитектуры, позволяют получать расширенную информацию об исполняемых модулях, в том числе возможность разбора стека, получения локальных переменных и так далее. PDB-файлы содержат данные в формате MSF (Multi-Stream Files) и в них по первым 32 байтам можно обнаружить сигнатуру Microsoft C/C++ MSF 7.00\r\n\032DS\0\0 . В формате MSF вся информация хранится в потоках (аналогия с файлами в файловой системе), при этом каждый поток имеет собственный идентификатор, данные, массив номеров страниц, количество занимаемых страниц. Различные потоки хранят информацию о различных структурах символов, таких как типы переменных, функции и прочее.
Другое преимущество PDB заключается в том, что становится возможна пошаговая отладка по исходному тексту, при условии конечно же, доступности этого самого исходного текста.

На примере отладчика WinDbg можно сказать, что он «умеет» автоматически загружать файлы отладочных символов в формате PDB, с сервера посредством подбора различных критериев (метка времени, контрольная сумма (CRC), количество ядер и прч.) с помощью SymSrv ( SymSrv.dll ). Стандартный протокол поиска символов работает с сервером символов Microsoft.

Выводы

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

Источник