Windows debugging symbols что это

Windows Debugging Tools: диагностика и исправление BSOD

Такие типы сбоев обычно связаны со сбойным драйвером, который бывает трудно вычислить. Тем не менее, улучшенная система отслеживания ошибок в 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, откройте файл \Windows\MEMORY.DMP, и программа незамедлительно начнет его анализировать.

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

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

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

!analyze –v

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

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

Развертывание сервера отладочной информации / Хабр

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

Развертывание хранилища отладочной информации

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

Для развертывания хранилища отладочных сиволов понадобится:

Компьютер с доступом в интернет (не важно прямым или через proxy), операционной системой Window 2003 Server или Windows XP Pro, веб сервером Internet Information Services
Дистрибутив Debugging Tools For Windows. Дистрибутив можно взять с сайта: www.microsoft.com/whdc/DevTools/Debugging/default.mspx, версию x86 или x64
Дистрибутивы символов операционных систем. Дистрибутивы можно взять с сайта: www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx
Дистрибутив прокси-сервера (в случае прямого доступа в интернет)

Следует установить дистрибутив Debugging Tools For Windows (будем считать, что дистрибутив установлен в папку “C:\Program Files\Debugging 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 Files\Debugging Tools For Windows\symproxy”.
Установим прокси фильтр:

Скопируем из каталога “C:\Program Files\Debugging Tools For Windows\symproxy” файлы “symproxy.dll “и “symsrv.dll“ в папку “%WINDIR%\system32\inetsrv”.
Создадим пустой файл “%WINDIR%\system32\inetsrv\symget.yes”.
Внесём данные из файла “С:\Program Files\Debugging Tools For Windows\symproxy\symproxy.reg” в реестр.
Зайдем в редактор реестра и найдем ключ “HKLM/Software/Microsoft/Symbol Server Proxy/Web Directories/symbols”.
Изменим значение “SymbolPath” на “C:\symbols;http://msdl.microsoft.com/download/symbols”.
Далее зарегистрируем прокси-фильтр как источник событий создав ключ реестра “HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\SymProxy” и добавив туда REG_EXPAND_SZ значение с именем “EventMessageFilter” и значением “%WINDIR%\system32\inetsrv\symproxy.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%\system32\inetsrv\symproxy.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 и создать переменные окружения:

_NT_SYMBOL_PATH=srv*[local_repository]*http://[symbol_server_ip]/symbols

 _NT_IMAGE_PATH=srv*[local_repository]*http://[symbol_server_ip]/symbols

Где:

[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, для затравки скажу что ещё можно привязать ваш сервер отладочной информации с сервером хранения исходников, и тогда при разборе крашдампа вы сможете видеть не только стек падения программы, но и место в исходниках, валидных на момент сборки.

Анализ дампов после BSOD с помощью Debugging Tools for Windows

Debugging Tools for Windows – это набор утилит от Microsoft, предназначенный для разработчиков и администраторов. Установщик можно бесплатно скачать по ссылке — http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx. Перед этим, вам нужно выбрать версию ОС, в которой вы будете использовать утилиты.

Если вы разработчик драйверов и используете DDK то Debugging Tools for Windows входит туда, и его установку можно выбрать при установке DDK.

После перехода по ссылке, будет загружен веб установщик, который предложит установить Windows SDK (Software Development Kit), в который входит и Debugging Tools.

В ходе установки, вы можете выбрать только Debugging Tools

После того, как установка завершится, вам нужно найти один из файлов установки Debugging Tools. В моей Windows XP SP3 (x86) файлы установки находятся по пути — C:Program FilesMicrosoft SDKsWindowsv7.1RedistDebugging Tools for Windows. Запускаем файл dbg_x86.msi и выполняем установку.

В моей системе набор программ для отладки Debugging Tools по-умолчанию установился в каталог «C:Program FilesDebugging Tools for Windows (x86)»

Теперь нам необходим фал дампа. О том, где его взять вы можете почитать на главной странице – здесь. Если его нет, вы можете его создать с помощью утилиты NotMyFault. Давайте так и поступим, при этом, в качестве ошибки в драйвере, мы выберем DRIVER_IRQL_NOT_LESS_OR_EQUAL. Запускаем программу, выбираем “Hihg IRQL fault (Kernel-mode)” и нажимаем “Crash”. Поскольку в Windows XP, которую я использую, по-умолчанию тип дампа – малый дамп (смотрите здесь — о типах дампов), файл дампа можно найти в каталоге %Systemroot%minidump (c:windowsminidump).

Среди утилит, которые входят в Debugging Tools есть несколько, с помощью которых можно анализировать файлы дампов:

windbg.exe
dumpchk.exe
dumpexam.exe
kd.exe

Одной из самых простых программ является dumpchk.exe. Давайте запустим ее и перенаправим вывод в файл. Мы получим приблизительно следующий результат (см. вложенный файл ниже)

По результатам анализа можно обратить внимание на следующую важную информацию.

1. Код ошибки (стоп-код) и его параметры, в файле — BugCheck 100000D1, {e2ee9008, 2, 0, badbc5ab}.

2. Строку с названием драйвера, который по мнению утилиты, привел к BSOD — Probably caused by : myfault.sys ( myfault+5ab )

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.

Символы играют важную роль при отладке драйверов разработчиками, в том числе при анализе BSOD. Они позволяют видеть названия функций, которые используются ядром, позволяют разработчикам драйверов видеть непосредственно код на С/С++ своих драйверов, выполнение которого привело к BSOD, а также получать другую информацию. “Символы” – это общее понятие, которое относится к дополнительной информации, которая обычно записывается в файлы .pdb или в исполняемый файл, в процессе работы линковщика. Для нас важно знать, что они содержат дополнительную информацию, которая упрощает анализ дампов. Более подробную информацию о символах вы можете узнать в файле помощи к Debugging Tools — debugger.chm.

Давайте запустим dumpchk.exe с параметром — “y”, который позволяет указать путь к файлам символов.

dumpchk.exe -y srv*C:Symbols*http://msdl.microsoft.com/download/symbols C:WINDOWSMinidumpMini021814-01.dmp > rep.txt

Если в каталоге c:symbols будут отсутствовать необходимые символы, они будут загружены с сайта Microsoft. Это может занять некоторое время.

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

Больших различий в результатах мы не видим. Они появятся когда мы выполним детальный анализ в Windbg.exe с помощью команды

analyze –v

Запускаем windbg.exe

windbg.exe -y cache*C:Symbols;srv*http://msdl.microsoft.com/download/symbols

Выбираем “File / Open Crash Dump” открываем наш файла малого дампа.

Мы также увидим сообщение о ошибке — “ERROR: Module load completed but symbols could not be loaded for myfault.sys”. Так и должно быть поскольку для этого драйвера файлы символы не представлены. Теперь в строке ввода команд давайте введем:

!analyze -v

Мы получи намного больше информации, чем в случае использования dumpchk.exe (см. вложенный файл)

Вот сам отчет.

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

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

Debugging Details:
——————

READ_ADDRESS: e2ee9008

CURRENT_IRQL: 2

FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: NotMyfault.exe

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

STACK_COMMAND: kb

FOLLOWUP_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: myfault+5ab

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: myfault

IMAGE_NAME: myfault.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4f806ca0

FAILURE_BUCKET_ID: 0xD1_myfault+5ab

BUCKET_ID: 0xD1_myfault+5ab

Followup: MachineOwner

Давайте рассмотрим полученную информацию.

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 – это имя драйвера).

PROCESS_NAME: NotMyfault.exe

Это имя процесса пользовательского режима, который выполнялся во время краха.

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

nt!KiFastCallEntry+0xfc
nt!NtDeviceIoControlFile+0x2a
nt!IopXxxControlFile+0x5c5
nt!IopSynchronousServiceTail+0x70
nt!IopfCallDriver+0x31
myfault+0xb26
myfault+0x9db
myfault+0x5ab

С 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

Что менее информативно.

Вообще анализ дампов, кроме самых простых случаев (таких как рассмотренный) требует значительной подготовки и хорошего понимания как работы ОС и драйверов так и владение знанием ассемблера. В открытом доступе можно найти некоторые книги Дмитрия Востокова «Memory Dump Analysis Antology». Если вы их найдете, вы сможете приблизительно оценить уровень автора и приблизительно понять нетривиальность анализа дампов.

Как я уже говорил, мы разобрали простой случай анализа дампа после BSOD. Если результаты анализа показывают, что причиной BSOD являются файлы ядра, например – ntoskrnl.exe, обязательно прочитайте об использовании утилиты Driver Verifier.

Post Views: 3 062

Анализ аварийных дампов Windows - расшифровка синих экранов (BSOD)

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

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

Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).

