Microsoft windows debugging symbols что это за программа - Доктор Windows

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

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

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

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

Отладочные символы (файлы идентификаторов, символы отладки, debug-символы или symbol files) — это определенным образом сконструированный блок данных, генерируемый компилятором языка программирования на основе исходного кода программы на этапе сборки (линковки), содержащий информацию о том, какие элементы (имена переменных, функций) и где располагаются в соответствующем бинарном исполняемом модуле.

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

Отладочные символы используются средствами отладки для сопоставления адресов (смещений) в исполняемых модулях (.EXE или .DLL) с именами/вызовами функций в этих файлах.

таким образом:

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

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

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

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

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

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

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

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

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

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

В процессе отладки 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):

http://msdl.microsoft.com/download/symbols

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

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

Формат 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.00rn32DS. В формате MSF вся информация хранится в потоках (аналогия с файлами в файловой системе), при этом каждый поток имеет собственный идентификатор, данные, массив номеров страниц, количество занимаемых страниц. Различные потоки хранят информацию о различных структурах символов, таких как типы переменных, функции и прочее.
Другое преимущество PDB заключается в том, что становится возможна пошаговая отладка по исходному тексту, при условии конечно же, доступности этого самого исходного текста.

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

Выводы

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

Источник

Содержание

Microsoft Windows debugging symbols можно ли удалить?
Как установить и настроить WinDBG для анализа BSOD
Загрузка и установка WinDBG
Ассоциированние .dmp файлов с WinDBG
Debugging: Развертывание сервера отладочной информации
1. Подготовка окружения
2. Организация хранилища отладочной информации
3. Организация доступа к хранилищу отладочной информации через протокол http
4. Инсталляция прокси-фильтра для обновления символов через интернет
5. Настройка параметров прокси сервера для symproxy.dll
6. Настройка клиентских компьютеров на работу с сервером отладочной информации
Резюме
Заключение
Отладочные символы
Нужны ли символы
Распространение
Публичные и приватные (частные) символы
Сервер символов Microsoft
Формат PDB
Выводы

Microsoft Windows debugging symbols можно ли удалить?

Как установить и настроить WinDBG для анализа BSOD

Инструмент WinDBG от Майкрософт необходим для загрузки и анализа файлов .dmp, которые создаются когда возникает синий экран BSoD (сообщение о критической системной ошибке). Последняя версия WinDBG работает в Windows 10, Windows 8.x, Windows 7 и Windows Vista.

В этой статье рассмотри где скачать, как установить и настроить WinDBG.

Загрузка и установка WinDBG

1.Откройте страницу загрузки и нажмите левой клавишей мыши на «Скачать отдельный пакет SDK»;

2.Откройте скачанный файл sdksetup.exe;

3.Здесь вы можете выбрать место для установки или оставить его по умолчанию, нажмите Next;

4.Примите лицензионное соглашение, нажав на Accept;

5.Поставьте галочки в поля Debugging Tools for Windows и .Net.Framework 4.6.. …, после чего нажмите Install;

6.После завершения установки нужно нажать на Close.

Ассоциированние .dmp файлов с WinDBG

1.Откройте командную строку от имени администратора: один из способов, нажмите на меню «Пуск» правой клавишей мыши и выберите «Командная строка (администратор)».

2.Если вы во время установки WinDBG не меняли путь установки, то скопируйте одну из ниже перечисленных команд и вставьте в командную строку. Если вы изменили путь установки — измените его в команде. В 32-х разрядной системе нужно написать команду cdProgram FilesWindows Kits10Debuggersx86 и нажать Enter. В 64х-разрядной системе нужно написать команду cdProgram Files (x86)Windows Kits10Debuggersx64 и нажать Enter. Если вы не знаете разрядность вашей системы — читайте статью 32-разрядная или 64-разрядная Windows?.

3.Теперь в командной строке нужно написать команду windbg.exe -IA и нажать Enter.

Если команду вы написали без ошибок, то в результате появится окно подтверждение (смотрите рисунок), нажмите «ОК». Окно командной строки можете закрывать.

Настроить путь к символам.

WinDBG ищет символы каждый раз , когда он читает двоичный файл в файле .dmp BSOD, и нам нужно указать где ему их искать.

1.Откройте WinDBG: зайдите в меню «Пуск» => Все приложения => Windows Kits => WinDBG (x86).

2.В открывшемся окне зайдите в File => Symbol File Path.

3. Вставьте следующую строку SRV*C:SymCache*http://msdl.microsoft.com/download/symbols и нажмите «ОК».

Что данная строка означает: создается папка с именем C: SymCache и в нее загружаются новые символы с сайта MSDL.

4. Открой File => Save Workspace. Закройте WinDBG.

На сегодня всё, если у вас есть дополнения — пишите комментарии! Удачи Вам

Debugging: Развертывание сервера отладочной информации

