Microsoft 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 и запустите анализатор снова после следующего сбоя. Возможно, это даст вам несколько больше информации. Удачи!

Анализ аварийных дампов 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. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%\Minidump.

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

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

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

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

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

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

Запускаем 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.

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

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

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

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

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

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

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

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

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

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

1. Откроем “Start->Administrative Tools->Internet Information Services (IIS) Manager”.
2. Развернем папку”Web Sites”.
3. В контекстном меню элемента “Default Web Site “выберем пункт “New->Virtual Directory…”
4. В окне приветствия щелкнем “Next”.
5. В поле “Alias” введём “ Symbols” и нажмем кнопку “Next”.
6. В поле “Path” введём “C:\Symbols” и нажмем кнопку “Next”.
7. Уберём галочку с поля “Run scripts” и “Browse”.
8. Нажмем кнопку “Next” и “Finish”.

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

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

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

1. Откроем “Start->Administrative Tools->Internet Information Services (IIS) Manager”.
2. В контекстном меню элемента “Application Pools выберем New->Application Pool”.
3. В поле “Application ID” введём “SymSrv Pool”. И нажмем Ok.
4. В контекстном меню элемента “SymSrv Pool” выберем пункт “Properties”.
5. Выберем вкладку “Identity”, выберем радио-кнопку “Predefined” и в комбо-боксе выберем пункт “Network Service” и нажмем Ok.
6. Развернем ветку “Web Sites->Default Web Site”.
7. В контекстном меню элемента “Symbols” выберем пункт “Properties”.
8. На вкладке “Virtual Directory” нажмем кнопку “Create”.
9. В комбо-боксе “Application Pool” выберем “SymSrv Pool” и нажмем Ok.
10. В контекстном меню “Default Web Site” выберем пункт “Properties”.
11. Выберем вкладку “ISAPI Filters” и нажмем кнопку “Add”.
12. В поле “Filter Name” напишем “SymProxy”, в поле “Executable” введем “%WINDIR%\system32\inetsrv\symproxy.dll”.
13. Нажмем “Ok” чтобы закрыть окно “Filter Properties”.
14. Нажмем “Ok” чтобы закрыть окно “Default Web Site Properties”.

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

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

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

Резюме

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

Заключение

Анализ дампов после 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 (адрес в памяти инструкции, которая выполняла операцию чтения)

3.

FAULTING_IP:
myfault+5ab
badbc5ab 8b08            mov     ecx,dword ptr [eax]
Здесь показана непосредственно инструкция которая выполнялась – операция записи в регистр ecx содержимого по адресу указанному в eax. Эта инструкция находится по адресу myfault+5ab и относится к драйверу myfault.sys (myfault – это имя драйвера).

4.

PROCESS_NAME:  NotMyfault.exe

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

5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состав Debugging Tools for Windows

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

Знакомство с WinDBG – Часть 1

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

Автор: Брэд Антониевич (Brad Antoniewicz)

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

Эта первая статья из цикла, посвященного WinDBG. Перечень всех статей, входящих в этот цикл:

• Часть 1 – установка, интерфейс, символы, удаленная/локальная отладка, система помощи, модули, регистры.
• Часть 2 – точки останова.
• Часть 3 – инспектирование памяти, пошаговая отладка программ, советы и трюки.

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

Установка WinDBG

По сравнению с Windows 7 процесс установки WinDBG в Windows 8 претерпел небольшие изменения. В этом разделе мы рассмотрим установку отладчика для обеих операционных систем.

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

В Windows 8 WinDBG включается в пакет Windows Driver Kit (WDK). Вы можете установить Visual Studio и WDK или установить отдельно пакет «Debugging Tools for Windows 8.1», который включает WinDBG.

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

Рисунок 1: Выбор типа установки

В следующем окне вам необходимо снять флажки со всех пунктов кроме «Debugging Tools for Windows» и нажать на кнопку «Download».

Как только установщик закончит свою работу, зайдите в директорию, куда загрузился пакет (по умолчанию это c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) и пройдите процедуру установки.

Установка WinDBG в Windows 7 и более ранних версиях

Для Windows 7 и более ранних версий WinDBG входит в состав пакета «Debugging Tools for Windows», который включен в состав Windows SDK и .Net Framework. От вас потребуется загрузить инсталлятор, а затем в процессе установки выбрать «Debugging Tools for Windows».

