Windows Debugging Tools: диагностика и исправление BSOD. Установка Debugging Tools for Windows Подключение к процессу

Здравствуйте друзья, сегодня разберем интересную тему, которая поможет вам в будущем при появлении синего экрана смерти (BSoD).

Как и мне, так и многим другим пользователям приходилось наблюдать появление экрана с синим фоном, на котором что-то написано (белым по синему). Данное явление говорит о критической неполадке, как в программном обеспечении, например, конфликт драйверов, так и в физической неисправности какого-то компонента компьютера.

Недавно у меня снова появился голубой экран в Windows 10, но я быстро от него избавился и скоро об этом вам расскажу.

Хотите смотреть фильмы онлайн в хорошем качестве? Тогда переходите по ссылке.

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

Есть три типа дампа памяти:

• Полный дамп памяти – эта функция позволяет полностью сохранить содержимое оперативной памяти. Он редко используется, так как представьте, что у вас 32 Гб оперативной памяти, при полном дампе весь этот объем сохранится на диске.
• Дамп ядра – сохраняет информацию о режиме ядра.
• Малый дамп памяти – сохраняет небольшой объем информации о ошибках и загруженных компонентов, которые были на момент появления неисправности системы. Мы будем использовать именно этот тип дампа, потому что она даст нам достаточное количество сведений о BSoD.

Расположение, как малого, так и полного дампа отличается, например, малый дамп находится по следующему пути: %systemroot%minidump.

Полный дамп находится здесь: %systemroot%.

Для анализа дампов памяти существуют различные программы, но мы воспользуемся двумя. Первая – Microsoft Kernel Debuggers, как понятно из названия утилита от Microsoft. Скачать ее можно с официального сайта. Вторая программа – BlueScreenView, бесплатная программка, скачиваем отсюда.

Анализ дампа памяти с помощью Microsoft Kernel Debuggers

Для разных версий систем нужно скачивать свой тип утилиты. Например, для 64-х разрядной операционной системы, нужна 64-битовая программа, для 32-х разрядной – 32-битная версия.

Это еще не все, вам нужно скачать и установить пакет отладочных символов, нужные для программы. Называется Debugging Symbols. Каждая версия данного пакета тоже скачивается под определённою ОС, для начала узнайте какая у вас система, а потом скачивайте. Дабы вам не искать где попало эти символы, вот ссылка на скачивание. Установка, желательно, должна производиться по этому пути: %systemroot%symbols.

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

Прежде чем проанализировать дампы мы кое-что настроим в утилите. Во-первых, нужно указать программе, куда мы установили отладочные символы. Для этого нажимаем на кнопку «File» и выбираем пункт «Symbol File Path», потом указываем путь до символов.

Программа позволяет извлекать символы прямо из сети, поэтому вам даже не придется их скачивать (извините те, кто уже скачал). Они буду браться с сервером Microsoft, поэтому все безопасно. Итак, вам нужно снова открыть «File», потом «Symbol File Path» и ввести следующую команду:

SRV*%systemroot%symbols*http://msdl.microsoft.com/download/symbols

Таким образом мы указали программе, что символы должны браться из сети. Как только мы это сделали нажимаем «File» и выбираем пункт «Save Workspace», потом жмем ОК.

Вот и все. Мы настроили программу на нужный лад, теперь приступаем к анализу дампов памяти.  В программе нажимаем кнопочку «File», потом «Open Crash Dump» и выбираем нужный файл.

Kernel Debuggers начнет анализ файла и после этого выведет результат о причине ошибки.

В появившемся окне можно вводить команды. Если мы введем !analyze –v, то получим больше информации.

Вот и все с этой программой. Чтобы остановить работу отладчика, выберите «Debug» и пункт «Stop Debugging».

Анализ дампа памяти с помощью BlueScreenView

Для анализа различных ошибок и BSoD подойдет и программа BlueScreenView, которая имеет простой интерфейс, поэтому проблем с освоением возникнуть не должно.

Скачайте программу по указанной выше ссылке и установите. После запуска утилиты нужно ее настроить. Зайдите в параметры: «Настройки» – «Дополнительные параметры». Откроется небольшое окошко, в котором есть пару пунктов. В первом пункте нужно указать местонахождение дампов памяти. Обычно они находятся по пути C:WINDOWSMinidump. Тогда просто нажмите кнопку «По умолчанию».

Что можно видеть в программе? У нас есть пункты меню, часть окна с названиями файлов дампов и вторая часть окна – содержимое дампов памяти.

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

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

В интернете можно найти все о коде ошибке и драйвере, который может быть виной BSoD. Для этого нажимаем «Файл», а потом «Найти в Google код ошибки + Драйвер».

Можно сделать показ только драйверов, которые были на момент появления ошибки. Для этого нужно нажать «Настройки» – «Режим нижнего окна» – «Только драйвера, найденные в крэш-стеке». Либо нажать клавишу F7.

Чтобы показать скриншот BSoD нажмите клавишу F8. Для показа всех драйверов и файлов нажимаем F6.

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

Что такое Зеленый экран смерти GSOD

Также не забывайте задавать вопросы в комментариях.

Вчера наткнулся на статью, в которой описывался один из способов применения дебаггера x64dbg. Естественно, для профи это уже пройденный этап, но новичкам может будет интересно. Это не совсем перевод статьи, а скорее заметка для меня (я же не профи 🙂 ) 1. Конфигурация Options ▶ Preferences ▶ Events:

System Breakpoint: When loading a new process, the will cause x64dbg to break in the system function which initializes the application you are attempting to debug.

TLS Callbacks: The TLS Callback is a function which is called before the main application runs. This can set parameters or even be used by certain protectors to implement anti-debug technology. This allows you to break on this function.

Entry Breakpoint: This causes x64dbg to break on the Entry point on the application. For general debugging, this is the only breakpoint you will need to have checked.

DLL Entry: This will break on the entry point of any DLL which is loaded by the process you are debugging.

Thread Entry: This will break on the first instruction of any new thread initialized by the current process.

Attach Breakpoint: When this is checked, it will cause x64dbg to break in the DbgUiRemoteBreakin function when attaching to an active process. If unchecked, it will attach without suspending the process.

DLL Load/DLL Unload: This will break in the system function when a new library(DLL) is loaded into or unloaded from the active process. The DLL Load breakpoint occurs before any of its code is executed.

Thread Start/Thread End: This allows us to break in system when our debugged application initializes or terminates a thread.

2. Скачиваем файл sample.exe (он в архиве SampleApp_bin.zip) 3. Открываем этот файл в x64dbg. Это можно сделать через File ▶ Open, либо просто перетащить файл в окно программы:

Отдельно отмечу, что если приложение 32-бита, то нужно запускать x32dbg.exe, иначе дебаггер не увидит процесс! В этом случае в строке статуса будет выведено предупреждение: «Use x32dbg to debug this file!»

4. Нажимаем F9 чтобы возобновить отладку, появляется окно программы, куда мы вводим любой пароль и нажимаем кнопку «Check»: 5. Пароль «123456» оказался неверным, поэтому появилось сообщение об ошибке «Authentication Failed. Invalid Password!» 6. Теперь, когда мы знаем текст сообщения об ошибке, можно попробовать найти ссылку на эту строку. Для этого нажимаем в окне вкладки CPU правую кнопку мышки и выбираем Search for ▶ Current Region ▶ String references 7. Откроется список адресов на все строковые ссылки используемые в программе. Используя фильтр, можно быстро найти искомую строку:

Authentication Failed. Invalid Password

В файле примера Sample.exe была внесена ошибка (сознательно или нет, не важно), поэтому нужно искать такую строку:

Authentication Failed. Invaild Password!

8. Сделаем на ней двойной щелчок мышкой, так мы перейдем на тот фрагмент кода, где эта строка используется: 9. На скриншоте выше видна красная пунктирная стрелочка, которая указывает на тот участок, где происходило сравнение результатов и дальнейший вызов окна с сообщением о неверном пароле. 10. Клавишей F2 ставим точку останова (breakpoint) на начало функции, которая проверяет пароль: 11. Сначала она пропускает пароль через хэширующий алгоритм, а потом сравнивает результаты с сохраненным в программе значением. 12. Чтобы проверить, какой именно алгоритм хэширования был использован, можно воспользоваться утилитой Hashing Utility 2.0. Нужно ее запустить и ввести там то значение, которое мы вводили ранее: «123456»: 13. Результатом хэширования будет строка «E10ADC3949BA59ABBE56E057F20F883E», получается, что алгоритм хэширования в программе использует MD5. Значит перебирать оригинальный пароль нет смысла, но можно изменить инструкции так, чтобы принимался любой пароль. В участке кода выше оба хэша сравниваются. Если они совпадают, то программа сообщает, что пароль верный. Если нет, то говорит, что пароль неверный. Это значит, если мы заменим инструкцию следующего шага, то все время будет появляться сообщение о правильном пароле, независимо от того так это или нет. В x64dbg нам достаточно переместить курсор на нужную инструкцию и нажать клавишу Пробел, затем сменить адрес на новый: 13. В обычной ситуации, если пароль неверный, произошел бы переход на адрес 59EA68, но мы его поменяли на 59EA5A, поэтому, независимо от того, правильный пароль мы ввели или нет, все время будет сообщение о верном пароле. Нажав на «ОК» изменения записались в память. Теперь можно запустить выполнение программы заново. В результате мы получим сообщение о том, что пароль верный. Действия пункта 13 работают только до тех пор, пока мы не перезапустим приложение, потом все изменения пропадают. 14. Чтобы сделать изменения перманентными, нужно нажать на значок заплатки под главным меню: 15. Сохраняем пропатченый файл под новым именем, запускаем его и вводим любой пароль:

*. Если выделить адрес 59EA4A, нажать на нем ПКМ и выбрать Follow in Dump -> Address: 59EAF8 (В последних версиях x64dbg этот пункт будет другим: Follow in Dump ▶ Constant: sample.000000000059EAF8), то в нижней части x64dbg можно будет выделить 32 символа ASCII и нажать Ctrl+E , после чего откроется окно, в котором можно будет скопировать UNICODE-строку 10db8e415b857a61e18ef5d4db8e4f38: Ее можно вставить в окно поиска на сайте hashkiller.co.uk (Раздел Decrypter/Cracker -> MD5 decrypter). В результате мы узнаем, что зашифрованный пароль был ba321c

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

DenTNT недавно публиковал (посмотреть все)

• SWtOR: Советы для начинающих игроков – 20.12.2021
• WordPress: Запретить переводить текст для Google Translate – 18.12.2021
• Android: Убрать подпись в исходящем письме – 16.12.2021

Задайте вопрос Быстрый доступ

Общий раздел  >  Разное

• Вопрос

• • Перемещено 12 октября 2020 г. 7:58

  11 октября 2020 г. 10:20 Ответить | Цитировать

Ответы

• Подробнее можно прочитать тут:

  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection

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

  Если конфигурация не выполнена, то есть только “видимость” адаптера. 

  This posting is provided “AS IS” with no warranties, and confers no rights.

  • Помечено в качестве ответа 27 октября 2020 г. 19:29

  13 октября 2020 г. 0:56 Ответить | Цитировать

• Спасибо за ссылку прочитал.

  А вот теперь смотрите.Первый скрин, это постоянное состояние ПК,где:

  0 – после включения ПК

  42 – после отключения этого адаптера 11.10.2020г.

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

  Физически его очевидно не существует, так что не важно “включен/задействован” он или нет. 

  Что до сообщений, то судить есть ли проблема или нет по их числу сомнительная практика.

  Я бы рекомендовал оставить все как есть, но наверное большой беды не будет если вы “отключите” данный “адаптер”. Как в том анекдоте про отпиливание ножек от кровати… 🙂

  This posting is provided “AS IS” with no warranties, and confers no rights.

  • Помечено в качестве ответа 27 октября 2020 г. 19:29

  13 октября 2020 г. 6:23 Ответить | Цитировать

• Здравствуйте Посмотрите нижеуказанное обсуждение: What is Microsoft Kernel Debug Network Adapter?

  Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется “как есть” без каких-либо гарантий.

  • Помечено в качестве ответа 27 октября 2020 г. 19:29

  12 октября 2020 г. 16:17 Ответить | Цитировать

Все ответы

• Здравствуйте Посмотрите нижеуказанное обсуждение: What is Microsoft Kernel Debug Network Adapter?

  Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется “как есть” без каких-либо гарантий.

  • Помечено в качестве ответа 27 октября 2020 г. 19:29

  12 октября 2020 г. 16:17 Ответить | Цитировать

• Спасибо Вам за ссылку.

  12 октября 2020 г. 20:15 Ответить | Цитировать

• Спасибо Вам за ссылку.

  Для начала, почему вы решили что он “включен по умолчанию”? 

  This posting is provided “AS IS” with no warranties, and confers no rights.

  12 октября 2020 г. 21:24 Ответить | Цитировать

• 12 октября 2020 г. 22:58 Ответить | Цитировать

• А почему вы решили что ваш конкретный ПК является этаким эталоном “по умолчанию”?

  Вот, скажем, у меня дома 8 ПК (ну так получилось) и этот “адаптер” не только не включен, но его и вовсе нет на всех моих ПК. И, конечно, я ничего не удалял и не выключал, все “по умолчанию”.

  Вот например:

  Кстати, если я правильно припоминаю, при включенной отладке ядра загрузка ОС останавливается на очень ранней стадии и ожидается подключения отладчика… Хотя может быть я путаю с Windows CE, дело давно было…

  This posting is provided “AS IS” with no warranties, and confers no rights.

  13 октября 2020 г. 0:09 Ответить | Цитировать

• Подробнее можно прочитать тут:

  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection

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

  Если конфигурация не выполнена, то есть только “видимость” адаптера. 

  This posting is provided “AS IS” with no warranties, and confers no rights.

  • Помечено в качестве ответа 27 октября 2020 г. 19:29

  13 октября 2020 г. 0:56 Ответить | Цитировать

• Спасибо за ссылку прочитал.

  А вот теперь смотрите.Первый скрин, это постоянное состояние ПК,где:

  0 – после включения ПК

  42 – после отключения этого адаптера 11.10.2020г.

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

  • Изменено 13 октября 2020 г. 5:33

  13 октября 2020 г. 5:16 Ответить | Цитировать

• Спасибо за ссылку прочитал.

  А вот теперь смотрите.Первый скрин, это постоянное состояние ПК,где:

  0 – после включения ПК

  42 – после отключения этого адаптера 11.10.2020г.

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

  Физически его очевидно не существует, так что не важно “включен/задействован” он или нет. 

  Что до сообщений, то судить есть ли проблема или нет по их числу сомнительная практика.

  Я бы рекомендовал оставить все как есть, но наверное большой беды не будет если вы “отключите” данный “адаптер”. Как в том анекдоте про отпиливание ножек от кровати… 🙂

  This posting is provided “AS IS” with no warranties, and confers no rights.

  • Помечено в качестве ответа 27 октября 2020 г. 19:29

  13 октября 2020 г. 6:23 Ответить | Цитировать

• • Изменено 13 октября 2020 г. 19:53

  13 октября 2020 г. 7:17 Ответить | Цитировать

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

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

Режим отладки позволяет решить массу проблем – от небольших сбоев Windows 10 до полного отказа от работы. Впрочем, к нему следует обращаться только опытным пользователям, которые способны найти объяснение каждому своему шагу. В остальных случаях, когда речь идет о новичке, исключать возможность применения режима тоже нельзя. Но в такой ситуации важно изучить инструкцию по активации Debugging и способах его применения на практике.

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

• Откройте «Параметры» через меню «Пуск».

• Перейдите в раздел «Обновление и безопасность», а затем – «Восстановление».

• Под заголовком «Особые варианты загрузки» нажмите на кнопку «Перезагрузить сейчас».

На заметку. Также вы можете открыть дополнительное меню, зажав клавишу «Shift» при выборе варианта «Перезагрузка» в «Пуске».

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

• Перейдите в раздел «Поиск и устранение неисправностей».

• Выберите «Дополнительные параметры», а затем – «Параметры загрузки».

• Найдите в списке пункт, отвечающий за отладку, и нажмите на клавишу, которая отвечает за ее активацию (как правило, это клавиша «F1»).

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

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

• Щелкните ПКМ по иконке «Пуск».
• Откройте Командную строку с правами Администратора.
• Введите запрос «bcdedit /set advancedoptions true».

• Нажмите на клавишу «Enter».

Следом произойдет перезапуск, и расширенные параметры откроются в принудительном порядке. Еще одна проблема связана с выходом из отладки. Чтобы компьютер включался в стандартной конфигурации, необходимо обработать запрос «deletevalue». Впечатать «bcdedit /deletevalue advancedoptions» в вышеупомянутой Командной строке или на появившемся синем экране выбрать опцию «Продолжить».

28.08.2021 17:30 13 Евгений Верещака Информационный портал IT Техник

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

Шаг 1 – Настройка записи малых дампов памяти

Шаг 2 – Установка WinDBG

Для проведения анализа дампов памяти вам понадобится установить отладчик WinDBG, который входит в состав пакета Windows SDK. На момент написания статьи последние доступные версии Windows SDK:

• Пакет SDK для Windows 10 (скачать сетевой установщик)
• Пакет SDK для Windows 8.1 (скачать сетевой установщик)

Шаг 3 – Сопоставление файлов.dmp с WinDBG

Для упрощения процедуры чтения и анализа дампов памяти выполните сопоставление файлов.dmp с WinDBG. Это позволит открывать файлы дампов из проводника сразу в WinDBG минуя его предварительный запуск.

Шаг 4 – Настройка сервера символов для получения файлов символов отладки

Установка и первичная настройка WinDBG завершена. Для того, чтобы изменить его внешний вид можете перейти в меню View – настройки шрифтов вы найдете выбрав пункт Font , а настройки окон консолей в Options .

Шаг 1 – Настройка записи малых дампов памяти

Шаг 2 – Установка WinDBG

Для проведения анализа дампов памяти вам понадобится установить отладчик WinDBG, который входит в состав пакета Windows SDK. На момент написания статьи последние доступные версии Windows SDK:

• Пакет SDK для Windows 10 (скачать сетевой установщик)
• Пакет SDK для Windows 8.1 (скачать сетевой установщик)

Шаг 3 – Сопоставление файлов.dmp с WinDBG

Для упрощения процедуры чтения и анализа дампов памяти выполните сопоставление файлов.dmp с WinDBG. Это позволит открывать файлы дампов из проводника сразу в WinDBG минуя его предварительный запуск.

Шаг 4 – Настройка сервера символов для получения файлов символов отладки

Установка и первичная настройка WinDBG завершена. Для того, чтобы изменить его внешний вид можете перейти в меню View – настройки шрифтов вы найдете выбрав пункт Font , а настройки окон консолей в Options .

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

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

Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

• Мини дамп памяти (Small memory dump) (256 КБ). Этот тип файла включает минимальный объем информации. Он содержит только сообщение об ошибке BSOD, информацию о драйверах, процессах, которые были активны в момент сбоя, а также какой процесс или поток ядра вызвал сбой.
• Дамп памяти ядра (Kernel memory dump) . Как правило, небольшой по размеру — одна треть объема физической памяти. Дамп памяти ядра является более подробным, чем мини дамп. Он содержит информацию о драйверах и программах в режиме ядра, включает память, выделенную ядру Windows и аппаратному уровню абстракции (HAL), а также память, выделенную драйверам и другим программам в режиме ядра.
• Полный дамп памяти (Complete memory dump) . Самый большой по объему и требует памяти, равной оперативной памяти вашей системы плюс 1MB, необходимый Windows для создания этого файла.
• Автоматический дамп памяти (Automatic memory dump) . Соответствует дампу памяти ядра с точки зрения информации. Отличается только тем, сколько места он использует для создания файла дампа. Этот тип файлов не существовал в Windows 7. Он был добавлен в Windows 8.
• Активный дамп памяти (Active memory dump) . Этот тип отсеивает элементы, которые не могут определить причину сбоя системы. Это было добавлено в Windows 10 и особенно полезно, если вы используете виртуальную машину, или если ваша система является хостом Hyper-V.

Как включить создание дампа памяти в Windows?

С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы » (Advanced system settings). Во вкладке «Дополнительно » (Advanced), раздел «» (Startup and Recovery) нажмите кнопку «Параметры » (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал » (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа » (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).

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

Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger ).

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

Утилита WinDBG входит в «Пакет SDK для Windows 10 » (Windows 10 SDK). .

Файл называется winsdksetup.exe , размер 1,3 МБ.

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

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows .

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации.dmp файлов с WinDBG

Для того, чтобы открывать файлы дампов простым кликом, сопоставьте расширение.dmp с утилитой WinDBG.

1. Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы: cd C:Program Files (x86)Windows Kits10Debuggersx64 windbg.exe –IA для 32-разрядной системы: C:Program Files (x86)Windows Kits10Debuggersx86 windbg.exe –IA
2. В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.

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

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

• Откройте WinDBG;
• Перейдите в меню File –> Symbol File Path;
• Пропишите строку, содержащую URL для загрузки символов отладки с сайта Microsoft и папку для сохранения кэша: SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols В примере кэш загружается в папку E:Sym_WinDBG, можете указать любую.
• Не забывайте сохранить изменения в меню File –> Save WorkSpace;

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

SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:Symbols

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages .

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

Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.

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

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: , 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.

Отладчик предлагает выполнить команду!analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?

• Она выполняет предварительный анализ дампа памяти и предоставляет подробную информацию для начала анализа.
• Эта команда отобразит STOP-код и символическое имя ошибки.
• Она показывает стек вызовов команд, которые привели к аварийному завершению.
• Кроме того, здесь отображаются неисправности IP-адреса, процессов и регистров.
• Команда может предоставить готовые рекомендации по решению проблемы.

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды!analyze –v (листинг неполный).

1: kd> !analyze -v

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

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Код STOP-ошибки в сокращенном формате:

BUGCHECK_STR: 0x139

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

PROCESS_NAME: sqlservr.exe

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

Участок кода, где возникла ошибка:

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

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Например:

Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.

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’

Once you do the installation, you can find the program in Start Menu -> All Programs -> Debugging Tools for Windows -> Windbg