Содержание

Анализ аварийного дампа утилитой BlueScreenView

Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.

Загружаем программу с сайта разработчика.

BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.

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

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

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

Анализ аварийного дампа отладчиком WinDbg

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

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

Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки центра разработки.

Для анализа аварийных дампов установка SDK не требуется. Скачать Debugging Tools for Windows (WinDbg) отдельным пакетом можно здесь или здесь.

Загружаем и устанавливаем WinDbg для вашей версии Windows. Версия для Windows 7 работает также в Windows XP и в Windows Vista.

Для Windows 10 требуется WinDbg версии 10.0.10586.567. Скачиваем Изолированный пакет SDK для Windows 10. Будет загружен веб-установщик. При установке, отключаем все компоненты, кроме отладчика.

После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%\Minidump.

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

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

При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.

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

srv*C:\Windows\symbols*http://msdl.microsoft.com/download/symbols

Если система не подключена к интернету, пакет для установки символов можно предварительно загрузить на странице загрузки пакетов символов Windows, центра разработки Microsoft.

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

Запускаем WinDbg.

В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.

Указываем путь к дампу %SystemRoot%\MEMORY.DMP или %SystemRoot%\Minidump\файл.dmp.

Загрузка отладочных символов из интернета может занять некоторое время.

Для получения детальной информации выполняем команду:

