Debugging tools for Windows что это за программа

Как найти источник проблем с помощью отладчика Windows

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

Чтобы помочь читателям в решении подобных проблем, предлагаю несколько рекомендаций, на которые не имеющие большого опыта в области отладки администраторы смогут на первых порах опереться. Я проиллюстрирую эти советы на примере приложения, поддержкой которого мне приходится заниматься, Device Manager. Не стану утомлять читателей подробным описанием всего процесса отладки на уровне сборки той или иной проблемы; вместо этого я расскажу о некоторых базовых приемах отладки.

Совет 1. Откройте процесс в окне отладчика

Когда система не получает никаких сведений о проблеме, можно определить, как протекает процесс, с помощью отладчика (windbg.exe). Более подробные сведения о том, как приступить к работе с отладчиком, можно найти в статье «Диагностика неисправностей: рекомендации администраторам», опубликованной в «Windows IT Pro/RE» № 8 за 2009 год. Перед запуском процесса в отладчике нужно будет открыть командную строку, чтобы ввести в ней имя программы windbg и запустить этот процесс. Открыть командную строку можно с помощью программы Process Explorer (technet.microsoft.com/en-us/sysinternals/bb896653.aspx); чтобы получить доступ к командной строке, дважды щелкните на процессе, и вы увидите командную строку, отображенную на вкладке Image.

6 Debug工具

Открыв окно отладчика Windows из группы Debugging Tools for Windows меню Start, можно запустить диспетчер Device Manager, выбрав в меню File элемент Open Executable. Введите командную строку, которая обычно используется для инициализации процесса.

Совет 2. Получите максимум данных до начала процесса отладки

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

Если, к примеру, ваше приложение сообщает об ошибке, поясняя, что не удалось открыть некий раздел реестра, требуется выяснить, какая именно функция ответственна за открытие этих разделов. А как можно определить функции, применяемые для решения различных задач? Иногда ответ содержится в названии функции, но можно воспользоваться MSDN, сетью для разработчиков на платформе Windows, чтобы выяснить, какие вызовы происходят. К примеру, быстрый поиск по ключевым словам registry functions позволит вам обнаружить документы MSDN с перечислением этих функций по адресу msdn.microsoft.com/en-us/library/ms724875(VS.85).aspx. И там вы увидите, что для открытия разделов реестра используется функция RegOpenKeyEx.

Для получения информации о соответствующих функциях можно воспользоваться бесплатно распространяемым средством Dependency Walker (depends.exe), доступным для загрузки по адресу www.dependencywalker.com. Программа Dependency Walker показывает, какие библиотеки DLL используются двоичным файлом, а также имена функций, применяемых файлом из DLL.

超好用的Chrome DevTool Debug 技巧 | 幫你省下不少時間！

Получить эти сведения просто: запустите программу depends.exe, затем откройте исследуемый двоичный файл с помощью команды open из меню File. После этого Dependency Walker отобразит имена функций, вызываемых данным приложением при его выполнении. Эта информация будет иметь большое значение при проведении операции отладки, поскольку она позволяет выявить интересные вызовы, которые, возможно, имеют отношение к рассматриваемой проблеме. Так, если ваше приложение выдает сообщение о том, что попытка сетевого соединения не удалась, нужно просмотреть выходные данные Dependency Walker и найти там имена функций, которые, по-видимому, имеют отношение к установлению сетевых соединений. Затем вы сможете с помощью отладчика расследовать соответствующие вызовы.

В качестве примера давайте воспользуемся Dependency Walker для открытия файла devmgr.dll. Этот бинарный файл содержит код, который программа mmc.exe задействует для создания оснастки Device Manager. Как видно на экране 1, Dependency Walker показывает, что файл devmgr.dll импортирует различные функции, связанные с перечислением устройств, из файла setupapi.dll. Если вас интересует вопрос, как я определил, что файл devmgr.dll представляет собой библиотеку DLL, применяемую для создания диспетчера Device Manager, поясняю, что файл devmgmt.msc фактически является XML-файлом, упоминающим файл devmgr.dll в тексте. Чтобы его открыть, можно воспользоваться редактором Notepad.

Совет 3. Установите точки прерывания

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

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

Вы можете установить точку прерывания против функции с помощью команды bp (set breakpoint). Далее можно воспользоваться командой g (go), чтобы возобновить выполнение потоков процесса до тех пор, пока другие обстоятельства не заставят отладчик вновь приостановить процесс. Ниже приводятся соответствующие команды и выходные данные:

0: 000> bp setupapi! CM_Get_Device_ID_
List_ExW
0: 000> g
Breakpoint 0 hit

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

В предыдущем фрагменте кода отладчик проинформировал нас о том, что мы дошли до точки прерывания «ноль». Составить список этих точек прерывания можно с помощью команды bl (breakpoint list). У нас имеется лишь одна точка прерывания, и она имеет номер ноль.

0: 000> bl
0 e 770 edf2 d
0001 (0001)
0:****
setupapi! CM_Get_
Device_ID_List_
ExW

Итак, каким же образом искать имена функций, против которых целесообразно поставить точки прерывания? Команда x (examine symbols) может использовать информацию о символах для получения функций и других данных, соответствующих шаблону. В примере, приведенном на экране 2, перечисляются все символьные данные, соответствующие шаблону *Devices* из модуля devmgr. Затем вы сможете установить точки прерывания против любой из этих функций.

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

0: 000> sxe ld: setupapi
0: 000> g
ModLoad: 770 e0000 771 e8000 c:
windowssystem32setupapi.dll

Совет 4. Определите поток вызовов

При достижении точки прерывания вы сможете выяснить, какая команда вызвала данную функцию и какую процедуру упомянутая функция вызывает (т. е. определить поток вызовов), проанализировав стек с помощью команды kC (отобразить обратную трассировку стека). В нашем примере я выполнил команду kC по достижении точки прерывания, которую я выставил на setupapi! PNP_GetDeviceList.

Приращение стеков происходит снизу вверх. Это значит, что в начале списка отображается функция, которая вызывалась последней. В результате выполнения команды kC будет отображен стек, образовавшийся при достижении точки прерывания, которая была установлена на setupapi! PNP_GetDeviceList. Модуль devmgr.dll вызвал файл setupapi.dll для формирования списка устройств.

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

В примере, показанном на экране 3, я использовал параметр -l2 для ограничения глубины выходных данных двумя уровнями. В этом примере функция setupapi! PNP_Get-DeviceList вызвала функцию setupapi! NdrClientCall2, которая, в свою очередь, вызвала функцию rpcrt4! NdrClientCall2.

Совет 5. Определите, была ли после вызова функции возвращена ошибка

Допустим, точка прерывания, установленная вами для некоей функции, достигнута. Как определить, возвратили ли эти функции сообщение об ошибке? Нужно запустить команду gu (go up), чтобы вернуться из функции, а затем применить команду r, чтобы исследовать возвращенное значение.

Команда gu возобновляет выполнение до возвращения результата текущей функцией. В данном случае команда gu запускает функцию PNP_GetDeviceList, а затем останавливает исполнение непосредственно по завершении выполнения функции. Команда r (register) возвращает содержимое регистров.

Переменная $retreg представляет регистр возврата, который можно использовать для определения того, закончилось ли выполнение функции успешно или она вернула сообщение об ошибке. Мы получили сообщение об ошибке с кодом 0x1d от функции PNP_Get-DeviceList(). Я обнаружил, что возвращенное значение для функции PNP_GetDeviceList было задокументировано в файле, размещенном по адресу msdn.microsoft.com/en-us/library/cc239018(PROT.10).aspx: An error occurred during an attempt to read the registry.

Заключительные шаги

Проблема диспетчера устройств была решена с использованием команды p (step), выполняющей трассировку процесса выполнения функции. Трассировка в ходе отладки показала, что функция setupapi! PNP_GetDeviceList осуществила удаленный вызов процедуры, направленный на интерфейс 8d9f4e40-a03d-11ce-8f69-08003e30051b.

С помощью монитора процессов я обнаружил, что на этот удаленный вызов процедуры ответила функция umpnpmgr.dll! PNP_GetDeviceList (), которая выполнялась в процессе services.exe. Этот вызов завершился с ошибкой NAME_NOT_FOUND вследствие повреждения реестра. Я перезагрузил систему, используя конфигурацию Last Known Good registry configuration. Проблема была решена!

