Offline Symbols for Windows Update

This topic describes how you can work with offline symbols for Windows Update. It describes a procedure that can be used to decode Windows Update logs on machines that don’t have access to the Microsoft symbol server.

If you find yourself needing to do this often, you should see if setting up a Symbol Proxy Server is viable for your networking configuration. For more information see SymProxy.

All the options below require you to have one machine that can connect to Microsoft’s symbol server, and have the ability to copy files to or from the machine that has the logs. The machine that doesn’t have access to the symbol server will be referred to as the offline machine, and the machine that does have access as the online machine.

We recommend using a single online machine per OS build version so the WU symbol cache will build month-by-month and contain the WU symbols from multiple update releases.

If you have access to an online machine with the same exact patch level as the offline machine, you have two options:

Verify the online and offline PCs the same version level by running winver or ver on both machines.

If you don’t have access to an online machine with the same version, you’ll need to go through some extra steps to create a SymChk manifest file, described later in this topic in Option 3: Create a SymChk manifest file.

Option 1: Copy the ETL event log to the online machine

Copy all the WindowsUpdate ETL files from C:\Windows\logs\WindowsUpdate\ to your online machine.

On the online machine, open a PowerShell prompt and run the following Get-WindowsUpdateLog PowerShell command.

This will download the symbols needed for log analysis.

Option 2: Copy the symbols to the offline machine

On the online machine, open a PowerShell prompt and run “Get-WindowsUpdateLog”. This will cache the symbols needed for log analysis.

Copy all the files in %temp%\WindowsUpdateLog\SymCache from the online machine to %temp%\WindowsUpdateLog\SymCache on the offline machine.

On the offline machine, open a PowerShell prompt and run “Get-WindowsUpdateLog” to analyze the logs.

Option 3: Create a SymChk manifest file

On the offline machine, follow steps at Using a Manifest File with SymChk to create a manifest for these files in the system32 directory:

Copy the manifest to your online machine.

With the manifest file, use SymChk to download the symbols locally to your online PC.

Copy the folder and symbols you passed to SymChk to %temp%\WindowsUpdateLog\SymCache on your offline PC.

On the offline machine, open a PowerShell prompt and run “Get-WindowsUpdateLog” to analyze the logs.

Installing Windows Symbol Files

Before you debug the Windows kernel, a driver or app, you need access to the proper symbol files. The official way to get Windows symbols is to use the Microsoft Symbol Server. The symbol server makes symbols available to your debugging tools as needed. After a symbol file is downloaded from the symbol server it is cached on the local computer for quick access.

You can connect to the Microsoft Symbol Server with one simple use of the .symfix (Set Symbol Store Path) command. For full details, see Microsoft Public Symbols.

We are no longer publishing the offline symbol packages for Windows. The faster Windows update cadence means the Windows debugging symbols are quickly made out of date. We have made significant improvements to the online Microsoft Symbol Server where symbols for all Windows versions and updates are available. You can find more about this in this blog entry.

For information on how to retrieve symbols for a machine that is not connected to the Internet, see Using a Manifest File with SymChk.

If you are going to debug a user-mode app, you need to install the symbols for this app as well.

You can debug an app if you have its symbols but not Windows symbols. However, your results will be much more limited. You will still be able to step through the app code, but any debugger activity which requires analysis of the kernel (such as getting a stack trace) is likely to fail.

Microsoft Is No Longer Providing Offline MSI Symbol Packages

Lawrence Abrams

Microsoft has stated that they are no longer offering offline symbol packages as a downloadable MSI. For those who need to download symbols to debug their applications or Windows, you will now need to connect directly to their symbol server or use the symchk utility to download them.

According to Microsoft, the MSI symbol packages are no longer being offered because they are updating Windows too fast and the packages quickly become out of date.

«With the cadence that we release updates for Windows, the Windows debugging symbols we publish via the packages on this page are quickly made out of date. We have made significant improvements to the online Microsoft Symbol Server by moving this to be an Azure-based symbol store, and symbols for all Windows versions and updates are available there.» — Microsoft

Thankfully, if you do not wish to connect directly to the symbol server, you can instead use the symchk.exe utility to download any necessary PDB files.

Symchk.exe, which is included in the Windows 10 SDK, is a program that examines an executable and confirms whether the correct symbols are available on the machine. To get symchk, you need to install the Windows 10 SDK and select to install the Debugging Tools for Windows package.

Using symchk to download symbols from Microsoft’s Symbol Server

If your computer is directly connected to the Internet, you can use symchk to analyze an executable and then automatically connect to the Microsoft symbol server and download the appropriate symbol (PDB) files.

Before we get started, we want to create a folder called C:\symbols that will be used to store the downloaded PDB files. You can then run symchk using the following command to download an executable’s associated symbol files.

As an example, if we want to download the symbol files associated with C:\Windows\system32\calc.exe and store them in C:\Symbols, we would issue the following command:

Once you execute the command, symchk will connect to Microsoft’s symbol server, search for the associated PDB files, and download them to the C:\symbol folder.