Во время установки я выбираю опцию «Debugging Tools» в разделе «Redistributable Packages», чтобы создать автономный инсталлятор для облегчения последующих установок.

Рисунок 2: Выбор опций установки для создания автономного инсталлятора

По завершению установки, у вас должны появиться инсталляторы WinDBG для различных платформ (в директории c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\ ).

Рисунок 3: Папка с инсталляторами WinDBG для различных платформ

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

Интерфейс WinDBG

Рисунок 4: Внешний вид WinDBG

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

Самое основное, что вам необходимо знать об интерфейсе отладчика, - командное окно, которое состоит из двух областей. Первая область: окно, где выводится результат выполнения команд. Вторая область: небольшое текстовое поле для ввода команд.

Рисунок 5: Командное окно WinDBG

Символы

В большинстве случаев WinDBG не требует особых настроек и корректно работает прямо «из коробки». Но одну важную вещь, которую необходимо настроить, - это символы. Символы – это файлы, которые генерируются вместе с исполняемым файлом во время компиляции программы и содержат отладочную информацию (функции и имена переменных). Отладочная информация позволяет исследовать функциональность приложения во время отладки или дизассемблирования. Многие компоненты Microsoft компилируются вместе с символами, которые распространяются через Microsoft Symbol Server. С остальными исполняемыми файлами все не так радужно, - очень редко файлы с отладочной информацией идут в комплекте с приложением. В большинстве случаев компании ограничивают доступ к подобной информации.

Чтобы настроить WinDBG на использование Microsoft Symbol Server зайдите в раздел File:Symbol File Path и установите путь SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols. Конечно, немного странно, что звездочки используются в качестве разделителя. После того, как вы настроите Microsoft Symbol Server, символы загрузятся в папку C:\Symbols.

Рисунок 6: Настройка Microsoft Symbol Server

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

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder

Добавление символов во время отладки

Если вам нужно импортировать символы во время отладки, то можно сделать это при помощи .sympath (окно для ввода команд появится, когда вы подцепитесь к процессу). К примеру, чтобы добавить папку c:\SomeOtherSymbolFolder, введите следующую команду:

0:025> .sympath+ c:\SomeOtherSymbolFolder
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\someothersymbolfolder

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

0:025> .reload
Reloading current modules
................................................................
...............................................

Проверка загруженных символов

Чтобы увидеть, для каких модулей загружены символы, вы можете воспользоваться командой x*!. Хотя WinDBG загружает символы только по мере надобности, команда x*! покажет символы, которые могут быть загружены. Можно принудительно загрузить символы при помощи команды ld * (на это может уйти некоторое время, и вы можете остановить этот процесс, зайдя в Debug:Break).

Рисунок 7: Принудительная загрузка символов

Теперь мы можем увидеть символы для каждого модуля.

Рисунок 8: Перечень символов

Отладка локального процесса

При отладке локального процесса у вас есть два пути:

1. Подцепиться к уже запущенному процессу.
2. Запустить процесс через WinDBG.

У каждого способа есть свои преимущества и недостатки. Если, допустим, вы запустили программу через WinDBG, то вам доступны некоторые специальные отладочные опции (например, отладка кучи), которые могут привести к краху приложения. С другой стороны, существуют также и программы, которые аварийно заканчиваются свою работу, когда вы цепляете к ним отладчик. Некоторые приложения (в особенности, вредоносы) во время запуска проверяют присутствие отладчика в системе и, соответственно, в этом случае имеет смысл цепляться к уже запущенному процессу. Иногда происходит отладка службы под управлением ОС Windows, которая устанавливает некоторые параметры во время запуска, так что для упрощения процесса отладки, также лучше подцепляться к запущенному процессу, а не запускать службу через отладчик. Некоторые люди утверждают, что запуск процесса через отладчик серьезно сказывается на производительности. Короче говоря, попробуйте и то и другое и выберите то, что подходит вам лучше всего. Если вы по каким-то причинам предпочитаете какой-то конкретный способ, поделитесь своими соображениями в комментариях!

Запуск процесса

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

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

Рисунок 9: Выбор исполняемого файла для отладки

Подключение к процессу

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

Чтобы подцепиться к уже запущенному процессу зайдите в «File:Attach to a Process», а затем выберите PID или имя процесса. Помните о том, что вам необходимо иметь соответствующие права, чтобы подцепиться к процессу.