Райан Мангипано — инженер по технической поддержке подразделения Microsoft Global Escalation Services. Специализируется на диагностике ядра Windows и новых методах отладки. Дополнительная информация по отладке Windows — по адресу blogs.msdn.com/ntdebugging

Источник: www.osp.ru

Debugging tools for windows что это за программа

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

• Позволяет расшифровать минидамп любой ОС Windows

Операционная система:Windows 2000/ХР/Vista/7. Server 2000/2003/2008.

Скачать для х 86:
Скачать для х 64:
Небольшой FAQ по синим окнам

Как пользоваться программой

Если у вас опция создания дампа памяти уже была включена – тогда ситуация проще: вам не нужно будет ждать следующей ”аварии”, чтобы выяснить причину. Скорее всего, в папке файл C:Windows вы найдёте файл MEMORY.DMP или в C:windowsminidump файлы Mini112110-01.dmp. Чтобы его ”прочитать”, потребуется программа windbg из пакета Debugging Tools for Windows (объём примерно 16 Мб). Далее так:

1. В папке программы, обычно это C:Program FilesDebugging Tools for Windows (x86), находим программу windbg.exe, запускаем её под учётной записью с правами администратора.
2. В меню выбираем пункт File/Open Crash Dump (иконка на тулбаре – это другой пункт меню).
3. Находим файл дампа MEMORY.DMP в папке C:Windows, открываем.
4. Появится окно с текстом и со строкой ввода внизу, вводим в эту строку: !analyze –v (да, там вначале восклицательный знак) и нажмаем Enter.
5. Получим порцию текста. Самый интересный для нас – это MODULE_NAME. Находим имя модуля (в моём случае это был iaStor), щёлкаем по нему мышью – узнаем подробнее:
Image path: SystemRootsystem32DRIVERSiaStor.sys

То есть проблема была вызвана драйвером iaStor. Порывшись в интернете, я нашёл, что это часть драйвера Intel Matrix Storage Manager. После обновления драйвера проблем не возникало.

!analyze –v команда анализа дампа.

Источник: 4pda.to

Сборка исследовательского ядра Windows и работа с отладчиком

1. Скачайте Windows Software Development Kit ( SDK ) for Windows 8 по следующему адресу:

Замечание. Данный дистрибутив предназначен для работы на операционных системах Windows 7 и Windows 8.

Загрузится программа инсталлятор (sdksetup.exe) размером около 1 Мб, после чего следует её запустить. Откроется следующее окно:

Выберите пункт Install the Windows Software Development Kit to this computer , нажмите кнопку Next .

При желании можете поучаствовать в программе улучшения продуктов Microsoft на основе опыта пользователей ( Customer Experience Improvement Program) или отказаться от участия в ней:

На следующем шаге, если на вашем компьютере не установлен . NET Framework 4.5, программа инсталлятор предупредит, что без его наличия компонент . NET Framework 4.5 SDK не установится. Нам он не нужен, поэтому можно пропустить этот шаг (нажмите Next ):

Прочитайте лицензионное соглашение и, если согласны с ним, нажмите Accept.

В следующем окне уберите все галочки, кроме Debugging Tools for Windows и нажмите Install :

Во время установки должно работать соединение с Интернетом.

После завершения установки программу WinDbg можно запустить (в Windows 7) из меню Пуск – Все программы – Windows Kits – Debugging Tools for Windows ( X86 ) – WinDbg ( X86 ).

Задание 5. Настроить отладчик WinDbg для отладки ядра.

Указания к выполнению.

1. Сначала необходимо задать настройки виртуальной машины.

В меню Action выберите пункт Settings. В левой панели выберите пункт COM1, в поле Named pipe введите следующий текст:

\.pipedebugPipe

Нажмите кнопку ОК.

2. Установите пути к отладочным символам в настройках отладчика WinDbg.

Запустите отладчик WinDbg. В меню File выберите пункт Symbol File Path (или просто нажмите Ctrl+S). Откроется окно Symbol Search Path , в которое нужно ввести пути к файлам с отладочными символами. Введем два пути:

• путь к файлу отладочной информации WRK – wrkx86.pdb (например, C:WRK-v1.2basentosBUILDEXE);
• путь к файлам с отладочными символами других компонентов Windows – можно указать отладчику скачать эти данные с сайта Microsoft и сохранить их в папке на жестком диске, например C:Symbols.

В окне Symbol Search Path введите следующий текст:

c:WRK-v1.2 base ntos BUILD EXE;

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

Обратите внимание, что текст должен идти без пробелов и переносов строк:

3. Установить путь к исходному коду WRK в настройках отладчика WinDbg.

В меню File выберите пункт Source File Path (или нажмите Ctrl+P). Откроется окно Source Search Path , в которое нужно ввести путь к исходным файлам WRK, например, C:WRK-v1.2 base :

4. Установить соединение отладчика WinDbg с виртуальной машиной.

В меню File выберите пункт Kernel Debug (или нажмите Ctrl+K). Откроется окно Kernel Debugging .

Установите следующие значения на вкладке COM в этом окне:

• Baud Rate: 115200
• Port: \.pipedebugPipe
• Pipe: отметить
• Reconnect: отметить
• Resets: 0

Нажмите кнопку OK, при этом начнется процесс подключения к виртуальной машине по COM порту. На вопрос о сохранении информации ( Save information for workspace ) можете ответить Yes.

Запустите виртуальную машину. В меню загрузки выберите Windows Research Kernel [ debugger enabled ]. В процессе загрузки в окне Command отладчика должна появиться следующая информация :

5. Узнать информацию о загруженных модулях.

Остановите процесс выполнения виртуальной машины, нажав кнопку на панели инструментов отладчика, или выбрав в меню Debug пункт Break , или нажав Ctrl+ Break .

Отладчик перейдет в режим ввода команд (внизу окна Command сделается активной строка для текстового ввода с подсказкой kd>):

При этом виртуальная машина будет недоступна для любого взаимодействия с пользователем.

В строке команд отладчика введите команду:

где заглавная буква D – параметр команды lm, отображающей список загруженных модулей.

В окне Command выведется список всех загруженных модулей (на рисунке показана только часть вывода):

Обратите внимание на информацию об отладочных символах справа от модулей ntdll и nt.

Если щелкнуть по названию модуля nt (или ввести команду lmDvmnt), то отобразится более подробная информация о данном модуле:

Чтобы продолжить работу виртуальной машины нажмите F5, или нажмите кнопку на панели инструментов отладчика, или введите команду g в окне команд.

Дальше >>
< Лекция 5|| Самостоятельная работа 1: 1 2 3 4 || Лекция 6 >

Вопросы и ответы

Екатерина Гастева

Добрый день. Не работают ссылки для скачивания на начальном этапе первой самостоятельной работы. Возможно и далее встречаются старые ссылки. Как быть с этим?

Может есть какой-то более новый несложный курс по устройству windows c практическими заданиями? Заранее спасибо.

«1. Скачайте и установите программу виртуализации Microsoft Virtual PC 2007 SP1, доступную по адресу:

» Microsoft Windows Server 2003 SP1 » также не находится.

Источник: intuit.ru

Debugging tools for windows что это за программа

• Language ▼

• English
• Français
• Nederlands
• 日本語
• Deutsch
• Español
• Italiano
• Português (EU)
• Português (BR)
• Dansk
• Cestina
• العربية
• 中文 (漢語)
• 中文 (汉语)
• Türkçe
• Русский
• Polski
• Svenska
• Norsk
• Suomi
• 한국말
• Română
• Ελληνικά
• Magyar

Debugging Tools for Windows

	Имя разработчика:	Microsoft Corporation
	Категория программного обеспечения:	Средства разработчика
	Подкатегория программного обеспечения:	Отладка
	Операционная система:	Windows

Обзор программного обеспечения

Средства отладки для Windows, используются для отладки драйверов, приложений, а также услуг по системам Windows.

Поиск типов файлов

Связанные разделы реестра

HKEY_LOCAL_MACHINESOFTWAREMicrosoftCorporationDebuggingToolsforWindows
HKEY_CURRENT_USERSOFTWAREDebuggingToolsforWindows

Поддерживаемые расширения файлов

Расширение файла Тип расширений файлов Создатель/разработчик типа файла

LGV	Debugging Tools For Windows Logger Log	Microsoft Corporation

Продукт Solvusoft

Просмотрите расширения файлов в алфавитном порядке: # A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Источник: www.solvusoft.com

dumpchk.exe что это за программа?

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

Официальная информация

Нашел сайт Майкрософт, где пишется что dumpchk.exe — сервисная консольная утилита проверки корректности создания файла дампа пмяти. Также сказано — программа не требует доступа к символам, что это значит — к сожалению непонятно. Случайно узнал — файлы символов оказывается находятся здесь:

Скорее всего dumpchk.exe — команда консоли. Однако у меня стоит десятка — запустил командную строку, хотел вызвать справку по команде — ошибка, мол не является внутренней или внешней командой:

Я поспешил — на сайте Майкрософт сказано — dumpchk.exe находится на компакт-диске Win XP, на сегодняшний день это устаревшая система. Вроде бы даже если установить XP — dumpchk.exe будет отсутствовать, чтобы появился, необходимо установить средства поддержки из папки SupportTools установочного диска XP. По умолчанию программа установится в эту папку:

C:Program FilesSupport Tools

На заметку — компонент также входит в состав Debugging Tools for Windows (как понимаю это инструменты для отладки). Также вроде бы dumpchk.exe присутствует в Windows Automated Installation Kit (WAIK).

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

При успешной установки команда станет доступной из консоли. Для вызова консоли (cmd):

1. Зажмите Win + R
2. Введите cmd.exe
3. Нажмите ОК.

После всех шагов появится черное окно — это командная строка/консоль (Command line).

Какие параметры существуют?

Параметры указываются после указания самой команды, через пробел. На сайте Майкрософт не совсем понятно написано как работать с параметрами. Поэтому пришлось еще поискать информации — нашел. Итак, смотрите:

Вы открываете консоль. Как — написал выше.

Далее нужно прописать dumpchk.exe. Если установили Debugging Tools for Windows (DTW) — указывайте в таком виде:

C:Program FilesDebugging Tools for Windows (x86)dumpchk.exe

Нужно прописывать полный путь. Если установили средства поддержки — возможно команда будет в папке:

Кстати, возможно Debugging Tools for Windows и есть средства поддержки.

Далее нужны файлы символов, мы выяснили, они находятся здесь:

Аварийный файл находится как правило здесь (название файла приведено для примера):

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

«C:Program FilesDebugging Tools for Windows (x86)dumpchk.exe» -y C:WINDOWSSymbols C:WINDOWSMinidumpMini010609-01.dmp

Буква -y в строке — параметр, необходим как раз для поиска символов. Кроме него есть другие:

1. -? — показывает справку по команде.
2. -p — печатает только заголовок, не совсем понятно что имеется ввиду.
3. -v — режим подробного вывода.
4. -c — проверка файла дампа.
5. -x — дополнительная проверка.
6. -e — анализ дампа.
7. -q — быстрая проверка (не применима в XP).

Также с dumpchk.exe может быть ошибка (Application Error):

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

Как открыть настройки файла дампа?

На заметку. В Виндовс 10 чтобы открыть настройки файла дампа (файлы идут с расширением dmp, стандартное название — MEMORY.DMP):

1. Необходимо открыть Свойства системы — в панели управления значок Система:
2. Нажать Дополнительные параметры:
3. На вкладке Дополнительно внизу будет раздел Загрузка и восстановление, нажать Параметры:
4. Появится окно Загрузка и восстановление, где и будут сами настройки:

Важно: без необходимости настройки не менять!

Заключение

dumpchk.exe — компонент по работе с файлом дампа памяти, устанавливается как понимаю вручную. Файл создается при возникновении сбоя системы — может помочь выявить проблему.

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

Выяснил еще — dumpchk.exe содержится и в дистрибутиве Win2k Server.

Настоятельно рекомендую посетить официальный сайт Майкрософт, где сказано об этой команде.

Источник: virtmachine.ru