If you want to recursively download symbols for all the executables found in a particular path, you can add the «/r» command line argument. For example, to download all PDB files for executables under the C:\Windows folder, you would enter:

Once you enter this command, symchk.exe will scan all the files under C:\Windows and download the associated symbol files from Microsoft’s symbol server to C:\symbols as shown below.

Downloading Symbol Files

This process can take quite a while, so please be patient while the files are downloaded.

If you need to download symbols for a computer that is offline, you can instead follow these instructions, which utilize the /om and /im command line arguments.

Creating symbol packages (.snupkg)

A good debugging experience relies on the presence of debug symbols as they provide critical information like the association between the compiled and the source code, names of local variables, stack traces, and more. You can use symbol packages (.snupkg) to distribute these symbols and improve the debugging experience of your NuGet packages.

Note that symbol package isn’t the only strategy to make the debug symbols available to the consumers of your library. It’s also possible to embed them in the dll or exe with the following project property: embedded

Prerequisites

Creating a symbol package

If you’re using dotnet CLI or MSBuild, you need to set the IncludeSymbols and SymbolPackageFormat properties to create a .snupkg file in addition to the .nupkg file.

Either add the following properties to your .csproj file:

Or specify these properties on the command-line:

If you’re using NuGet.exe, you can use the following commands to create a .snupkg file in addition to the .nupkg file:

The SymbolPackageFormat property can have one of two values: symbols.nupkg (the default) or snupkg . If this property is not specified, a legacy symbol package will be created.

The legacy format .symbols.nupkg is still supported but only for compatibility reasons like native packages (see Legacy Symbol Packages). NuGet.org’s symbol server only accepts the new symbol package format — .snupkg .

Publishing a symbol package

For convenience, first save your API key with NuGet (see publish a package).

After publishing your primary package to nuget.org, push the symbol package as follows.

You can also push both primary and symbol packages at the same time using the below command. Both .nupkg and .snupkg files need to be present in the current folder.

NuGet will publish both packages to nuget.org. MyPackage.nupkg will be published first, followed by MyPackage.snupkg .

If the symbol package isn’t published, check that you’ve configured the NuGet.org source as https://api.nuget.org/v3/index.json . Symbol package publishing is only supported by the NuGet V3 API.

NuGet.org symbol server

NuGet.org supports its own symbols server repository and only accepts the new symbol package format — .snupkg . Package consumers can use the symbols published to nuget.org symbol server by adding https://symbols.nuget.org/download/symbols to their symbol sources in Visual Studio, which allows stepping into package code in the Visual Studio debugger. See Specify symbol (.pdb) and source files in the Visual Studio debugger for details on that process.

NuGet.org symbol package constraints

NuGet.org has the following constraints for symbol packages:

• Only the following file extensions are allowed in symbol packages: .pdb , .nuspec , .xml , .psmdcp , .rels , .p7s
• Only managed Portable PDBs are supported on NuGet.org’s symbol server.
• The PDBs and their associated .nupkg DLLs need to be built with the compiler in Visual Studio version 15.9 or above (see PDB crypto hash)

Symbol packages published to NuGet.org will fail validation if these constraints aren’t met.

Native projects, such as C++ projects, produce Windows PDBs instead of Portable PDBs. These are not supported by NuGet.org’s symbol server. Please use Legacy Symbol Packages instead.

Symbol package validation and indexing

Symbol packages published to NuGet.org undergo several validations, including malware scanning. If a package fails a validation check, its package details page will display an error message. In addition, the package’s owners will receive an email with instructions on how to fix the identified issues.

When the symbol package has passed all validations, the symbols will be indexed by NuGet.org’s symbol servers and will be available for consumption.

Package validation and indexing usually takes under 15 minutes. If the package publishing takes longer than expected, visit status.nuget.org to check if NuGet.org is experiencing any interruptions. If all systems are operational and the package hasn’t been successfully published within an hour, please login to nuget.org and contact us using the Contact Support link on the package details page.

Symbol package structure

The symbol package (.snupkg) has the following characteristics:

The .snupkg has the same id and version as its corresponding NuGet package (.nupkg).

The .snupkg has the same folder structure as its corresponding .nupkg for any DLL or EXE files with the distinction that instead of DLLs/EXEs, their corresponding PDBs will be included in the same folder hierarchy. Files and folders with extensions other than PDB will be left out of the snupkg.

The symbol package’s .nuspec file has the SymbolsPackage package type:

If an author decides to use a custom nuspec to build their nupkg and snupkg, the snupkg should have the same folder hierarchy and files detailed in 2).

The following fields will be excluded from the snupkg’s nuspec: authors , owners , requireLicenseAcceptance , license type , licenseUrl , and icon .

Do not use the
element. A .snupkg is covered under the same license as the corresponding .nupkg.

See also

Consider using Source Link to enable source code debugging of .NET assemblies. For more information, please refer to the Source Link guidance.

For more information on symbol packages, please refer to the NuGet Package Debugging & Symbols Improvements design spec.

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

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

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

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

или, иными словами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формат 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 заключается в том, что становится возможна пошаговая отладка по исходному тексту, при условии конечно же, доступности этого самого исходного текста.

Выводы

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