Microsoft windows debugging symbols что это за программа
В случае критической ошибки система останавливает свою работу, отображает синий экран смерти (BSOD), информация об ошибке и содержимое памяти сохраняется в файле подкачки. При последующей загрузке системы, на основе сохраненных данных, создается аварийный дамп c отладочной информацией. В системном журнале событий создается запись о критической ошибке.
Если критическая ошибка возникла на ранней стадии загрузки системы или в результате ошибки произошел отказ дисковой подсистемы, аварийный дамп сохранен не будет.
Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).
Содержание
Анализ аварийного дампа утилитой BlueScreenView
Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.
BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.
По каждому отказу отображается дата, данные об ошибке и драйвер, который предположительно вызвал отказ.
В нижней части окна отображается список загруженных в системе драйверов. Модули, к которым выполнялось обращение в момент отказа, выделены цветом, на них следует обратить особое внимание, они могут быть причиной отказа.
По двойному клику отображается дополнительная информация.
Анализ аварийного дампа отладчиком WinDbg
С помощью WinDbg из аварийного дампа можно вытащить более детальную информацию, включая расшифровку стека.
Установка Debugging Tools for Windows (WinDbg)
Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки.
После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%\Minidump.
Настройка отладочных символов
Отладочные символы содержат символические имена функций из исходного кода. Они необходимы для расшифровки и интерпретации аварийного дампа.
При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.
Следующей строкой включаем загрузку отладочных символов из сети, задаем локальный путь для сохранения файлов и адрес для загрузки из интернета:
Анализ аварийного дампа
В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.
Указываем путь к дампу %SystemRoot%\MEMORY.DMP или %SystemRoot%\Minidump\файл.dmp.
Загрузка отладочных символов из интернета может занять некоторое время.
Для получения детальной информации выполняем команду:
Дебаггер сам вам предложит ее выполнить, достаточно навести указатель мыши на ссылку и кликнуть.
В результате получаем следующий вывод:
Получение информации о проблемном драйвере
Если удалось обнаружить драйвер, в котором возникла ошибка, имя драйвера будет отображено в полях MODULE_NAME и IMAGE_NAME.
Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:
Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%\system32\drivers.
Находим указанный файл, и изучаем его свойства.
Обновляем проблемный драйвер.
Аппаратные причины возникновения критических ошибок
Источником критических ошибок нередко бывают неисправности в дисковой подсистеме, или в подсистеме памяти.
Диагностика неисправностей диска
В случае ошибок дисковой подсистемы, аварийный дамп может не сохраняться.
Чтобы исключить проблемы с диском, проверяем системный журнал событий на наличие ошибок чтения и записи на диск.
Проверяем параметры S.M.A.R.T жесткого диска, получить их можно, например, с помощью программы SpeedFan.
Особое внимание обращаем на параметры: "Current Pending Sector Count" и "Uncorrectable Sector Count", ненулевые значения этих параметров сигнализируют о неисправности диска.
Ненулевое значение параметра: "UltraDMA CRC Error Count", сигнализирует о проблеме с SATA-кабелем.
Подробнее о параметрах S.M.A.R.T. читаем в статье Википедии.
Диагностика неисправностей памяти
Проблемы с памятью нередко могут стать причиной самых разнообразных глюков, включая различные синие экраны, зависания, аварийное завершение программ, повреждение реестра, повреждение файловой системы и данных.
Выявить проблемы с памятью можно с помощью утилиты Memtest86+.
Загружаем образ по ссылке, записываем на диск, загружаемся с диска, запускается тест.
Начиная с Windows Vista, в системе имеется свой тест памяти. Для его запуска нажимаем "Пуск", в строке поиска набираем "памяти", выбираем "Средство диагностики памяти Windows".
Проблемы с памятью в некоторых случаях могут быть устранены обновлением BIOS.
Настройка параметров сохранения аварийного дампа
Для изменения параметров сохранения аварийного дампа нажимаем кнопку "Пуск", щелкаем на "Компьютер" правой кнопкой мыши, в контекстном меню выбираем "Свойства". В окне "Система" слева выбираем "Дополнительные параметры системы", в группе "Загрузка и восстановление" нажимаем кнопку "Параметры".
Windbg - это просто программа для отладки пользовательского режима / режима ядра под Windows и анализа файлов Core Dump. Для анализа Crash, утечки ресурсов, взаимоблокировок и других проблем Windbg является мощным инструментом.
Во-первых, скачать
Если вас не интересует другое содержимое Windows SDK, вы можете просто проверить Windbg.
После завершения установки вы можете найти Windbg в строке меню Windows Пуск.
Установка может быть неудачной. Если она не удалась, вы можете перейти в Панель управления \ Программы \ Программы и компоненты " Microsoft Visual C++ 2010 Redistributable Удалите, установка прошла успешно.
Перед использованием необходимо выполнить следующие задачи
- Определите, какое устройство выступает в качестве сервисной системы, а какое - в качестве клиентской системы. Отладчик работает в клиентской системе, а программа - в сервисной системе.
- Определите, собираетесь ли вы выполнять отладку в пользовательском режиме или в режиме ядра. Режим ядра может иметь большие разрешения и доступ к любой части системы. Многие основные функции операционной системы и драйверы оборудования работают в режиме ядра. Пользовательский режим имеет множество ограничений и может работать только в своем собственном пространстве виртуальной памяти и не имеет прямого доступа к системе.
Для режима отладки ядра, пожалуйста, обратитесь к:
Для отладки пользовательского режима, пожалуйста, обратитесь к: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, что мой файл символов хранится в папке c: \ mysymbol. На самом деле в нем ничего нет, даже эта папка не существует, но это не имеет значения. Если система не может найти ее, она создаст ее и загрузит по указанному выше URL-адресу. Перейти, чтобы помочь вам загрузить файл символов в нем.
Примечание: После выполнения этого шага, если вы снова запустите VS, VS прочитает переменную среды _NT_SYMBOL_PATH и загрузит и прочитает из нее символ, что приведет к очень медленному запуску и отладке VS. Рекомендуется изменить _NT_SYMBOL_PATH на другое имя, когда Windbg не используется.
- Как отладчик распознает таблицу символов
- Проблемы с символами при отладке
Начало работы с отладкой в пользовательском режиме
Отладка вашей собственной программы
Предположим, вы написали следующую программу
(1) Используйте Visual studio 2015 для создания Helloworld.exe в x64 и режиме отладки, а также Helloworld.pdb.
(2) Скопируйте Helloworld.pdb в локальную папку символов (обратитесь к:Таблица символов конфигурации)。
(3) Откройте Helloworld.exe и Helloworld.cpp с помощью windbg.
Затем вы можете ввести команды отладки, например:
Средства установки точки останова в главном модуле HelloWorld
(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.
00000001`3f2a16d3 f7bd28010000 idiv eax,dword ptr [rbp+128h] ss:00000000`0014f648=00000000
Это означает, что произошла ошибка деления на 0.
Будет сгруппирован анализ ошибок.
Обязательным условием для этого раздела является настройка символа (ссылка:Таблица символов конфигурации)。
- Откройте notepad.exe с помощью windbg, обычно в C:\Windows\System32 Как показано на рисунке:
- пробег.reload, Найти и загрузить символы
- x notepad!WinMain
Найти все с WinMain согласование symbols 。
Выше две команды могут войти 0 Хороший прогресс и просмотр трассировки стека
Копая залежи документов на своем рабочем компе обнаружил инструкцию по развертыванию сервера отладочной информации, которую писал два-три года назад. Попробую представить её хабросообществу. Данная инструкция будет полезна C++ разработчикам под Windows, которые хотят использовать отладку релизных версий своего продукта (удаленно и напрямую, на своих компах и компах тестировщиков), а также делать разбор крашдампов (postmortem debugging).
Развертывание хранилища отладочной информации
1. Подготовка окружения
2. Организация хранилища отладочной информации
- add – добавить файлы в хранилище.
- /r – рекурсивно обходить папку с файлами символов.
- /3 – организовывать трёхуровневое хранилище (для ускорения доступа к файлам)
- /f [path] – путь к файлам добавляемым в хранилище.
- /s [path] – путь к хранилищу.
- /compress – создавать архивированное хранилище (для сбережения дискового пространства)
4. Инсталляция прокси-фильтра для обновления символов через интернет
5. Настройка параметров прокси сервера для symproxy.dll
В Debugging Tools For Windows есть недочет, связанный с тем, что “symproxy.dll” не перенаправляет вызовы на получение сжатых файлов отладочных символов на сайт Microsoft если “symproxy.dll” работает с интернетом напрямую (без прокси сервера). Для того чтобы устранить данный дефект необходимо поставить локальный прокси сервер и с помощью утилиты “proxycfg.exe” настроить систему на работу с прокси сервером.
6. Настройка клиентских компьютеров на работу с сервером отладочной информации
- [local_repository] – это локальный кеш символов, например “C:\Symbols”.
- [symbol_server_ip] – IP адрес или доменное имя корпоративного сервера отладочной информации.
Резюме
- настройку создания файлов отладочной информации (*.pdb)
- вызов «symstore» для того чтобы отладочная информация о ваших компонентах и сами компоненты попали на ваш сервер.
Заключение
Данная инструкция, как я и говорил, была написана 2-3 года назад, поэтому там фигурирует компьютер с Win2003, думаю вам не составит труда по аналогии развернуть сервер символов на Win2008 и последней версии IIS. Да и виртуалки, на которой можно было бы снять скриншоты настроки, тоже не оказалось. Но описание достаточно детальное, поэтому думаю что вы разберетесь.
Возможно проблема описанная в пункте 5 уже не актуальна, я не проверял.
Более детальную информацию по работе с серверами отладочной информации можно почерпнуть их хелп файла Debugging Tools For Windows, для затравки скажу что ещё можно привязать ваш сервер отладочной информации с сервером хранения исходников, и тогда при разборе крашдампа вы сможете видеть не только стек падения программы, но и место в исходниках, валидных на момент сборки.
Если вы разработчик драйверов и используете DDK то Debugging Tools for Windows входит туда, и его установку можно выбрать при установке DDK.
После перехода по ссылке, будет загружен веб установщик, который предложит установить Windows SDK (Software Development Kit), в который входит и Debugging Tools.
В ходе установки, вы можете выбрать только Debugging Tools
Среди утилит, которые входят в Debugging Tools есть несколько, с помощью которых можно анализировать файлы дампов:
- windbg.exe
- dumpchk.exe
- dumpexam.exe
- kd.exe
Одной из самых простых программ является dumpchk.exe. Давайте запустим ее и перенаправим вывод в файл. Мы получим приблизительно следующий результат (см. вложенный файл ниже)
По результатам анализа можно обратить внимание на следующую важную информацию.
3. Драйвера, которые использовались в системе на момент краха, строки вида:
804d7000 806e4000 nt Sun Apr 13 21:31:06 2008 (4802516A)
806e4000 80704d00 hal Sun Apr 13 21:31:27 2008 (4802517F)
b0b90000 b0ba8b00 bthpan Sun Apr 13 21:51:32 2008 (48025634)
b0ba9000 b0beba80 bthport Sun Apr 13 21:46:29 2008 (48025505)
В простейших случаях, уже этого достаточно для того, чтобы сделать выводы относительно причин BSOD – драйвер myfault.sys как раз и используется утилитой NotMyFault, то есть, мы нашли виновника.
Вы должны были также обратить внимание на наличие в отчете строк вида:
Symbol search path is: *** Invalid ***
Your debugger is not using the correct symbols
Symbols can not be loaded because symbol path is not initialized.
Если в каталоге c:symbols будут отсутствовать необходимые символы, они будут загружены с сайта Microsoft. Это может занять некоторое время.
Вложенный файл ниже – это результат работы dumpchk.exe с включенной опцией местонахождения символов.
Больших различий в результатах мы не видим. Они появятся когда мы выполним детальный анализ в Windbg.exe с помощью команды
analyze –v
Выбираем “File / Open Crash Dump” открываем наш файла малого дампа.
!analyze -v
Мы получи намного больше информации, чем в случае использования dumpchk.exe (см. вложенный файл)
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e2ee9008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: badbc5ab, address which referenced memory
FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]
LAST_CONTROL_TRANSFER: from badbc9db to badbc5ab
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4
FOLLOWUP_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]
Давайте рассмотрим полученную информацию.
1. DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) – это символическое описание ошибки
2. У данной ошибки, есть 4-е параметра, которые позволяют получить дополнительную информацию, все они представлены ниже
Arg1: e2ee9008, memory referenced (адрес памяти по которому происходило обращение)
Arg2: 00000002, IRQL (уровень IRQL на момент обращения)
Arg3: 00000000, value 0 = read operation, 1 = write operation (тип операции, в нашем случае, это операция чтения)
Arg4: badbc5ab, address which referenced memory (адрес в памяти инструкции, которая выполняла операцию чтения)
FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]
Здесь показана непосредственно инструкция которая выполнялась – операция записи в регистр ecx содержимого по адресу указанному в eax. Эта инструкция находится по адресу myfault+5ab и относится к драйверу myfault.sys (myfault – это имя драйвера).
Это имя процесса пользовательского режима, который выполнялся во время краха.
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4
Это стек вызовов режима ядра. В отличии от стека процесса пользовательского режима, стек ядра один. Благодаря стеку мы видим, что последовательность вызовов была следующей:
С Ntdll.dll была вызвана функция KiFastCallEntry, которая затем вызвала NtDeviceIoControlFile и т.д., пока при выполнении инструкции по адресу myfault+0x5ab не произошел крах системы.
Анализ данных говорит нам о том, что виновником BSOD был драйвер myfault (myfault.sys)
Если бы мы не использовали символы, у нас была бы следующая информация о стеке
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c64 805807f7 89668958 898ae698 8936b740 nt+0x1818f
b08f6d00 80579274 00000094 00000000 00000000 nt+0xa97f7
b08f6d34 8054161c 00000094 00000000 00000000 nt+0xa2274
b08f6d64 7c90e4f4 badb0d00 0006f888 b11b2d98 nt+0x6a61c
b08f6d68 badb0d00 0006f888 b11b2d98 b11b2dcc 0x7c90e4f4
b08f6d6c 0006f888 b11b2d98 b11b2dcc 00000000 vmscsi+0xd00
b08f6d70 b11b2d98 b11b2dcc 00000000 00000000 0x6f888
b08f6d74 b11b2dcc 00000000 00000000 00000000 0xb11b2d98
b08f6d78 00000000 00000000 00000000 00000000 0xb11b2dcc
Что менее информативно.
Читайте также: