Анализ bsod windows 7. Как с помощью дампа памяти определить драйвер, вызывающий BSOD. Анализ дампа памяти с помощью BlueScreenView

Здравствуйте друзья, сегодня разберем интересную тему, которая поможет вам в будущем при появлении синего экрана смерти (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:\WINDOWS\Minidump. Тогда просто нажмите кнопку «По умолчанию».

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

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

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

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

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

Чтобы показать скриншот BSoD нажмите клавишу F8.

Для показа всех драйверов и файлов нажимаем F6.

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

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

Или как его еще называют BSOD, может изрядно подпортить жизнь как компьютеру так и серверу, а еще выяснилось и виртуальной машине. Сегодня расскажу как анализировать синий экран dump memory в Windows, так как правильная диагностика и получение причины из за чего не работает ваша система, 99 процентов ее решения, тем более системный инженер, просто обязан уметь это делать, да и еще в кратчайшие сроки, так как от этого бизнес может в следствии простоя сервиса, терять кучу денег.

BSOD расшифровка

Давайте для начала разберем, что означает данная аббревиатура, BSOD от английского Blue Screen of Death или еще режим STOP ошибки.

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

Как настроить создание memory dump

По умолчанию windows при синем экране создает аварийный дамп файл memory.dmp, сейчас покажу как он настраивается и где хранится, я буду показывать на примере Windows Server 2008 R2, так как у меня недавно была задача по изучению вопроса синего экрана в виртуальной машине . Для того чтобы узнать где настроен dump memory windows, открываем пуск и щелкаем правым кликом по значку Компьютер и выбираем свойства.

Как анализировать синий экран dump memory в Windows-Свойства компьютера

Как анализировать синий экран dump memory в Windows-параметры системы

Переходим во вкладку Дополнительно-Загрузка и восстановление. Жмем кнопку Параметры

Как анализировать синий экран dump memory в Windows-Загрузка и восстановление

Где хранится файл memory.dmp

и видим, что во первых стоит галка выполнить автоматическую перезагрузку, для записи отладочной информации, выбрано Дамп памяти ядра и ниже есть пусть куда сохраняется дамп памяти %SystemRoot%\MEMORY.DMP

Перейдем в папку c:\windows\ и найдем файл MEMORY.DMP в нем содержаться коды синего экрана смерти

Как анализировать синий экран dump memory в Windows-memory.dmp

Как настроить mini dump

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

Хранится он в папке c:\windows\minidump. Преимущество в том, что он занимает меньше места и на каждый синий экран создается отдельным файлом. Всегда можно просмотреть историю появлений синего экрана.

Теперь когда мы разобрались где искать файл memory dump, нужно научиться его интерпритировать и понимать причину из за чего происходит синий экран смерти. В решении этой задачи нам поможет Microsoft Kernel Debugger. Скачать Microsoft Kernel Debugger можно с официального сайта, главное выберите нужную версию ОС если кому то влом, то можете скачать с яндекс диска по прямой ссылке. Так же он входит в состав ADK .

Скачиваем Microsoft Kernel Debugger, в итоге у вас будет маленький файл который позволит скачать из интернета все что вам нужно. Запускаем его.

присоединяться к программе по улучшению качества участвовать не будем

жмем Accept и соглашаемся с лицензией

Как установить Microsoft Kernel Debugger-соглашаемся с лицензией

начнется установка Microsoft Kernel Debugger

Как установить Microsoft Kernel Debugger-установка MKD

Видим, что Microsoft Kernel Debugger успешно установлен

После чего видим, что в пуске появилась папка Debugging Tools for Windows как для 32 так и для 64 битных систем.

Помимо самого пакета Debugging Tools for Windows, также понадобятся набор отладочных символов - Debugging Symbols. Набор отладочных символов специфичен для каждой ОС, на которой был зафиксирован BSoD. Потому придется загрузить набор символов для каждой ОС, анализировать работу которой Вам придется. Для 32-разрядной Windows XP потребуются набор символов для Windows XP 32-бит, для 64-разрядной ОС потребуются набор символов для Windows XP 64-бит. Для других ОС семейства Windows наборы символов подбираются сообразно такому же принципу. Загрузить отладочные символы можно отсюда . Устанавливать их рекомендуется по адресу %systemroot%\symbols хотя мне нравится устанавливать их в отдельные папки и не захламлять папку Windows.

Анализ синего экрана в Debugging Tools

После установки Debugging Symbols под систему на которой был синий экран смерти запускаем Debugging Tools

Как установить Microsoft Kernel Debugger-Запуск

Перед анализом содержимого дампа памяти, потребуется провести небольшую настройку отладчика. Конкретно - сообщить программе, по какому пути следует искать отладочные символы. Для этого выбираем в меню File > Symbol File Path…

Нажимаем кнопку Browse…

и указываем папку, в которую мы установили отладочные символы для рассматриваемого дампа памяти, можно указать несколько папок через запятую и можно запрашивать информацию о требуемых отладочных символах прямо через Интернет, с публичного сервера Microsoft. Таким образом у вас будет самая новая версия символов. Сделать это можно следующим образом - в меню File > Symbol File Path… вводим:

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

Как анализировать синий экран смерти

Копируем с компьютера где выскочил синий экран, файл memory.dmp или minidump, и открываем его, выбираем в меню File > Open Crash Dump… и выбираем требуемый для рассмотрения файл.

Как анализировать синий экран смерти-01

Выбираем для примера minidump

Как анализировать синий экран смерти-открываем minidump

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

Как анализировать синий экран смерти-03

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

Как анализировать синий экран смерти-04

Получите более детальную информацию по причине синего экрана.

Как анализировать синий экран смерти-05

Если открыть memory.dmp то вы получите подобную картину и видим почему синий экран у вас появился.

Как анализировать синий экран смерти-06

Вот так вот просто диагностировать и устранить синий экран смерти.

В Windows 8, Microsoft представила новый дамп памяти — опция автоматического дампа памяти. Этот параметр в операционной системе установлен по умолчанию. В Windows 10 ввели новый тип файла дампа — активный дамп памяти. Для тех, кто не знает, в Windows 7 у нас есть малый дамп, дамп ядра и полный дамп памяти. Вы можете удивиться, почему Microsoft решила создать этот новый параметр дамп памяти? По словам Роберта Симпкинса, старшего инженера поддержки, автоматический дамп памяти, может создать поддержку для страницы “системы” в файле конфигурации.
Система управления конфигурацией файла подкачки отвечает за управление размером файла подкачки – это позволяет избежать излишнего запаса или размера файла подкачки. Эта опция введена в основном для ПК, которые работают на SSD-дисках, которые, как правило, имеют меньший размер, но огромное количество оперативной памяти.

Параметры дампа памяти

Главное преимущество “Автоматический дамп памяти” заключается в том, что это позволит сеансу подсистемы в диспетчере процессов автоматически уменьшить файл подкачки до размера, меньшего, чем размер оперативной памяти. Для тех, кто не знает, сессия диспетчера подсистемы отвечает за инициализацию системы, среду запуска служб и процессов, которые необходимы для входа пользователя в систему. Он в основном устанавливает страницу файлов в виртуальную память и запускает процесс winlogon.exe.

Если вы хотите изменить параметры автоматического дампа памяти, вот как это можно сделать. Нажмите клавиши Windows + X и выберите — Система. Далее нажмите на кнопку “Дополнительные параметры системы — Advance System Settings ”.

Нажмите на кнопку Дополнительные параметры системы.

Здесь вы можете увидеть выпадающее меню, где написано “Дополнительно”.

Здесь вы можете выбрать нужный вариант. Предлагаемые варианты:

Никаких дампов памяти.
Малый дамп памяти.
Дамп памяти ядра.
Полный дамп памяти.
Автоматический дамп памяти. Добавлены в Windows 8.
Активный дамп памяти. Добавили в Windows 10.
Расположение файла дампа памяти в файле %SystemRoot%\MEMORY.DMP.

Если вы используете SSD диск, то лучше оставить его на “Автоматический дамп памяти”; но если вы нуждаетесь в файле аварийного дампа, то лучше установить его на “малый дамп памяти”, с ним вы можете, если вы хотите, отправить его кому-то, чтобы он мог взглянуть на него.

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

он называется “LastCrashTime”.

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

В Windows 10 ввели новый файл дампа активный дамп памяти. Он содержит только самое необходимое и, следовательно, он меньшего размера.

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

Вы можете проанализировать дамп памяти Windows.dmp файлов с помощью WhoCrashed. Утилита WhoCrashed Home бесплатная, в ней представлены драйверы, которые были врезаны в ваш компьютер с помощью одного клика. В большинстве случаев она может определить не исправный драйвер, который причиняют страдания вашему компьютеру. Это краш-дамп анализа системы, дампы памяти и здесь представлена вся собранная информация в доступной форме.

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

WhoCrashed полагается на пакет отладки (программы windbg) от Microsoft. Если этот пакет не установлен, WhoCrashed будет сама скачивать и автоматически извлечёт этот пакет для вас. Просто запустите программу и нажмите на кнопку Анализ. Когда у вас есть WhoCrashed установленный в системе и, если он неожиданно сбрасывает или закрывается, программа даст вам знать, если аварийный дамп включен на вашем компьютере, и она будет предлагать Вам предложения о том, как их включить.

В ОС Windows очень часто случаются ошибки, даже в случае с «чистой» системой. Если обычные ошибки программ решить можно (появляется сообщение о недостающем компоненте), то исправить критические ошибки будет намного сложнее.

Что такое дамп памяти в Windows

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

Существует несколько видов дампов памяти:

Малый дамп (Small Memory Dump) – сохраняет минимальный объем ОЗУ, где находятся сведения по критическим ошибкам (BSoD) и компонентах, которые были загружены во время работы системы, например, драйвера, программы. MiniDump хранится по пути C:\Windows\Minidump.

Полный дамп (Complete Memory Dump) – сохраняется полный объем ОЗУ. Это значит, что размер файла будет равен объему оперативной памяти. Если места на диске мало, будет проблематично сохранить, например, 32 Гб. Также бывают проблемы с созданием файла дампа памяти более 4 Гб. Данный вид используется очень редко. Храниться по пути C:\Windows\MEMORY.DMP.

Дамп памяти ядра – сохраняется только информация, относящаяся к ядру системы.

Когда пользователь дойдет до анализа ошибки, ему достаточно использовать только minidamp (малый дамп). Но перед этим он обязательно должен быть включен, иначе распознать проблему не удастся. Также для более эффективного выявления аварии использование полного снимка памяти предпочтительней.

Информация в реестре

Если заглянуть в реестр Windows, то можно обнаружить некоторые полезные параметры снимков. Щелкаем сочетание клавиш Win+R, вводим команду regedit и открываем следующие ветки:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

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

• AutoReboot – активация или отключение перезагрузки после создания синего экрана смерти (BSoD).
• DumpFile – название видов дампов и расположение.
• CrashDumpEnabled – номер создаваемого файла, например, число 0 – дамп не создается; 1 – создание полного дампа; 2 – создание дампа ядра; 3 – создание малого дампа.
• DumpFilters – параметр позволяет добавить новые функции перед созданием снимка. Например, шифрование файла.
• MinidumpDir – название малого дампа и его расположение.
• LogEvent – активация записи сведений в системный журнал.
• MinidumpsCount – задать количество создаваемых малых дампов. (Превышение этого количества будет уничтожать старые файлы и заменять их).
• Overwrite – функция для полного дампа или системного. При создании нового снимка, предыдущий будет всегда заменяться на новый.
• DedicatedDumpFile – создание альтернативного файла снимка и указание его пути.
• IgnorePagefileSize – используется для временного расположения снимка, без использования файла подкачки.

Как это работает

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

Обычно файл сохраняется в выделенном для файла подкачки блоке жёсткого диска, после появления BSoD файл перезаписывается в тот вид, который пользователь сам и настроил (Малый, полный или дамп ядра). Хотя, в современных ОС участие файла подкачки не обязательно.

Как включить дампы

В Windows 7 :

В Windows 8 и 10 :

Здесь процесс немного похож, в сведения о системе можно попасть точно также, как в Windows 7. В «Десятке» обязательно открываем «Этот компьютер », нажимаем по свободному месту правой кнопочкой мышки и выбираем «Свойства ». По-другому туда можно попасть через Панель управления.

Второй вариант для Wi ndows 10 :

Следует заметить, что в новых версиях Windows 10 появились новые пункты, которых не было в «семерке»:

• Малый дамп памяти 256 КБ – минимальные данные о сбое.
• Активный дамп – появился в десятой версии системы и сохраняет только активную память компьютера, ядра системы и пользователя. Рекомендуется использовать на серверах.

Как удалить дамп

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

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

Даже если вы когда-то включали их, некоторые используемые утилиты по оптимизации системы могут легко отключить некоторый функционал . Часто много чего отключается при использовании SSD накопителей, так как многократные процедуры чтения и записи сильно вредят здоровью данного диска.

Анализ дампа памяти при помощи WinDbg

Скачиваем с официального сайта Microsoft данную программу на шаге 2, где описана «Установка WDK » — https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk .

Чтобы работать с программой еще понадобиться специальный пакет отладочных символов. Он называется Debugging Symbols , раньше его можно было скачать с сайта Microsoft, но теперь они отказались от этой идеи и придется использовать функцию программы File — «Symbol File Path », куда следует вписать следующую строчку и нажать ОК:

set _NT_SYMBOL_PATH=srv*DownstreamStore*https://msdl.microsoft.com/download/symbols

Если не сработало, пробуем вот эту команду:

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

Снова нажимаем пункт «File» и выбираем опцию «Save Workspace».

Утилита настроена. Остается указать путь до файлов дампов памяти. Для этого нажимаем File и щелкаем опцию «O pen Crash Dump ». Расположение всех дампов указано в начале статьи.

После выбора закончится анализ и проблемный компонент автоматически будет выделен. Для получения большего количества информации в этом же окошке можно ввести такую команду: !analyze –v

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

Загрузить инструмент бесплатно можно с этого сайта — http://www.nirsoft.net/utils/blue_screen_view.html . Установка не требует каких-то навыков. Используется только в Windows 7 и выше.

Запускаем и настраиваем. Нажмите «Настройки» (Options) – «Дополнительные параметры » (Advanced Options). Выберите первый пункт «Загружать МиниДампы из этой папки » и указываем каталог — C:\WINDOWS\Minidump . Хотя можно просто нажать кнопку «По умолчанию». Нажимаем ОК.

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

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

Теперь нажимаем «Файл» и выбираем, например, пункт «Найти в Go ogle код ошибки + драйвер ». Если нашли нужный драйвер, установите и перезагрузите компьютер. Возможно ошибка исчезнет.

Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство - это скрипт автоматизации отладчика ядра под названием kdfe . Kdfe расшифровывается как Kernel Debugger Front End , то есть интерфейс или надстройка для взаимодействия пользователя с ядерным отладчиком kd.exe (Kernel Debugger) на достаточно простом и понятном уровне. Фактически, kdfe представляет собой скрипт, автоматизирующий определенные действия пользователя и позволяющий в достаточно сжатый промежуток времени получить анализ аварийного дампа памяти системы, либо полностью автоматизировать действия по получению результата анализа и использовать их в более развитых и глобальных автоматизированных системах (правда в этом случае скрипт придется слегка доработать). В стандартном режиме kdfe перенаправляет вывод отладчика ядра kd.exe , что позволяет использовать только необходимые выходные данные отладчика. Понятное дело что kdfe не является панацеей, в его отсутствии нам просто пришлось бы анализировать аварийный дамп памяти системы вручную, непосредственно в консоли при помощи отладчика ядра kd с определенными входными параметрами, что, согласитесь, менее удобно и более времязатратно. Автор скрипта, Александр Суховей (Alexander Suhovey), несомненно создал хороший инструментарий, за что хотелось бы сказать ему отдельное спасибо и за весомый вклад в науку отладки и сэкономленное время.

Подготовка к анализу

Как было уже сказано ранее, скрипт kdfe требует наличия в системе отладчика ядра kd.exe , входящего в состав комплекта Debugging Tools for Windows. Из этого следует, что нам требуется сперва .
На следующем этапе нам необходимо получить в свое распоряжение сам скрипт kdfe. В сети мне удалось найти сайт, носящий название abandoned blog , который оказался домашней страницей автора. Могу предположить, что сайт давно не обновляется, поэтому я решил, на всякий случай, продублировать скрипт и на своем ресурсе.

Исходный код скрипта приводить не вижу особого смысла, во избежание разночтений. После того, как вы скачали скрипт на свою машину, его можно распаковать (как вариант) во временную папку (системная переменная %TEMP%), лично у меня она ссылается, по старой-доброй традиции, на C:\TEMP .

Настройка пути к средствам отладки

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

. . . ::Kernel debugger path. Default is: ::For version 6.8.4.0 - October 18, 2007 and older IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows\kd.exe" (set dbgpath="%PROGRAMFILES%\Debugging Tools for Windows") ELSE (rem For version 6.9.3.113 - April 29, 2008 and newer rem 32 bit IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows (x86)\kd.exe" (set dbgpath="%PROGRAMFILES%\Debugging Tools for Windows (x86)") ELSE (rem 64 bit IF EXIST "%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)\kd.exe" (set dbgpath="%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)") ELSE (IF EXIST "%PROGRAMW6432%\Debugging Tools for Windows (x64)\kd.exe" (set dbgpath="%PROGRAMW6432%\Debugging Tools for Windows (x64)") ELSE (echo ERROR: Debugging Tools for Windows not found^^! pause exit /b 1)))) :: Or set the path to Debugging Tools below:: set dbgpath="" . . .

. . . :: Kernel debugger path . Default is : IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows\kd.exe" ( Set dbgpath = "%PROGRAMFILES%\Debugging Tools for Windows" ) ELSE ( Rem 32 bit IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows (x86)\kd.exe" ( Set dbgpath = "%PROGRAMFILES%\Debugging Tools for Windows (x86)" ) ELSE ( Rem 64 bit IF EXIST "%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)\kd.exe" ( Set dbgpath = "%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)" ) ELSE ( IF EXIST "%PROGRAMW6432%\Debugging Tools for Windows (x64)\kd.exe" ( Set dbgpath = "%PROGRAMW6432%\Debugging Tools for Windows (x64)" ) ELSE ( Echo ERROR : Debugging Tools for Windows not found ^ ^ ! Pause Exit / b 1 :: Or set the path to Debugging Tools below :: set dbgpath = "" . . .

Скрипт писался давно, и попросту "не знал" о существовании новых путей установки средств отладки Microsoft. С определенной версии путь установки изменился на:

• %PROGRAMFILES(X86)%\Windows Kits\10\Debuggers\x86 ;
• %PROGRAMFILES(X86)%\Windows Kits\10\Debuggers\x64 ;

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

Настройка символов

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

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

У нас есть два варианта решения данной проблемы:

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

Вам необходимы символы для той системы, которая создала дамп памяти, но не для той системы, на который Вы этот дамп анализируете!

Скрипт kdfe написан таким образом, чтобы указывать отладчику kd скачивать с сервера символов Microsoft только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. Задается это в скрипте при помощи переменной smbpath , которая указывает каталог, в который kd.exe будет сохранять необходимые файлы. По-умолчанию это %SYSTEMDRIVE%\symbols , соответственно, в большинстве случаев это C:\symbols . Надо ли вручную создавать эту директорию, либо kd создаст её сам?

Запуск скрипта

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

kdfe

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

kdfe d:\junk\memory.dmp

Непосредственно после запуска скрипт kdfe определяет рабочую директорию средств отладки (Debugging Tools for Windows). Среди возможных вариантов перебираются все возможные пути установки средств отладки. Необходимо это для того, чтобы адресно запускать отладчик ядра kd.exe с указанием полного пути до исполняемого файла.

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

Если скрипт kdfe без параметров командной строки, то он анализирует параметры ветки реестра HKLM\SYSTEM\CurrentControlSet\Control\CrashControl и использует сконфигурированные в параметрах DumpFile и MinidumpDir места расположения дампов в системе. После этого сканирует директории и выводит все обнаруженные файлы дампов в виде меню выбора, предлагая пользователю указать требуемый файл дампа для анализа:

Соответственно, после того, как пользователь выбирает дамп для анализа, скрипт kdfe запускает отладчик kd.exe с определенными параметрами командной строки, дожидается результатов, фильтрует вывод отладчика и перенаправляет его на консоль.

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

Анализ результатов

Теперь пришло время проанализировать вывод, предоставленный нам скриптом kdfe.

Прежде всего, нас интересует главный и самый важный параметр, который выводится после строки probably caused by . В нем обозначается источник проблемы, то есть причина синего экрана смерти . По выводу мы можем понять, что в данном конкретном случае присутствует исключительно аппаратная проблема (ключевое слово hardware). Забегая вперед скажу, что виновником оказался процессор. Да, да, да, сам был чрезвычайно удивлен, потому как столкнулся с подобным впервые, но после долгой диагностики всего железа с последующей заменой частей, последним вариантом оказался именно процессор. Итогом всего этого стала замена процессора, и вот только после этого синие экраны прекратились.
Однако, по статистике, в большинстве случаев виновниками синих экранов являются драйвера устройств сторонних производителей, в подобном случае в строке probably caused by мы можем увидеть нечто вроде igxpdv32.dll . После чего необходимо понять, что именно это за драйвер и скачать+установить более новую (либо более старую) стабильную версию.
Довольно часто рекомендуется обращать внимание так же и на строку Process name , поскольку проблема бывает многосоставная и в этом параметре указывается контекст процесса, то есть (вероятный) виновник более общего, высокого уровня. Например, исполняемый.exe-файл какой-либо программы, библиотека.dll, и зачастую проблема может быть связана с указанной программой, а не с драйвером/компонентом. Дополнительно, имейте эту информацию в виду, и если проблема не устранилась непосредственной работой с источником, указанным в строке probably caused by .