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:
- Для версии 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 .
По окончании инсталляции рабочие директории комплекта 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 | Отладчик режима пользователя и режима ядра с графическим интерфейсом. |
on June 22, 2010
Previously Windbg was available separately to download. But for the latest versions, Microsoft keeps it as part of Windows SDK. Please find the download links below.
Windows 10
The latest version of Windbg for Windows 7 can be downloaded from the link https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
Windows 7
Download installers from the above links. Note that this does not download the whole SDK, it’s just an installer. Once you run the file, you can select which tools you would like to be downloaded. If you are interested only in Windbg, you can exclude everything else and only select ‘Debugging tools’ under ‘Common Utilities’
The above package installs windbg 6.12 version. If you want to quick install windbg, you can go for older version(6.11) which can be downloaded from
the link given at the end of this post.
Once you do the installation, you can find the program in Start Menu -> All Programs -> Debugging Tools for Windows -> Windbg
Такие типы сбоев обычно связаны со сбойным драйвером, который бывает трудно вычислить. Тем не менее, улучшенная система отслеживания ошибок в 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.
Решить свою проблему
Теперь подождите очередного сбоя с синим экраном, и последующего окончания перезагрузки компьютера. Затем еще раз запустите WinDbg (пользователям Vista необходимо запускать программу от имени администратора), кликните по меню File, выберите открытие сбойного дампа Open Crash Dump, откройте файл \Windows\MEMORY.DMP, и программа незамедлительно начнет его анализировать.
К сожалению, WinDbg предоставляет очень мало информации о том, что она делает, поэтому вы можете даже подумать, что программа зависла. Однако подождите. Поймите, анализ, скажем, 4GB памяти на не очень мощном компьютере может занять некоторое время, вплоть до часов. Поэтому наберитесь терпения, а лучше оставьте анализ на ночь.
Впрочем, обычно результат получается уже через несколько минут. Об этом свидетельствует строка анализатора ошибки Bugcheck Analysis, сообщающая нечто вроде "Probably caused by: UACReplace.sys". В переводе на русский это означает, что проблема, возможно, вызвана файлом UACReplace.sys. Введите его в строку поиска, например, Google и вы узнаете его реальное происхождение. В частности, если он принадлежит одной из установленных вами программ или установленному драйверу, то вы можете просто попытаться обновить ее или его. Возможно, это решит возникшие у вас проблемы.
Надо сказать, что время от времени WinDbg не может назвать имени файла совсем или просто выбирает одну из DLL-библиотек Windows. Если это произошло и у вас, то просто кликните по командному окну над панелью статуса и наберите команду:
После этого нажмите Enter. Это предоставит вам более детальный отчет, в котором может содержаться информация о возможных причинах ваших бед.
Если же и в этот раз вам не повезет, не отчаивайтесь. Отладка является довольно сложным делом даже для экспертов. Поэтому просто закройте WinDbg и запустите анализатор снова после следующего сбоя. Возможно, это даст вам несколько больше информации. Удачи!
Раньше я не знал, что такое сабж и не умел его использовать. Теперь немного узнал и впечатлён. Расскажу про свой опыт общения с ним, может кому-то будет полезно.
Например, как получить мемори лики для любой программы:
Нам понадобится 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.