Рисунок 10: Выбор процесса, к которому нужно подцепиться

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

Отладка удаленного процесса

Возможно, иногда вам будет требоваться отладка процесса на удаленной системе. Было бы намного более удобно решать эту задачу при помощи локального отладчика, вместо использования виртуальной машины или RDP. Или, быть может, вы отлаживаете процесс LoginUI.exe, который доступен только в случае, когда система заблокирована. В подобных ситуациях вы можете использовать локальную версию WinDBG и удаленно подключаться к процессам. Для решения этих задач существует два наиболее распространенных способа.

Существующие отладочные сессии

Если вы уже начали локальную отладку программы (посредством подключения или запуска процесса через WinDBG), то можете ввести определенную команду, и WinDBG запустит «слушатель» (listener), к которому сможет подключиться удаленный отладчик. Для этого используйте команду .server:

.server tcp:port=5005

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

Рисунок 11: Сообщение с предупреждением, которое может возникнуть после запуска команды по создания «слушателя»

Затем WinDBG сообщит, что сервер запущен:

0:005> .server tcp:port=5005
Server started. Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=5005,Server=USER-PC

Теперь вы может подключиться с удаленного хоста к уже существующей отладочной сессии, зайдя в «File:Connect to a Remote Session» и введя в текстовое поле примерно следующее: tcp:Port=5005,Server=192.168.127.138

Рисунок 12: Удаленное подключение к отладочной сессии

После подключения вы получите подтверждение на удаленном клиенте:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Server started. Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=5005,Server=USER-PC
MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

и сообщение в локальной версии отладчика:

MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

Создание удаленного сервера

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

dbgsrv.exe -t tcp:port=5005

Рисунок 13: Запуск удаленного сервера

И опять же вы можете получить предупреждение о безопасности, которое вам следует принять:

Рисунок 14: Сообщение безопасности, которое может возникнуть во время запуска отладочного сервера

К серверу отладки вы можете подключиться, если зайдете в файл «File: Connect to Remote Stub» и введете в текстовое поле следующую строку: tcp:Port=5005,Server=192.168.127.138

Рисунок 15: Подключение к отладочному серверу

После подключения вы не получите каких-то сигналов о том, что вы подключились, однако если вы зайдете в «File:Attach to a Process», то увидите перечень процессов отладочного сервера (там, где запущен dbgsrv.exe). Теперь вы можете подцепляться к процессу, как если бы делали это локально.

Система помощи

Система помощи в WinDBG – великолепна. Помимо изучения чего-то нового, вы должны уметь получать справочную информацию о какой-либо команде. Используйте команду .hh для доступа к справке WinDBG:

windbg> .hh

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

windbg> .hh .reload

Или просто зайдите в раздел «Help:Contents».

Модули

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

После подключения к процессу WinDBG автоматически отобразит загруженные модули. К примеру, ниже показаны модули, после того, как я подключился к calc.exe:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

*** wait with pending attach
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
ModLoad: 77630000 7776c000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 77550000 77624000 C:\Windows\system32\kernel32.dll
ModLoad: 75920000 7596a000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 76410000 77059000 C:\Windows\system32\SHELL32.dll
ModLoad: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
ModLoad: 76300000 76357000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 75cd0000 75d1e000 C:\Windows\system32\GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
ModLoad: 777b0000 777ba000 C:\Windows\system32\LPK.dll
ModLoad: 774b0000 7754d000 C:\Windows\system32\USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
ModLoad: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
ModLoad: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
ModLoad: 74c80000 74c89000 C:\Windows\system32\VERSION.dll
ModLoad: 77770000 7778f000 C:\Windows\system32\IMM32.DLL
ModLoad: 75c00000 75ccc000 C:\Windows\system32\MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
ModLoad: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
ModLoad: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll

Позже в процессе отладки вы можете вновь вывести этот список при помощи команды lmf:

0:005> lmf
start end module name
00a70000 00b30000 calc C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C:\Windows\system32\UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
74c80000 74c89000 VERSION C:\Windows\system32\VERSION.dll
756d0000 756dc000 CRYPTBASE C:\Windows\system32\CRYPTBASE.dll
75920000 7596a000 KERNELBASE C:\Windows\system32\KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C:\Windows\SYSTEM32\sechost.dll
75c00000 75ccc000 MSCTF C:\Windows\system32\MSCTF.dll
75cd0000 75d1e000 GDI32 C:\Windows\system32\GDI32.dll
75e60000 75ee3000 CLBCatQ C:\Windows\system32\CLBCatQ.DLL
75fa0000 76069000 USER32 C:\Windows\system32\USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C:\Windows\system32\SHLWAPI.dll
76360000 76401000 RPCRT4 C:\Windows\system32\RPCRT4.dll
76410000 77059000 SHELL32 C:\Windows\system32\SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C:\Windows\system32\USP10.dll
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
77630000 7776c000 ntdll C:\Windows\SYSTEM32\ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000 LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll

Также вы можете узнать адрес загрузки для конкретного модуля при помощи команды «lmf m»:

0:005> lmf m kernel32
start end module name
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll

Вы также можете получить информацию о заголовке (image header) конкретного модуля при помощи расширения !dh (восклицательный знак указывает на расширение):

0:005> !dh kernel32

File Type: DLL
FILE HEADER VALUES
14C machine (i386)
4 number of sections
4A5BDAAD time date stamp Mon Jul 13 21:09:01 2009

0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL

OPTIONAL HEADER VALUES
10B magic #
9.00 linker version
C4600 size of code
C800 size of initialized data
0 size of uninitialized data
510C5 address of entry point
1000 base of code
----- new -----
77550000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.01 operating system version
6.01 image version
6.01 subsystem version
D4000 size of image
800 size of headers
D5597 checksum
00040000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
140 DLL characteristics
Dynamic base
NX compatible
B4DA8 [ A915] address [size] of Export Directory
BF6C0 [ 1F4] address [size] of Import Directory
C7000 [ 520] address [size] of Resource Directory
0 [ 0] address [size] of Exception Directory
0 [ 0] address [size] of Security Directory
C8000 [ B098] address [size] of Base Relocation Directory
C5460 [ 38] address [size] of Debug Directory
0 [ 0] address [size] of Description Directory
0 [ 0] address [size] of Special Directory
0 [ 0] address [size] of Thread Storage Directory
816B8 [ 40] address [size] of Load Configuration Directory
278 [ 408] address [size] of Bound Import Directory
1000 [ DE8] address [size] of Import Address Table Directory
0 [ 0] address [size] of Delay Import Directory
0 [ 0] address [size] of COR20 Header Directory
0 [ 0] address [size] of Reserved Directory

SECTION HEADER #1
.text name
C44C1 virtual size
1000 virtual address
C4600 size of raw data
800 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
(no align specified)
Execute Read

Debug Directories(2)
Type Size Address Pointer
cv 25 c549c c4c9c Format: RSDS, guid, 2, kernel32.pdb
( 10) 4 c5498 c4c98

SECTION HEADER #2
.data name
FEC virtual size
C6000 virtual address
E00 size of raw data
C4E00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
(no align specified)
Read Write

SECTION HEADER #3
.rsrc name
520 virtual size
C7000 virtual address
600 size of raw data
C5C00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
(no align specified)
Read Only

SECTION HEADER #4
.reloc name
B098 virtual size
C8000 virtual address
B200 size of raw data
C6200 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
(no align specified)
Read Only

Сообщения и исключения

После подключения к процессу вначале отображается список модулей, а затем могут появиться другие сообщения. Например, когда мы цепляемся к calc.exe, WinDBG автоматически устанавливает точку останова (которая является просто маркером, используемым для остановки приложения). Информация о точке останова выводится на экран:

(da8.b44): Break instruction exception - code 80000003 (first chance)

Конкретно это сообщение является исключением, а именно first-chance исключением. По сути, исключение – это особое состояние, возникающее во время выполнения программы. First-chance исключение означает, что программа остановилась сразу же после появления исключения. Second-chance исключение означает, что после возникновения исключения будут выполнены некоторые операции, а потом программа остановит свою работу.

Регистры

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

После подключения к calc.exe WinDBG автоматически отображает информацию о следующих регистрах:

eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

Позже можно продублировать эту информацию еще раз при помощи команды r:

0:005> r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3

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

0:005> r eax
eax=7ffd9000

Информацию одновременно из нескольких регистров можно получить так:

0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8

Указатель на инструкцию