!analyze -v

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

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

*******************************************************************************
 * *
 * Bugcheck Analysis *
 * *
 *******************************************************************************
 
 Тип ошибки: KMODE_EXCEPTION_NOT_HANDLED (1e)
 Комментарий к ошибке: This is a very common bugcheck. Usually the exception address pinpoints
 the driver/function that caused the problem. Always note this address
 as well as the link date of the driver/image that contains this address.
 Arguments:
 Аргументы ошибки:
 Arg1: 0000000000000000, The exception code that was not handled
 Arg2: 0000000000000000, The address that the exception occurred at
 Arg3: 0000000000000000, Parameter 0 of the exception
 Arg4: 0000000000000000, Parameter 1 of the exception
 
 Debugging Details:
 ------------------
 
 EXCEPTION_CODE: (Win32) 0 (0) - .
 
 FAULTING_IP:
 +3332313336383065
 00000000`00000000 ?? ???
 
 EXCEPTION_PARAMETER1: 0000000000000000
 
 EXCEPTION_PARAMETER2: 0000000000000000
 
 ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0
 
 BUGCHECK_STR: 0x1E_0
 
 CUSTOMER_CRASH_COUNT: 1
 
 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
 
 Процесс, вызвавший ошибку: PROCESS_NAME: VirtualBox.exe
 
 CURRENT_IRQL: 2
 
 EXCEPTION_RECORD: fffff80000ba24d8 -- (.exr 0xfffff80000ba24d8)
 ExceptionAddress: fffff800034d8a70 (nt!DbgBreakPoint)
 ExceptionCode: 80000003 (Break instruction exception)
 ExceptionFlags: 00000000
 NumberParameters: 1
 Parameter[0]: 0000000000000000
 
 TRAP_FRAME: fffff80000ba2580 -- (.trap 0xfffff80000ba2580)
 NOTE: The trap frame does not contain all registers.
 Some register values may be zeroed or incorrect.
 rax=0000000000142940 rbx=0000000000000000 rcx=fffffa80055be690
 rdx=0000000000009018 rsi=0000000000000000 rdi=0000000000000000
 rip=fffff800034d8a71 rsp=fffff80000ba2718 rbp=fffff88006fa0000
 r8=0000000000002274 r9=11d0851b22c6ac61 r10=fffff80003464000
 r11=fffff80000ba27e0 r12=0000000000000000 r13=0000000000000000
 r14=0000000000000000 r15=0000000000000000
 iopl=0 nv up ei pl nz ac po nc
 nt!DbgBreakPoint+0x1:
 fffff800`034d8a71 c3 ret
 Resetting default scope
 
 LAST_CONTROL_TRANSFER: from fffff800034d85fe to fffff800034e0c10
 
 STACK_TEXT:
 Стек вызовов: 
 fffff800`00ba15b8 fffff800`034d85fe : fffffa80`03c05530 00000000`ffffffff fffff800`00ba1d30 fffff800`0350c830 : nt!KeBugCheck
 fffff800`00ba15c0 fffff800`0350c4fd : fffff800`036ea71c fffff800`03627c30 fffff800`03464000 fffff800`00ba24d8 : nt!KiKernelCalloutExceptionHandler+0xe
 fffff800`00ba15f0 fffff800`0350b2d5 : fffff800`0362b028 fffff800`00ba1668 fffff800`00ba24d8 fffff800`03464000 : nt!RtlpExecuteHandlerForException+0xd
 fffff800`00ba1620 fffff800`0351c361 : fffff800`00ba24d8 fffff800`00ba1d30 fffff800`00000000 00000000`00142940 : nt!RtlDispatchException+0x415
 fffff800`00ba1d00 fffff800`034e02c2 : fffff800`00ba24d8 fffffa80`07149010 fffff800`00ba2580 00000000`00000000 : nt!KiDispatchException+0x135
 fffff800`00ba23a0 fffff800`034de0f4 : 00000000`00000016 00000000`00000001 00000000`00000001 00000000`00000000 : nt!KiExceptionDispatch+0xc2
 fffff800`00ba2580 fffff800`034d8a71 : fffff880`05861446 00000000`df029940 fffff880`02f45bec 00000000`deee7000 : nt!KiBreakpointTrap+0xf4
 fffff800`00ba2718 fffff880`05861446 : 00000000`df029940 fffff880`02f45bec 00000000`deee7000 fffff880`01229f06 : nt!DbgBreakPoint+0x1
 fffff800`00ba2720 00000000`df029940 : fffff880`02f45bec 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8 : cmudaxp+0x25446
 fffff800`00ba2728 fffff880`02f45bec : 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8 00000000`00000000 : 0xdf029940
 fffff800`00ba2730 00000000`deee7000 : fffff880`01229f06 fffffa80`05635af8 00000000`00000000 00000000`00000003 : VBoxDrv+0x6bec
 fffff800`00ba2738 fffff880`01229f06 : fffffa80`05635af8 00000000`00000000 00000000`00000003 fffff880`05865913 : 0xdeee7000
 fffff800`00ba2740 00000000`00000000 : 00000000`00000001 00000000`00000006 00000000`00000001 fffff800`00ba2800 : CLASSPNP!ClasspServiceIdleRequest+0x26
 
 STACK_COMMAND: kb
 
 FOLLOWUP_IP:
 cmudaxp+25446
 fffff880`05861446 ?? ???
 
 SYMBOL_STACK_INDEX: 8
 
 SYMBOL_NAME: cmudaxp+25446
 
 FOLLOWUP_NAME: MachineOwner
 
 Драйвер, в котором возникла ошибка: MODULE_NAME: cmudaxp
 
 IMAGE_NAME: cmudaxp.sys
 
 DEBUG_FLR_IMAGE_TIMESTAMP: 47906a45
 
 FAILURE_BUCKET_ID: X64_0x1E_0_cmudaxp+25446
 
 BUCKET_ID: X64_0x1E_0_cmudaxp+25446
 
 Followup: MachineOwner
 ---------

Получение информации о проблемном драйвере

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

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

start end module name
 fffff880`0583c000 fffff880`059ef000 cmudaxp T (no symbols) 
 Loaded symbol image file: cmudaxp.sys
 Image path: \SystemRoot\system32\drivers\cmudaxp.sys
 Image name: cmudaxp.sys
 Timestamp: Fri Jan 18 13:58:45 2008 (47906A45)
 CheckSum: 0013077F
 ImageSize: 001B3000
 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Если полный путь к драйверу не указан, по умолчанию используется папка %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.

Настройка параметров сохранения аварийного дампа

Для изменения параметров сохранения аварийного дампа нажимаем кнопку "Пуск", щелкаем на "Компьютер" правой кнопкой мыши, в контекстном меню выбираем "Свойства". В окне "Система" слева выбираем "Дополнительные параметры системы", в группе "Загрузка и восстановление" нажимаем кнопку "Параметры".

Подробнее о дампах памяти читаем здесь.

Debugging tools for Windows / Хабр

Раньше я не знал, что такое сабж и не умел его использовать. Теперь немного узнал и впечатлён. Расскажу про свой опыт общения с ним, может кому-то будет полезно.

Эти тулзы содержат мощные отладчики (WinDbg, Cdb) и позволяют делать всякие полезности, типа создания symservers (symstore.exe), создания дампа с процесса (cdb, windbg), отладки мемори ликов (umdh.exe) и других ошибок работы с памятью (gflags — позволяет включать многие «скрытые» системные проверки как для конкретного exe файла, так и для всей системы в целом). Также в комплекте есть много других полезных тулзов, типа просмотрщика debug output.

Взять можно тут: Майкросайт

Например, как получить мемори лики для любой программы:
Нам понадобится umdh.exe, tlist.exe и gflags.exe. Все их надо запускать с админскими правами.
Запускаем gflags.exe, выставляем галочку Create user mode stack database. Перезагружаемся — теперь для всех запущенных программ будет создаваться этот database. Можно для каждого приложения отдельно настроить.
Далее запускаем нужную программу, ждем, пока все загрузится и получаем PID программы с помощью tlist.exe (или как угодно еще). Например, PID == 111.
Далее запускаем umdh.exe -p:111 -f:c:\temp\log1.log
Эта строка сохранит в файл log1.log инфу о всех текущих выделениях памяти в процессе 111.
Далее работаем в программе, ждем сколько-нибудь времени и снова пишем:
umdh.exe -p:111 -f:c:\temp\log2.log
Получаем второй лог с выделениями памяти.
Теперь их можно сравнить и получить лики:
umdh.exe -d -v -l c:\temp\log1.log c:\temp\log2.log 1> c:\temp\log_result.log
Теперь у нас в log_result.log будут все выделенные и не освобожденные куски памяти с калстэками!
Чтобы калстэки были правильные, нужно настроить enviroment variable _NT_SYMBOL_PATH. В хелпе написано, как его настроить для майкрософтовских exe и dll.
Свои pdb лучше всего сохранять на symbol server, который можно пополнять после билдов с помощью symstore.exe — тогда всегда отладчик будет иметь правильный pdb.
Если сервера нет, можно просто положить pdb рядом с ехе — должен подцепиться. Если не подцепится, то добавить путь к pdb в _NT_SYMBOL_PATH.

Если у вас есть дамп файл и надо его проверить, то опять же проще всего использовать WinDbg. Он использует ту же переменную _NT_SYMBOL_PATH и, в отличие от VisualStudio, он не требует ни исходников ни правильных бинарников для отладки. Просто дамп и подходящий pdb! Запускаешь WinDbg.exe, File\open crash dump..., открываешь дамп, пишешь !analyze -v, потом !uniqstack и уже обычно этого достаточно в простых случаях. Видишь, какие pdb нашлись, какие нет и получаешь анализ дампа. Можно открыть окошки с callstack, Processes and threads и отлаживаться. Если надо увидеть код — File\Source File Path… — указать путь к исходникам и можно смотреть место в коде, где что произошло (лучше сразу эти пути прописать в enviroment variable _NT_SOURCE_PATH, чтобы не вбивать их каждый раз). Короче, опять все просто и удобно, если есть правильный pdb :)

Проблемы с зависаниями чего-либо отлично решаются с помощью создания дампа зависшего процесса. Для этого можно использовать тот же WinDbg или специальные проги или стандартную системную фичу в висте в таск менеджере — создать дамп:)
Причем DebuggingTools можно установить уже после зависания — никакой перезагрузки не надо. Установил — снял дамп. Для снятия дампа юзеру не надо никаких pdb.
Потом этот дамп анализируешь и исправляешь (в Windbg есть специальные команды для поиска дедлоков и т.п. — команда !locks и другие).

Вывод:
Чтобы не иметь проблем с отладкой, надо озаботиться системой хранения pdb файлов для КАЖДОГО билда ну или хотя бы для официальных билдов. А также изучить Debugging tools и написать простые рекоммендации тестерам и программистам — что делать в случае ошибки или зависания, как создавать дамп, куда его класть и с какими коментариями. А некоторые тестеры даже могут запускать WinDBG и копипастить в отчет о баге оттуда нужные данные типа калстэка с ошибкой — очень помогает в предварительном анализе.

В дополнение пара полезных ссылок для начинающих про WinDBG:
WinDbg. From A to Z!
Common WinDbg Commands (Thematically Grouped)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя	Назначение
GRMSDK_EN_DVD.iso	Образ SDK для систем с архитектурой x86 (32-битных).
GRMSDKIAI_EN_DVD.iso	Образ SDK для систем с архитектурой ia64.
GRMSDKX_EN_DVD.iso	Образ SDK для систем с архитектурой x64 (64-битных).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состав Debugging Tools for Windows

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

Файл	Назначение
adplus.doc	Документация по утилите ADPlus.
adplus.exe	Консольное приложение, которое автоматизирует работу отладчика cdb для создания дампов, лог-файлов для одного или нескольких процессов.
agestore.exe	Утилита для удаления устаревших файлов из хранилища, используемого сервером символов или сервером исходников.
breakin.exe	Утилита, которая позволяет посылать процессам комбинацию пользовательского останова (break), аналогичное нажатию CTRL+C.
cdb.exe	Консольный отладчик пользовательского режима.
convertstore.exe	Утилита для конвертирования символов из уровня 2-tier в уровень 3-tier.
dbengprx.exe	Рипитер (прокси сервер) для удаленной отладки.
dbgrpc.exe	Утилита для отображения информации о состоянии вызова RPC.
dbgsrv.exe	Процесс сервера, используемый для удаленной отладки.
dbh.exe	Утилита для вывода информации о содержимом файла символов.
dumpchk.exe	Утилита проверки дампа. Утилита для быстрой проверки дамп-файла.
dumpexam.exe	Утилита для анализа дампа памяти. Результат выводится в %SystemRoot%\MEMORY.TXT.
gflags.exe	Редактор глобальных флагов системы. Утилита управляет ключами реестра и другими настройками.
i386kd.exe	Обертка к kd. Когда то так назывался kd для систем на базе Windows NT/2000 для x86 машин? Вероятно, оставлено из соображений совместимости.
ia64kd.exe	Обертка к kd. Когда то так назывался kd для систем на базе Windows NT/2000 для ia64 машин? Вероятно, оставлено из соображений совместимости.
kd.exe	Консольный отладчик режима ядра.
kdbgctrl.exe	Инструмент управления отладки ядра. Утилита для управление и конфигурирования kernel debugging connection.
kdsrv.exe	Сервер соединений для KD. Утилита представляет собой небольшое приложений, которое запускается и ждет удаленных соединений. kd запускается на клиенте и подсоединяется к этому серверу для удаленной отладки. И сервер и клиент должны быть из одной сборки Debugging Tools.
kill.exe	Утилита для завершения процессов.
list.exe	Утилита для вывода содержимого файла на экран. В комплекте эта миниатюрная утилита оказалась с одной целью - просмотр больших текстовых или лог-файлов. Занимает немного места в памяти, поскольку грузит текст частями.
logger.exe	Миниатюрный отладчик, который может работать только с одним процессом. Утилита внедряет logexts.dll в пространство процесса, которая записывает все вызовы функций и другие действия исследуемой программы.
logviewer.exe	Утилита для просмотра логов, записанных отладчиком logger.exe.
ntsd.exe	Microsoft NT Symbolic Debugger (NTSD). Отладчик, идентичный cdb, за исключением того, что он создает текстовое окно при запуске. Как и cdb, ntsd способен отлаживать и консольные приложения и графические приложения.
pdbcopy.exe	Утилита для удаления приватных символов из файла символов, контроля за публичными символами, включенными в файл символов.
remote.exe	Утилита для удаленной отладки и удаленного контроля любого консольного отладчика KD, CDB и NTSD. Позволяет запускать все эти консольные отладчики удаленно.
rtlist.exe	Удаленный просмотрщик задач. Утилита используется для вывода списка запущенных процессов через процесс сервера DbgSrv.
symchk.exe	Утилита для загрузки символов с сервера символов Microsoft и создания локального кеша символов.
symstore.exe	Утилита для создания сетевого или локального хранилища символов (2-tier/3-tier). Хранилище символов - специализированная директория на диске, которая строится в соответствии с определенной структурой и содержит символы. В корневой директории символов создается структура подпапок с названиями, идентичными названию компонентов. В свою очередь, в каждой из этих подпапок находятся вложенные подпапки, имеющие специальные наименования, получаемые методом хеширования бинарных файлов. Утилита symstore сканирует папки с компонентами и добавляет новые компоненты в хранилище символов, откуда их может получить любой клиент. Говорится что symstore служит для получения символов из хранилища уровня 0-tier и выкладывания их в хранилище уровня 2-tier/3-tier.
tlist.exe	Просмотрщик задач. Утилита для вывода списка всех запущенных процессов.
umdh.exe	User-mode dump heap utility. Утилита для анализа куч (heap) выбранного процесса. Позволяет выводить различные параметры для кучи.
usbview.exe	Просмотрщик USB. Утилита для просмотра USB устройств, подключенных к компьютеру.
vmdemux.exe	Демультиплексор виртуальной машины. Для одного COM-соединения создает несколько именованных каналов. Каналы используются для отладки различных компонентов виртуальной машины
windbg.exe	Отладчик режима пользователя и режима ядра с графическим интерфейсом.

Загрузить пакеты символов Windows для отладки - драйверы Windows

26.04.2018
2 минуты на чтение

В этой статье

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

Прекращение поддержки пакета символов

Важно

Мы больше не публикуем автономные пакеты символов для Windows.

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

Для получения информации о том, как получить символы для машины, не подключенной к Интернету, см. Использование файла манифеста с SymChk.

Ресурсы по символам и отзывы

Чтобы узнать больше об использовании символов и отладке, см. Символы и файлы символов.

Для получения справки по вопросам отладки см. Ресурсы для отладки.

Нам интересно ваше мнение о символах. Присылайте предложения или отчеты об ошибках на адрес windbgfb @ microsoft.com. Техническая поддержка по этому адресу недоступна, но ваши отзывы помогут нам спланировать будущие изменения символов и сделают их более полезными для вас в будущем.

символов для отладки Windows (WinDbg, KD, CDB, NTSD) - драйверы Windows

03.08.2018
2 минуты на чтение

В этой статье

Символы

для отладчиков Windows (WinDbg, KD, CDB и NTSD) доступны с общедоступного сервера символов.

В этот раздел входят:

Знакомство с символами

Доступ к символам для отладки

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

Проблемы с символом при отладке

В этих разделах объясняется, что такое символы, как получить к ним доступ во время сеанса отладки, как управлять параметрами символов отладчика и сопоставлением символов, а также как реагировать на различные проблемы, связанные с символами, во время отладки.

Если вы просто хотите настроить отладчик для доступа к символам для ваших собственных программ и для Windows, возможно, вам будет проще прочитать менее подробные вводные темы «Путь к символам» и «Использование сервера символов».

Путь символов для отладчиков Windows - драйверы Windows

23.10.2019
6 минут на чтение

В этой статье

Путь к символу указывает места, где отладчики Windows (WinDbg, KD, CDB, NTST) ищут файлы символов. Для получения дополнительной информации о символах и файлах символов см. Символы.

Некоторые компиляторы (например, Microsoft Visual Studio) помещают файлы символов в тот же каталог, что и двоичные файлы. Файлы символов и проверенные двоичные файлы содержат информацию о пути и имени файла. Эта информация часто позволяет отладчику автоматически находить файлы символов. Если вы отлаживаете процесс в пользовательском режиме на компьютере, на котором был создан исполняемый файл, и если файлы символов все еще находятся в их исходном местоположении, отладчик может найти файлы символов без указания пути к символам.

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

Синтаксис пути символа

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

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

Для каждого каталога в пути символа отладчик просматривает три каталога.Например, если путь к символу включает каталог c: \ MyDir , а отладчик ищет информацию о символах для библиотеки DLL, отладчик сначала просматривает c: \ MyDir \ symbols \ dll , а затем c: \ MyDir \ dll и, наконец, в c: \ MyDir . Затем отладчик повторяет этот процесс для каждого каталога в пути символа. Наконец, отладчик просматривает текущий каталог, а затем текущий каталог с добавленным к нему .. \ dll . (Отладчик добавляет .. \ dll , .. \ exe или .. \ sys , в зависимости от того, какие двоичные файлы отлаживаются.)

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

Один из способов задать путь символа - ввести .sympath команда. О других способах задания пути символа см. В разделе «Управление путем к символу» далее в этом разделе.

Кэширование символов локально

Мы настоятельно рекомендуем всегда кэшировать символы локально. Один из способов кэшировать символы локально - это включить кэш *; или cache * localsymbolcache; * в пути к вашему символу.

Если включить строку cache *; в пути к символам, символы, загруженные из любого элемента, который появляется справа от этой строки, сохраняются в каталоге кэша символов по умолчанию на локальном компьютере.Например, следующая команда указывает отладчику получить символы из общего сетевого ресурса \ someshare и кэшировать символы в расположении по умолчанию на локальном компьютере.

  .sympath cache *; \\ someshare

Если включить строку cache * localsymbolcache; в пути к вашему символу, символы, загруженные из любого элемента, который появляется справа от этой строки, хранятся в каталоге localsymbolcache .

Например, следующая команда указывает отладчику получить символы из общего сетевого ресурса \\ someshare и кэшировать символы в каталоге c: \ MySymbols .

  .sympath cache * c: \ MySymbols; \\ someshare

Использование сервера символов

Если вы подключены к Интернету или корпоративной сети, наиболее эффективным способом доступа к символам является использование сервера символов. Вы можете использовать сервер символов, используя строку srv * , srv * symbolstore или srv * localsymbolcache * symbolstore в пути к вашему символу.

Если вы включите строку srv * в свой путь к символу, отладчик использует сервер символов для получения символов из хранилища символов по умолчанию.Например, следующая команда указывает отладчику использовать сервер символов для получения символов из хранилища символов по умолчанию. Эти символы не кэшируются на локальном компьютере.

  .sympath SRV *

Если вы включите строку srv * symbolstore в свой путь к символу, отладчик использует сервер символов для получения символов из хранилища symbolstore store. Например, следующая команда указывает отладчику использовать сервер символов для получения символов из хранилища символов по адресу https: // msdl.microsoft.com/download/symbols. Эти символы не кэшируются на локальном компьютере.

  .sympath SRV * https: //msdl.microsoft.com/download/symbols

Если вы включите строку srv * localcache * symbolstore в свой путь к символу, отладчик использует сервер символов для получения символов из хранилища symbolstore и кэширует их в каталоге localcache . Например, следующая команда указывает отладчику использовать сервер символов для получения символов из хранилища символов по адресу https: // msdl.microsoft.com/download/symbols и кэшируйте символы в c: \ MyServerSymbols .

  .sympath SRV * c: \ MyServerSymbols * https: //msdl.microsoft.com/download/symbols

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

  .sympath c: \ MyRegularSymbols; srv * c: \ MyServerSymbols * https: //msdl.microsoft.com/download/symbols

Дополнительные сведения о серверах символов см. В разделах «Хранилища символов» и «Серверы символов».

Объединение cache * и srv *

Если включить строку cache *; в пути к символам, символы, загруженные из любого элемента, который появляется справа от этой строки, сохраняются в каталоге кэша символов по умолчанию на локальном компьютере.Например, следующая команда указывает отладчику использовать сервер символов для получения символов из хранилища по адресу https://msdl.microsoft.com/download/symbols и кэширования их в каталоге кэша символов по умолчанию.

  .sympath cache *; SRV * https: //msdl.microsoft.com/download/symbols

Например, следующая команда указывает отладчику использовать сервер символов для получения символов из хранилища по адресу https://msdl.microsoft.com/download/symbols и кэширования символов в каталоге c: \ MySymbols .

  .sympath кеш * c: \ MySymbols; srv * https: //msdl.microsoft.com/download/symbols

Использование AgeStore для уменьшения размера кеш-памяти

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

Дополнительную информацию о серверах символов и хранилищах символов см. В разделе Хранилища символов и Серверы символов.

Ленивая загрузка символов

По умолчанию отладчик использует отложенную загрузку символа (также известную как отложенная загрузка символа ). Этот вид загрузки означает, что символы не загружаются, пока они не потребуются.

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

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

Дополнительные сведения о отложенной загрузке символов см. В разделе «Отложенная загрузка символов».

Вы можете отключить отложенную загрузку символов в CDB и KD с помощью параметра командной строки -s .Вы также можете принудительно загрузить символ, используя команду ld (Загрузить символы) или используя команду .reload (Reload Module) вместе с опцией / f .

Артефакты служб Azure DevOps

Сервер символов доступен с артефактами Azure в Azure DevOps Services. Информацию о работе с артефактами Azure в WinDbg см. В разделе Отладка с использованием символов в WinDbg. Общие сведения о символах, созданных в Azure, см. В разделе Файлы символов (PDB).

Контроль пути символа

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

Используйте команду .sympath для отображения, установки, изменения или добавления к пути. Команда .symfix (Установить путь к хранилищу символов) аналогична команде .sympath , но избавляет от необходимости печатать.
Перед запуском отладчика используйте переменные среды _NT_SYMBOL_PATH и _NT_ALT_SYMBOL_PATH , чтобы задать путь.Путь к символу создается путем добавления _NT_SYMBOL_PATH после _NT_ALT_SYMBOL_PATH . (Как правило, путь задается через _NT_SYMBOL_PATH . Однако вы можете использовать _NT_ALT_SYMBOL_PATH , чтобы переопределить эти настройки в особых случаях, например, если у вас есть частные версии файлов общих символов.) Если вы попытаетесь добавить недопустимый каталог через эти переменные среды, отладчик игнорирует этот каталог.
При запуске отладчика используйте параметр командной строки -y для задания пути.
(только WinDbg) Используйте файл | Команда «Путь к файлу символов» или нажмите CTRL + S для отображения, установки, изменения или добавления к пути.

Если вы используете параметр командной строки -sins , отладчик игнорирует переменную среды пути символа.

Расширенное использование SymSrv

.Символы

и файлы символов - драйверы для Windows

23.05.2017
2 минуты на чтение

В этой статье

Когда приложения, библиотеки, драйверы или операционные системы связаны, компоновщик, который создает файлы .exe и .dll, также создает ряд дополнительных файлов, известных как файлы символов .

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

Обычно файлы символов могут содержать:

Каждый из этих элементов индивидуально называется символом . Например, один файл символов Myprogram.pdb может содержать несколько сотен символов, включая глобальные переменные и имена функций, а также сотни локальных переменных. Часто компании-разработчики программного обеспечения выпускают две версии каждого файла символов: полный файл символов, содержащий как общедоступных символов, и частных символов, , и сокращенный (разделенный) файл, содержащий только общедоступные символы.Подробнее см. Общие и частные символы.

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

Символы Windows

Windows хранит свои символы в файлах с расширением .pdb.

Компилятор и компоновщик управляют форматом символа.Компоновщик Visual C ++ помещает все символы в файлы .pdb.

Операционная система Windows была построена в двух версиях. Бесплатная сборка (или розничная сборка ) имеет относительно небольшие двоичные файлы, а проверенная сборка (или отладочная сборка ) имеет более крупные двоичные файлы с большим количеством отладочных символов в самом коде. Проверенные сборки были доступны в более старых версиях Windows до Windows 10 версии 1803. У каждой из этих сборок были собственные файлы символов. При отладке целевого объекта в Windows необходимо использовать файлы символов, соответствующие сборке Windows на целевом объекте.

В следующей таблице перечислены несколько каталогов, которые существуют в стандартном дереве символов Windows:

Справочник	содержит файлы символов для
ACM	Файлы Microsoft Audio Compression Manager
COM	Исполняемые файлы (.com)
CPL	Программы панели управления
DLL	Файлы библиотеки динамической компоновки (.dll)
ДРВ	Файлы драйвера (.drv)
EXE	Исполняемые файлы (.exe)
SCR	Файлы заставки
SYS	Файлы драйвера (.sys)

Доступ к символам для отладки - драйверы Windows

28.11.2017
2 минуты на чтение

В этой статье

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

Это может привести к очень длинному пути символа, состоящему из длинного списка каталогов.

Чтобы упростить эти трудности при координации файлов символов, файлы символов могут быть собраны в хранилище символов , к которому затем обращается сервер символов .

Хранилище символов - это набор файлов символов, индекс и инструмент, который может использоваться администратором для добавления и удаления файлов.Файлы индексируются в соответствии с уникальными параметрами, такими как отметка времени и размер изображения. Хранилище символов также может содержать исполняемые файлы изображений, которые можно извлечь с помощью сервера символов. Инструменты отладки для Windows содержат инструмент создания хранилища символов под названием SymStore.

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

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

Если вы выполняете отладку в пользовательском режиме, вам потребуются символы для целевого приложения.Если вы выполняете отладку в режиме ядра, вам потребуются символы для отлаживаемого драйвера, а также общедоступные символы Windows. Microsoft создала хранилище символов с общедоступными символами для продуктов Microsoft; этот магазин символов доступен в Интернете. Эти символы могут быть загружены с помощью команды .symfix (Установить путь к хранилищу символов) , если у вас есть доступ к Интернету во время работы отладчика. Для получения дополнительной информации или определения того, как установить эти символы вручную, см. Установка файлов символов Windows.

В этот раздел входят:

Установка файлов символов Windows

Магазины Symbol и серверы Symbol

Загрузка отложенного символа

символов в средствах отладки Microsoft для Windows?

Переполнение стека

Около
Товары
Для команд

Переполнение стека Общественные вопросы и ответы
Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии Программирование и связанные с ним технические возможности карьерного роста
Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама Обратитесь к разработчикам и технологам со всего мира
О компании