Копая залежи документов на своем рабочем компе обнаружил инструкцию по развертыванию сервера отладочной информации, которую писал два-три года назад. Попробую представить её хабросообществу. Данная инструкция будет полезна C++ разработчикам под Windows, которые хотят использовать отладку релизных версий своего продукта (удаленно и напрямую, на своих компах и компах тестировщиков), а также делать разбор крашдампов (postmortem debugging).

1. Подготовка окружения

Для развертывания хранилища отладочных сиволов понадобится: Следует установить дистрибутив Debugging Tools For Windows (будем считать, что дистрибутив установлен в папку “C:Program FilesDebugging Tools For Windows”), и установить все дистрибутивы отладочных символов операционных систем в какую либо папку (будем считать, что они установлены в папку “C:TempSymbols”).

2. Организация хранилища отладочной информации

Хранилище символов будем организовывать используя сервер отладочной информации symsrv.dll компании Microsoft. Для этого создадим папку для хранилища символов, например C:Symbols. Далее следует установить на неё права на чтение для любых пользователей компьютера. Следующим шагом станет добавление файлов отладочных символов в хранилище. Для этого используем программу “symstore.exe” из комплекта Debugging Tools For Windows. Выполним следующую команду:

symstore add /r /3 /f c:TempSymbols*.* /s c:Symbols /compress

данная команда пройдет по всем вложеным папкам каталога “c:TempSymbols” и скопирует оттуда бинарные файлы и файлы с отладочной информацией в трёхуровневое хранилище символов расположенное в папку “C:Symbols”. Архивирует их и создаст индексные файлы для ускорения доступа и хранения информации о транзакциях доступа на изменение хранилища. Описание ключей этой команды:

add – добавить файлы в хранилище.
/r – рекурсивно обходить папку с файлами символов.
/3 – организовывать трёхуровневое хранилище (для ускорения доступа к файлам)
/f [path] – путь к файлам добавляемым в хранилище.
/s [path] – путь к хранилищу.
/compress – создавать архивированное хранилище (для сбережения дискового пространства)

Команда будет выполнятся достаточно долго и результатом её выполнения будет создание хранилища отладочной информации в папке “C:Symbols”. После данного этапа папку “C:TempSymbols” можно удалить.

3. Организация доступа к хранилищу отладочной информации через протокол http

На данном этапе следует настроить Internet Information Services на предоставление доступа к хранилищу. Вначале следует создать виртуальную папку:

Откроем “Start->Administrative Tools->Internet Information Services (IIS) Manager”.
Развернем папку”Web Sites”.
В контекстном меню элемента “Default Web Site “выберем пункт “New->Virtual Directory…”
В окне приветствия щелкнем “Next”.
В поле “Alias” введём “ Symbols” и нажмем кнопку “Next”.
В поле “Path” введём “C:Symbols” и нажмем кнопку “Next”.

Уберём галочку с поля “Run scripts” и “Browse”.

Нажмем кнопку “Next” и “Finish”.

Далее следует настроить типы MIME.

В контектстном меню виртуальной папку “Symbols” выберем пунт “Properties”.
Выберем вкладку “HTTP Headers”.
Щёлкнем кнопку “MIME Types”.
Щелкнем кнопку “Next”.
В поле “Extension” введём “*”.
В поле “Mime type” введём “application/octet-stream”.
Щелкнем кнопку “Ok” чтобы выйти из окна “MIME Types”.
Щелкнем кнопку “Ok” чтобы выйти из окна “Properties”.

4. Инсталляция прокси-фильтра для обновления символов через интернет

Прокси-фильтр нужен для того чтобы отладчик не нешедший необходимые ему файлы отладочных символов попытался взять из из публичного хранилища Microsoft, тем самым выполнив обновление хранилища символов. Прокси фильтр предоставляемый компанией Microsoft в наборе Debugging Tools For Windows является ISAPI расширением и находится в каталоге “C:Program FilesDebugging Tools For Windowssymproxy”. Установим прокси фильтр:

Скопируем из каталога “C:Program FilesDebugging Tools For Windowssymproxy” файлы “symproxy.dll “и “symsrv.dll“ в папку “%WINDIR%system32inetsrv”.

Создадим пустой файл “%WINDIR%system32inetsrvsymget.yes”.

Внесём данные из файла “С:Program FilesDebugging Tools For Windowssymproxysymproxy.reg” в реестр.

Зайдем в редактор реестра и найдем ключ “HKLM/Software/Microsoft/Symbol Server Proxy/Web Directories/symbols”.

Изменим значение “SymbolPath” на “C:symbols;http://msdl.microsoft.com/download/symbols”.

Далее зарегистрируем прокси-фильтр как источник событий создав ключ реестра “HKLMSYSTEMCurrentControlSetServicesEventLogApplicationSymProxy” и добавив туда REG_EXPAND_SZ значение с именем “EventMessageFilter” и значением “%WINDIR%system32inetsrvsymproxy.dll”.