Последняя команда посвящена запускаемым инструкциям. Здесь информация также выводится на экран, как и в случае с командой r, того, что содержит регистр EIP. EIP – это регистр, содержащий местонахождение следующей инструкции, которую должен выполнить процессор. То, что отображает WinDBG, – эквивалент команды u eip L1, после выполнения которой WinDBG идет по адресу, указанному в регистре EIP, преобразует этот участок в ассемблерный код и отображает его на экране.

ntdll!DbgBreakPoint:
77663540 cc int 3

Оставайтесь на связи

В следующих статьях мы рассмотрим, как использовать WinDBG в боевых условиях: точки останова, пошаговую отладку и просмотр памяти. Не переключайтесь! J.

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

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

В этой статье

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

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

Важно

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

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

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

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

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

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

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

Путь символов для отладчиков 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 .

 .кеш симпата * 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  

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

Например, следующая команда указывает отладчику использовать сервер символов для получения символов из хранилища по адресу 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 (WinDbg, KD, CDB, NTSD) - драйверы Windows

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

В этой статье

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

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

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

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

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

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

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

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

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

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

В этой статье

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

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

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

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

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

Символы Windows

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

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

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

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

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

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

В этой статье

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

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

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

  0: 000> мл  

  0: 000> .sympath Текущий путь к символу: d: \ MyInstallation \ i386 \ symbols \ retail  

  0: 000>.перезагрузить ModuleName  

  kd>! Sym шумный kd> .reload NT 1: Проверено ядро ​​версии 2081 MP 2: База ядра = 0x80400000 PsLoadedModuleList = 0x80506fa0 3: DBGHELP: FindExecutableImageEx-> Ищем D: \ MyInstallation \ i386 \ ntkrnlmp.exe ... несоответствующая отметка времени 4: DBGHELP: файл изображения для ntkrnlmp.exe недоступен 5: DBGHELP: FindDebugInfoFileEx-> Ищу 6: d: \ MyInstallation \ i386 \ symbols \ retail \ symbols \ exe \ ntkrnlmp.dbg ... нет файла 7: DBGHELP: FindDebugInfoFileEx-> Ищу 8: d: \ MyInstallation \ i386 \ symbols \ retail \ symbols \ exe \ ntkrnlmp.pdb ... нет файла 9: DBGHELP: FindDebugInfoFileEx-> Ищем d: \ MyInstallation \ i386 \ symbols \ retail \ exe \ ntkrnlmp.dbg ... ОК 10: DBGHELP: LocatePDB-> Ищем d: \ MyInstallation \ i386 \ symbols \ retail \ exe \ ntkrnlmp.pdb ... ОК 11: *** ВНИМАНИЕ: контрольная сумма символов и метка времени неверны 0x0036a4ea 0x00361a83 для ntkrnlmp.exe  

  ImgHlpFindDebugInfo (00000000, module.dll, c: \ MyDir; c: \ SomeDir, 0823345, 0) не удалось  

  c: \ MyDir \ symbols \ exe \ ntoskrnl.dbg c: \ SomeDir \ symbols \ exe \ ntoskrnl.dbg c: \ MyDir \ exe \ ntoskrnl.dbg c: \ SomeDir \ exe \ ntoskrnl.dbg c: \ MyDir \ ntoskrnl.dbg c: \ SomeDir \ ntoskrnl.dbg текущий-рабочий-каталог \ ntoskrnl.dbg  

  c: \ MyDir \ symbols \ exe \ ntoskrnl.pdb c: \ MyDir \ exe \ ntoskrnl.pdb c: \ MyDir \ ntoskrnl.pdb c: \ SomeDir \ symbols \ exe \ ntoskrnl.pdb c: \ SomeDir \ exe \ ntoskrnl.PDB c: \ SomeDir \ ntoskrnl.pdb текущий-рабочий-каталог \ ntoskrnl.pdb  

  kd> вертаргет Версия ядра Windows XP 2505 UP Бесплатная совместимость с x86 Построен: 2505.основной. 010626-1514 База ядра = 0x804d0000 PsLoadedModuleList = 0x80548748 Время сеанса отладки: Пн, 02 июля, 14:41:11 2001 Время работы системы: 0 дней 0:04:53  

  kd> u videoprt! Videoportfindadapter2 Загрузка символов для 0xf2860000 videoprt.sys -> videoprt.sys ВИДЕОПРТ! VideoPortFindAdapter2: f2856f42 55 нажимать ebp f2856f43 8bec mov ebp, esp f2856f45 81ecb8010000 sub esp, 0x1b8 f2856f4b 8b4518 mov eax, [ebp + 0x18] f2856f4e 53 толкать ebx f2856f4f 8365f400 и dword ptr [ebp-0xc], 0x f2856f53 8065ff00 и байт ptr [ebp-0x1], 0x0 f2856f57 56 нажмите esi  

  kd> kb Загрузка символов для 0xf28d0000 videoprt.sys -> videoprt.sys Загрузка символов для 0xf9cdd000 glintmp.sys -> glintmp.sys *** ОШИБКА: не удалось загрузить символы для glintmp.sys. ChildEBP RetAddr Args to Child f29bf1b0 8045b5fa 00000001 0000a100 00000030 ntoskrnl! RtlpBreakWithStatusInstruction f29bf1b0 8044904e 00000001 0000a100 00000030 ntoskrnl! KeUpdateSystemTime + 0x13e f29bf234 f28d1955 f9b7d000 ffafb2dc f9b7d000 ntoskrnl! READ_REGISTER_ULONG + 0x6 f29bf248 f9cde411 f9b7d000 f29bf2b0 f9ba0060 ВИДЕОПРТ! VideoPortReadRegisterUlong + 0x27 00000002 00000000 00000000 00000000 00000000 glintMP + 0x1411 [Функции не указаны.]  

  1: kd> 1: kd> kb [местное время 9:50] Загрузка символов для 0xf22b0000 agpcpq.sys -> agpcpq.sys *** ВНИМАНИЕ: контрольная сумма символов неверна 0x0000735a 0x00000000 для agpcpq.sys *** ОШИБКА: не удалось загрузить символы для agpcpq.sys Загрузка символов для 0xa0000000 win32k.sys -> win32k.sys *** ВНИМАНИЕ: контрольная сумма символов неверна 0x00191a41 0x001995a9 для win32k.sys ChildEBP RetAddr Args to Child be682b18 f22b372b 82707128 f21c1ffc 826a70f8 agpCPQ + 0x125b [Функция не указана.] be682b4c a0140dd4 826a72f0 e11410a8 a0139605 agpCPQ + 0x372b [Функция не указана.] be682b80 a00f5646 e1145100 e1cee560 e1cee560 win32k! vPatCpyRect1_6x6 + 0x20b 00000001 00000000 00000000 00000000 00000000 win32k! RemoteRedrawRectangle + 0x32  

  1: kd> kb [местное время 9:49] ChildEBP RetAddr Args to Child be682b18 f22b372b 82707128 f21c1ffc 826a70f8 agpCPQ! AgpReleaseMemory + 0x88 be682b30 f20a385c 82703638 e183ec68 00000000 agpCPQ! AgpInterfaceReleaseMemory + 0x8b be682b4c a0140dd4 826a72f0 e11410a8 a0139605 ВИДЕОПРТ! AgpReleasePhysical + 0x44 be682b58 a0139605 e1cee560 e11410a8 a00e5f0a win32k! OsAGPFree + 0x14 be682b64 a00e5f0a e1cee560 e11410a8 e1cee560 win32k! AGPFree + 0xd be682b80 a00f5646 e1145100 e1cee560 e1cee560 win32k! HeapVidMemFini + 0x49 be682b9c a00f5c20 e1cee008 e1cee008 be682c0c win32k! vDdDisableDriver + 0x3a be682bac a00da510 e1cee008 00000000 be682c0c win32k! vDdDisableDirectDraw + 0x2d be682bc4 a00da787 00000000 e1843df8 e1843de8 win32k! PDEVOBJ__vDisableSurface + 0x27 be682bec a00d59fb 00000000 e1843de8 00000000 win32k! PDEVOBJ__vUnreferencePdev + 0x204 be682c04 a00d7421 e1cee008 82566a98 00000001 win32k! DrvDestroyMDEV + 0x30 be682ce0 a00a9e7f e1843e10 e184a008 00000000 win32k! DrvChangeDisplaySettings + 0x8b3 be682d20 a008b543 00000000 00000000 00000000 win32k! xxxUserChangeDisplaySettings + 0x106 be682d48 8045d119 00000000 00000000 00000000 win32k! NtUserChangeDisplaySettings + 0x48 be682d48 77e63660 00000000 00000000 00000000 ntkrnlmp! KiSystemService + 0xc9