Настроим IIS на работу с прокси-фильтром:

Откроем “Start->Administrative Tools->Internet Information Services (IIS) Manager”.
В контекстном меню элемента “Application Pools выберем New->Application Pool”.
В поле “Application ID” введём “SymSrv Pool”. И нажмем Ok.

В контекстном меню элемента “SymSrv Pool” выберем пункт “Properties”.

Выберем вкладку “Identity”, выберем радио-кнопку “Predefined” и в комбо-боксе выберем пункт “Network Service” и нажмем Ok.

Развернем ветку “Web Sites->Default Web Site”.

В контекстном меню элемента “Symbols” выберем пункт “Properties”.

На вкладке “Virtual Directory” нажмем кнопку “Create”.

В комбо-боксе “Application Pool” выберем “SymSrv Pool” и нажмем Ok.

В контекстном меню “Default Web Site” выберем пункт “Properties”.

Выберем вкладку “ISAPI Filters” и нажмем кнопку “Add”.

В поле “Filter Name” напишем “SymProxy”, в поле “Executable” введем “%WINDIR%system32inetsrvsymproxy.dll”.

Нажмем “Ok” чтобы закрыть окно “Filter Properties”.

Нажмем “Ok” чтобы закрыть окно “Default Web Site Properties”.

Запустим файл “iisreset.exe” чтобы рестартовать IIS с новыми настройками.

5. Настройка параметров прокси сервера для symproxy.dll

В Debugging Tools For Windows есть недочет, связанный с тем, что “symproxy.dll” не перенаправляет вызовы на получение сжатых файлов отладочных символов на сайт Microsoft если “symproxy.dll” работает с интернетом напрямую (без прокси сервера). Для того чтобы устранить данный дефект необходимо поставить локальный прокси сервер и с помощью утилиты “proxycfg.exe” настроить систему на работу с прокси сервером.

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

На каждом клиентском компьютере (компьютере разработчика) следует создать папку для кеширования символов, например “C:LocalSymbols”. Установить дистрибутив Debugging Tools For Windows и создать переменные окружения:

[local_repository] – это локальный кеш символов, например “C:Symbols”.
[symbol_server_ip] – IP адрес или доменное имя корпоративного сервера отладочной информации.

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

Резюме

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

На компьютерах девелоперов у вас будет организован локальный репозиторий символов, которые будут скачиваться с вашего сервера символов по требованию отладчика (Visual Studio, WinDbg и т.п.). Для полноты работы символьного сервера вам остается только добавить в вашу систему сборки:

настройку создания файлов отладочной информации (*.

pdb)

вызов «symstore» для того чтобы отладочная информация о ваших компонентах и сами компоненты попали на ваш сервер.

Заключение

Данная инструкция, как я и говорил, была написана 2-3 года назад, поэтому там фигурирует компьютер с Win2003, думаю вам не составит труда по аналогии развернуть сервер символов на Win2008 и последней версии IIS. Да и виртуалки, на которой можно было бы снять скриншоты настроки, тоже не оказалось. Но описание достаточно детальное, поэтому думаю что вы разберетесь.

Возможно проблема описанная в пункте 5 уже не актуальна, я не проверял.

Более детальную информацию по работе с серверами отладочной информации можно почерпнуть их хелп файла Debugging Tools For Windows, для затравки скажу что ещё можно привязать ваш сервер отладочной информации с сервером хранения исходников, и тогда при разборе крашдампа вы сможете видеть не только стек падения программы, но и место в исходниках, валидных на момент сборки.

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

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

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

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

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

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

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

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

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

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

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

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

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

Формат PDB

Файлы .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.

Публичные символы: все функции, статические и глобальные переменные;
Список объектных файлов которые отвечают за секции кода в исполняемом файле;
Информация о оптимизации указателя фрейма стека (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.00rn32DS . В формате MSF вся информация хранится в потоках (аналогия с файлами в файловой системе), при этом каждый поток имеет собственный идентификатор, данные, массив номеров страниц, количество занимаемых страниц. Различные потоки хранят информацию о различных структурах символов, таких как типы переменных, функции и прочее.
Другое преимущество PDB заключается в том, что становится возможна пошаговая отладка по исходному тексту, при условии конечно же, доступности этого самого исходного текста.

Выводы

Источник

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

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

При сбоях Windows обычно создается так называемый “дамп памяти”. Последний можно исследовать с помощью бесплатного отладочного инструмента Windows Debugging Tools, который может направить вас на источник проблемы. Поэтому, все, что вам необходимо сделать, это:

Скачать себе отладочный инструмент

Скачать Windows Debugging Tools можно непосредственно с сайта Microsoft. Программа работает с множеством операционных систем, начиная с Windows NT 4 и оканчивая Windows 2008, поэтому проблем с ней у вас возникнуть не должно. Да, нельзя сказать, что она стабильна под Windows 7 RC, однако по нашим тестам все-таки работает. Поэтому даже попытка диагностирования проблемы из под Windows 7 RC может оказаться удачной.

Сконфигурировать свою систему

Необходимо, чтобы во время сбоев ваш компьютер создавал дампы памяти, которые в дальнейшей послужат источником информации для отладчика. Поэтому важно, чтобы Windows была настроена на генерацию дампов. Чтобы настроить свою операционную систему, кликните правой кнопкой мыши по Своему компьютеру (Computer) и выберите Свойства (Properties). Затем кликните по вкладке дополнительных параметров Дополнительно (Advanced System Settings), на ней найдите подраздел Загрузка и Восстановление системы (Startup and Recovery Settings) и убедитесь, что параметр Запись отладочной информации (Write debugging information) установлен в состояние Дамп памяти ядра (Kernel memory dump) или Полный дамп памяти (Complete memory dump).

Далее кликните Пуск (Start), перейдите в Программы (All Programs), выберите Debugging Tools и запустите WinDbg. В программе пройдите в меню File и выберите Symbol File Path… Затем напишите в открывшемся окне следующую строку:

SRV*c:symbols*http://msdl.microsoft.com/download/symbols

Последняя определяет путь к специальным данным — так называемым “символам” (symbols), которые могут помочь отладочному инструменту в опознании вашего сбойного файла.

После ввода строки, кликните по кнопке OK. В последствии при работе с отладчиком эта строка вызовет скачивание символов с msdl.microsoft.com и сохранение их в папку c:symbols.

Далее еще раз кликните по меню File, выберите Exit и подтвердите сохранение своей рабочей области (имеется в виду пути к символам) нажатием кнопки Yes.

Решить свою проблему

Теперь подождите очередного сбоя с синим экраном, и последующего окончания перезагрузки компьютера. Затем еще раз запустите WinDbg (пользователям Vista необходимо запускать программу от имени администратора), кликните по меню File, выберите открытие сбойного дампа Open Crash Dump, откройте файл WindowsMEMORY.DMP, и программа незамедлительно начнет его анализировать.

К сожалению, WinDbg предоставляет очень мало информации о том, что она делает, поэтому вы можете даже подумать, что программа зависла. Однако подождите. Поймите, анализ, скажем, 4GB памяти на не очень мощном компьютере может занять некоторое время, вплоть до часов. Поэтому наберитесь терпения, а лучше оставьте анализ на ночь.

Впрочем, обычно результат получается уже через несколько минут. Об этом свидетельствует строка анализатора ошибки Bugcheck Analysis, сообщающая нечто вроде «Probably caused by: UACReplace.sys». В переводе на русский это означает, что проблема, возможно, вызвана файлом UACReplace.sys. Введите его в строку поиска, например, Google и вы узнаете его реальное происхождение. В частности, если он принадлежит одной из установленных вами программ или установленному драйверу, то вы можете просто попытаться обновить ее или его. Возможно, это решит возникшие у вас проблемы.

Надо сказать, что время от времени WinDbg не может назвать имени файла совсем или просто выбирает одну из DLL-библиотек Windows. Если это произошло и у вас, то просто кликните по командному окну над панелью статуса и наберите команду:

!analyze –v

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

Если же и в этот раз вам не повезет, не отчаивайтесь. Отладка является довольно сложным делом даже для экспертов. Поэтому просто закройте WinDbg и запустите анализатор снова после следующего сбоя. Возможно, это даст вам несколько больше информации. Удачи!

Источник

предисловие

Windbg — это просто программа для отладки пользовательского режима / режима ядра под Windows и анализа файлов Core Dump. Для анализа Crash, утечки ресурсов, взаимоблокировок и других проблем Windbg является мощным инструментом.

Во-первых, скачать

Windbg, предоставленный официальным веб-сайтом Microsoft, является версией Windows 10, которую нельзя использовать под Win 7. Чтобы использовать Windbg под Win7, вам нужно скачать его через Windows SDK.//www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en

устанавливать

Если вас не интересует другое содержимое Windows SDK, вы можете просто проверить Windbg.

После завершения установки вы можете найти Windbg в строке меню Windows Пуск.

Установка может быть неудачной. Если она не удалась, вы можете перейти в Панель управления Программы Программы и компоненты « Microsoft Visual C++ 2010 RedistributableУдалите, установка прошла успешно.

Начните с Windbg

Официальный сайт Microsoft предоставляет подробные учебные пособия, перейдите по ссылке:https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/getting-started-with-windows-debugging

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

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

Для режима отладки ядра, пожалуйста, обратитесь к:

Для отладки пользовательского режима, пожалуйста, обратитесь к:Getting Started with WinDbg (User-Mode).

Кроме того, вам необходимо сделать следующее:

Настройте таблицу символов. Чтобы использовать все расширенные функции, предоставляемые WinDbg, должна быть загружена правильная таблица символов. Может относиться к:Symbols for Windows debugging (WinDbg, KD, CDB, NTSD)。Таблица символов в Windows отладки
Настройте исходный код. Если вашей целью является отладка собственного исходного кода, вам необходимо настроить исходный путь.

Таблица символов в Windows отладки

О таблицах символов

Таблица символов и файл символов

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

Глобальные переменные
Локальная переменная
Имена функций и адреса их указателей сущностей
Таблица указателей кадров
Строки исходного кода

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

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

Суффикс Windows pdb сохраняет символы, а vs сохраняет все символы в файлах pdb.

Получить таблицу символов для отладки

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

Чтобы упростить трудности, файлы символов собираются в хранилище символов, которое можно получить через сервер символов. Хранилище символов — это набор файлов символов, индекс и инструмент для добавления и удаления файлов администраторами. Эти файлы индексируются некоторыми уникальными параметрами, такими как отметка времени или размер изображения.Debugging Tools for Windows contains a symbol store creation tool called SymStore. Debugging Tools for Windows contains a symbol server called SymSrv.

Таблица символов конфигурации

Официальный сайт Microsoft более эвфемичен и не прост в управлении. Вот простой метод настройки.

Добавьте каталог установки windbg в переменную окружения Path. Например: C: Program Files Средства отладки для Windows (x64)
Создайте новое значение переменной среды _NT_SYMBOL_PATH: SRV*c:mysymbol* http://msdl.microsoft.com/download/symbols

Это предложение сообщает WinDbg, что мой файл символов хранится в папке c: mysymbol. На самом деле в нем ничего нет, даже эта папка не существует, но это не имеет значения. Если система не может найти ее, она создаст ее и загрузит по указанному выше URL-адресу. Перейти, чтобы помочь вам загрузить файл символов в нем.

Перезагрузите компьютер

После перезагрузки компьютера, если вы найдете дополнительный файл mysymbol на диске C и откроете exe-файл с помощью windbg, вы увидитеSymbol search path is: SRV*c:mysymbol* http://msdl.microsoft.com/download/symbolsПодсказка указывает, что конфигурация прошла успешно.

Примечание: После выполнения этого шага, если вы снова запустите VS, VS прочитает переменную среды _NT_SYMBOL_PATH и загрузит и прочитает из нее символ, что приведет к очень медленному запуску и отладке VS. Рекомендуется изменить _NT_SYMBOL_PATH на другое имя, когда Windbg не используется.

Как отладчик распознает таблицу символов
Проблемы с символами при отладке

Начало работы с отладкой в пользовательском режиме

Отладка вашей собственной программы

Предположим, вы написали следующую программу

void MyFunction(long p1, long p2, long p3)

{

    long x = p1 + p2 + p3;

    long y = 0;

    y = x / p2;

}

void main()

{

    long a = 2;

    long b = 0;

    MyFunction(a, b, 5);

}

(1) Используйте Visual studio 2015 для создания Helloworld.exe в x64 и режиме отладки, а также Helloworld.pdb.

(2) Скопируйте Helloworld.pdb в локальную папку символов (обратитесь к:Таблица символов конфигурации）。

(3) Откройте Helloworld.exe и Helloworld.cpp с помощью windbg.

Затем вы можете ввести команды отладки, например:

bu HelloWorld!main

Средства установки точки останова в главном модуле HelloWorld

Запустите программу

Нажмите F11 для одношаговой отладки, пока программа не запустится доy = x / p2Вылетит с сообщением об ошибке вроде этого:

(3058.3830): Integer divide-by-zero — code c0000094 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

HelloWorld!MyFunction+0x53:

00000001`3f2a16d3 f7bd28010000 idiv eax,dword ptr [rbp+128h] ss:00000000`0014f648=00000000

Это означает, что произошла ошибка деления на 0.

（4）!analyze -v

Будет сгруппирован анализ ошибок.

Блокнот отладки

Обязательным условием для этого раздела является настройка символа (ссылка:Таблица символов конфигурации）。

Откройте notepad.exe с помощью windbg, обычно вC:WindowsSystem32Как показано на рисунке:

пробег.reload, Найти и загрузить символы
x notepad!WinMain

Найти все сWinMainсогласованиеsymbols。

bu notepad!WinMain Установить точку останова
bl Показать информацию о точках останова, которые были установлены
g Запустите программу до точки останова, сбоя или завершения программы.
lm Показать модули, загруженные программой «Блокнот»
kОтобразить трассировку стека текущего потока, то есть таблицу структуры вызова функции
g Продолжай бежать
Нажмите кнопку остановки в строке меню, чтобы остановить отладку
bu ntdll!ZwWriteFile Установить новую точку останова
bl Показать информацию о точке останова
~ Посмотреть все темы текущей программы
~0s

Выше две команды могут войти0Хороший прогресс и просмотр трассировки стека

qdВыйти из отладки

Источник

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

Внимание! Аварийный дамп не создается, если отказала дисковая подсистема или критическая ошибка возникла на начальной стадии загрузки Windows.

Содержание:

Типы аварийных дампов памяти Windows
Как включить создание дампа памяти в Windows?
Установка WinDBG в Windows
Настройка ассоциации .dmp файлов с WinDBG
Настройка сервера отладочных символов в WinDBG
Анализ аварийного дампа памяти в WinDBG

Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

Мини дамп памяти (Small memory dump) (256 КБ). Этот тип файла включает минимальный объем информации. Он содержит только сообщение об ошибке BSOD, информацию о драйверах, процессах, которые были активны в момент сбоя, а также какой процесс или поток ядра вызвал сбой.
Дамп памяти ядра (Kernel memory dump). Как правило, небольшой по размеру — одна треть объема физической памяти. Дамп памяти ядра является более подробным, чем мини дамп. Он содержит информацию о драйверах и программах в режиме ядра, включает память, выделенную ядру Windows и аппаратному уровню абстракции (HAL), а также память, выделенную драйверам и другим программам в режиме ядра.
Полный дамп памяти (Complete memory dump). Самый большой по объему и требует памяти, равной оперативной памяти вашей системы плюс 1MB, необходимый Windows для создания этого файла.
Автоматический дамп памяти (Automatic memory dump). Соответствует дампу памяти ядра с точки зрения информации. Отличается только тем, сколько места он использует для создания файла дампа. Этот тип файлов не существовал в Windows 7. Он был добавлен в Windows 8.
Активный дамп памяти (Active memory dump). Этот тип отсеивает элементы, которые не могут определить причину сбоя системы. Это было добавлено в Windows 10 и особенно полезно, если вы используете виртуальную машину, или если ваша система является хостом Hyper-V.

Как включить создание дампа памяти в Windows?

С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы» (Advanced system settings). Во вкладке «Дополнительно» (Advanced), раздел «Загрузка и восстановление» (Startup and Recovery) нажмите кнопку «Параметры» (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал» (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа» (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).

В большинстве случаев для анализа причины BSOD вам будет достаточно малого дампа памяти.

Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger).

Установка WinDBG в Windows

Утилита WinDBG входит в «Пакет SDK для Windows 10» (Windows 10 SDK). Скачать можно здесь.

Файл называется winsdksetup.exe, размер 1,3 МБ.

WinDBG для Windows7 и более ранних систем включен в состав пакета «Microsoft Windows SDK for Windows 7 and .NET Framework 4». Скачать можно здесь.

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

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации .dmp файлов с WinDBG

Для того, чтобы открывать файлы дампов простым кликом, сопоставьте расширение .dmp с утилитой WinDBG.

Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы:
cd C:Program Files (x86)Windows Kits10Debuggersx64 windbg.exe –IA

для 32-разрядной системы:
C:Program Files (x86)Windows Kits10Debuggersx86 windbg.exe –IA
В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.

Настройка сервера отладочных символов в WinDBG

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

Откройте WinDBG;
Перейдите в меню File –> Symbol File Path;
Пропишите строку, содержащую URL для загрузки символов отладки с сайта Microsoft и папку для сохранения кэша:
SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols
В примере кэш загружается в папку E:Sym_WinDBG, можете указать любую.
Не забывайте сохранить изменения в меню File –> Save WorkSpace;

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

SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:Symbols

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.

Анализ аварийного дампа памяти в WinDBG

Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.

Команды вводятся в командную строку, расположенную внизу окна.

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.

Полный справочник ошибок можно посмотреть здесь.

Отладчик предлагает выполнить команду !analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?

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

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !analyze –v (листинг неполный).

1: kd>
!analyze -v

***************************************************************************** * * * Bugcheck Analysis * * * *****************************************************************************

Символическое имя STOP-ошибки (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)

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

A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.

Аргументы ошибки:

Arguments: Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove). Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck Arg4: 0000000000000000, Reserved Debugging Details: ------------------

Счетчик показывает сколько раз система упала с аналогичной ошибкой:

CUSTOMER_CRASH_COUNT: 1

Основная категория текущего сбоя:

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Код STOP-ошибки в сокращенном формате:

BUGCHECK_STR: 0x139

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

PROCESS_NAME: sqlservr.exe

CURRENT_IRQL: 2

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application. EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

STACK_TEXT: ffffd000`3a20d2a8 fffff804`0117d6a9 : 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528 : nt!KeBugCheckEx ffffd000`3a20d2b0 fffff804`0117da50 : ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2 : nt!KiBugCheckDispatch+0x69 ffffd000`3a20d3f0 fffff804`0117c150 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiFastFailDispatch+0xd0 ffffd000`3a20d5d0 fffff804`01199482 : ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9 : nt!KiRaiseSecurityCheckFailure+0x3d0 ffffd000`3a20d760 fffff804`014a455d : 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951 : nt! ?? ::FNODOBFM::`string'+0x17252 ffffd000`3a20d8c0 fffff804`013a34ac : 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600 : nt!IopSynchronousServiceTail+0x379 ffffd000`3a20d990 fffff804`0117d313 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380 : nt!NtWriteFile+0x694 ffffd000`3a20da90 00007ffb`475307da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 000000ee`f25ed2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`475307da

Участок кода, где возникла ошибка:

FOLLOWUP_IP: nt!KiFastFailDispatch+d0 fffff804`0117da50 c644242000 mov byte ptr [rsp+20h],0 FAULT_INSTR_CODE: 202444c6 SYMBOL_STACK_INDEX: 2 SYMBOL_NAME: nt!KiFastFailDispatch+d0 FOLLOWUP_NAME: MachineOwner

Имя модуля в таблице объектов ядра. Если анализатору удалось обнаружить проблемный драйвер, имя отображается в полях MODULE_NAME и IMAGE_NAME:

MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe

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

1: kd>
lmvm nt

Browse full module list Loaded symbol image file: ntkrnlmp.exe Mapped memory image file: C:ProgramDatadbgsymntoskrnl.exe5A9A2147787000ntoskrnl.exe Image path: ntkrnlmp.exe Image name: ntkrnlmp.exe InternalName: ntkrnlmp.exe OriginalFilename: ntkrnlmp.exe ProductVersion: 6.3.9600.18946 FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Например:

Image path: SystemRootsystem32driverscmudaxp.sys Image name: cmudaxp.sys

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

Источник

В ОС Windows очень часто случаются ошибки, даже в случае с «чистой» системой. Если обычные ошибки программ решить можно (появляется сообщение о недостающем компоненте), то исправить критические ошибки будет намного сложнее.

Для решения проблем с системой обычно используют аварийный дамп памяти – это снимок части или полного объема оперативной памяти и помещение его на энергонезависимый носитель (жёсткий диск). Другими словами, содержимое оперативной памяти полностью или частично копируется на носитель, и пользователь может провести анализ дампа памяти.

Существует несколько видов дампов памяти:

Малый дамп (Small Memory Dump) – сохраняет минимальный объем ОЗУ, где находятся сведения по критическим ошибкам (BSoD) и компонентах, которые были загружены во время работы системы, например, драйвера, программы. MiniDump хранится по пути C:WindowsMinidump.

Полный дамп (Complete Memory Dump) – сохраняется полный объем ОЗУ. Это значит, что размер файла будет равен объему оперативной памяти. Если места на диске мало, будет проблематично сохранить, например, 32 Гб. Также бывают проблемы с созданием файла дампа памяти более 4 Гб. Данный вид используется очень редко. Храниться по пути C:WindowsMEMORY.DMP.

Дамп памяти ядра – сохраняется только информация, относящаяся к ядру системы.

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

Информация в реестре

Если заглянуть в реестр Windows, то можно обнаружить некоторые полезные параметры снимков. Щелкаем сочетание клавиш Win+R, вводим команду regedit и открываем следующие ветки:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCrashControl

В данной ветке пользователь обнаружит следующие параметры:

AutoReboot – активация или отключение перезагрузки после создания синего экрана смерти (BSoD).
DumpFile – название видов дампов и расположение.
CrashDumpEnabled – номер создаваемого файла, например, число 0 – дамп не создается; 1 – создание полного дампа; 2 – создание дампа ядра; 3 – создание малого дампа.
DumpFilters – параметр позволяет добавить новые функции перед созданием снимка. Например, шифрование файла.
MinidumpDir – название малого дампа и его расположение.
LogEvent – активация записи сведений в системный журнал.
MinidumpsCount – задать количество создаваемых малых дампов. (Превышение этого количества будет уничтожать старые файлы и заменять их).
Overwrite – функция для полного дампа или системного. При создании нового снимка, предыдущий будет всегда заменяться на новый.
DedicatedDumpFile – создание альтернативного файла снимка и указание его пути.
IgnorePagefileSize – используется для временного расположения снимка, без использования файла подкачки.

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

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

Обычно файл сохраняется в выделенном для файла подкачки блоке жёсткого диска, после появления BSoD файл перезаписывается в тот вид, который пользователь сам и настроил (Малый, полный или дамп ядра). Хотя, в современных ОС участие файла подкачки не обязательно.

Как включить дампы

В Windows 7:

Запускаем Мой компьютер и в свободном месте нажимаем правой кнопочкой мышки, выбираем пункт «Свойства».
В открывшемся окошке о системе слева переходим в раздел «Дополнительные параметры системы».
На следующем этапе переходим на вкладку «Дополнительно» и щелкаем по третьей кнопке «Параметры» в области «Загрузка и восстановление».
Настраиваем параметры по вашему желанию. Обязательно должен быть выбран какой-либо тип.
Нажимаем ОК.

В Windows 8 и 10:

Здесь процесс немного похож, в сведения о системе можно попасть точно также, как в Windows 7. В «Десятке» обязательно открываем «Этот компьютер», нажимаем по свободному месту правой кнопочкой мышки и выбираем «Свойства». По-другому туда можно попасть через Панель управления.

Второй вариант для Windows 10:

Щелкаем клавиши Win+I, открываются параметры ОС.
Переходим в раздел «Система».
Слева в самом низу выбираем подраздел «О системе».
В правой части окна опускаемся в низ и щелкаем по ссылке «Сведения о системе».
Слева выбираем «Дополнительные параметры системы».
Во вкладке «Дополнительно» нажимаем третью кнопку «Параметры».
Выбираем нужный файлик и жмём ОК.

Следует заметить, что в новых версиях Windows 10 появились новые пункты, которых не было в «семерке»:

Малый дамп памяти 256 КБ – минимальные данные о сбое.
Активный дамп – появился в десятой версии системы и сохраняет только активную память компьютера, ядра системы и пользователя. Рекомендуется использовать на серверах.

Как удалить дамп

Достаточно зайти в каталог, где хранятся снимки памяти и попросту удалить их. Но есть и другой способ удаления – использование утилиты очистки диска:

Открываем с помощью комбинации клавиш Win+R окошко «Выполнить» и прописываем команду cleanmgr.
Ищем кнопочку «Очистить системные файлы» и жмём по ней.
Если есть пункт о файлах дампов памяти, выделяем и очищаем.

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

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

Анализ дампа памяти при помощи WinDbg

Скачиваем с официального сайта Microsoft данную программу на шаге 2, где описана «Установка WDK» — https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk.

Чтобы работать с программой еще понадобиться специальный пакет отладочных символов. Он называется Debugging Symbols, раньше его можно было скачать с сайта Microsoft, но теперь они отказались от этой идеи и придется использовать функцию программы File — «Symbol File Path», куда следует вписать следующую строчку и нажать ОК:

set _NT_SYMBOL_PATH=srv*DownstreamStore*https://msdl.microsoft.com/download/symbols

Если не сработало, пробуем вот эту команду:

SRV*%systemroot%symbols*http://msdl.microsoft.com/download/symbols

Снова нажимаем пункт «File» и выбираем опцию «Save Workspace».

Утилита настроена. Остается указать путь до файлов дампов памяти. Для этого нажимаем File и щелкаем опцию «Open Crash Dump». Расположение всех дампов указано в начале статьи.

После выбора закончится анализ и проблемный компонент автоматически будет выделен. Для получения большего количества информации в этом же окошке можно ввести такую команду: !analyze –v

Анализ с помощью BlueScreenView

Загрузить инструмент бесплатно можно с этого сайта — http://www.nirsoft.net/utils/blue_screen_view.html. Установка не требует каких-то навыков. Используется только в Windows 7 и выше.

Запускаем и настраиваем. Нажмите «Настройки» (Options) – «Дополнительные параметры» (Advanced Options). Выберите первый пункт «Загружать МиниДампы из этой папки» и указываем каталог — C:WINDOWSMinidump. Хотя можно просто нажать кнопку «По умолчанию». Нажимаем ОК.

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

В нижней части окна будут отображены компоненты, которые были задействованы на момент сбоя. Красным цветом будет выделен виновник аварии.

Теперь нажимаем «Файл» и выбираем, например, пункт «Найти в Google код ошибки + драйвер». Если нашли нужный драйвер, установите и перезагрузите компьютер. Возможно ошибка исчезнет.

Источник

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

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

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

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

Формат PDB

Выводы

Microsoft Windows debugging symbols можно ли удалить?

Как установить и настроить WinDBG для анализа BSOD

Загрузка и установка WinDBG

Ассоциированние .dmp файлов с WinDBG

Debugging: Развертывание сервера отладочной информации

1. Подготовка окружения

2. Организация хранилища отладочной информации

3. Организация доступа к хранилищу отладочной информации через протокол http

4. Инсталляция прокси-фильтра для обновления символов через интернет

5. Настройка параметров прокси сервера для symproxy.dll

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

Резюме

Заключение

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

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

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

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

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

Формат PDB

Выводы

предисловие

Во-первых, скачать

Таблица символов в Windows отладки

Начало работы с отладкой в ​​пользовательском режиме

Типы аварийных дампов памяти Windows

Как включить создание дампа памяти в Windows?

Установка WinDBG в Windows

Настройка ассоциации .dmp файлов с WinDBG

Настройка сервера отладочных символов в WinDBG

Анализ аварийного дампа памяти в WinDBG

Информация в реестре

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

Как включить дампы

Как удалить дамп

Анализ дампа памяти при помощи WinDbg

Анализ с помощью BlueScreenView

Начало работы с отладкой в пользовательском режиме