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

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

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

Интерфейс WinDBG

Когда вы откроете файл дампа памяти, то увидите такое окно:

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

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

После того как символы будут загружены и отладчик будет готов к анализу файла дампа вы увидите сообщение Followup: MachineOwner в нижней части текстового окна.

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

Анализ дампа памяти

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

Коды ошибок всегда указываются в шестнадцатеричном значении и имеют вид 0xXXXXXXXX . Указываются же коды ошибок одним из следующих вариантов:

• STOP: 0x0000009F
• 03.06.2015 0009F

Справочник по кодам ошибок: Windows Dev Center Bug Check Code Reference

Команда!thread и анализ драйверов

Самая распространенная причина возникновения BSOD - это сторонние драйверы (производителей устройств). Для того, чтобы увидеть фигурирует ли драйвер устройства в дампе нам понадобится просмотреть стек.
Выполните команду ! thread и найдите в результатах ее выполнения Base и Limit , и их шестнадцатеричные значения.
В рассматриваемом примере они такие:
Base fffff80000b9b000 Limit fffff80000b95000

В командной строке напечатайте dps затем через пробел шестнацатеричное значение Limit , а за ним значение Base . В данном случае важен порядок указания значений - он должен быть обратным отображаемому в результате выполнения команды!thread.

dps fffff80000b95000 fffff80000b9b000

Когда стек будет загружен вы увидите множество строк с текстом и значениями. Среди результатов выполнения команды поищите сообщения об ошибках с указанием на драйверы. В рассматриваемом примере это драйвер igdkmd64.sys и iaStorA.sys а в отладчике это выглядит так:

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

driverquery /v > "%USERPROFILE%\Desktop\drivers.txt"

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

В рассматриваемом примере вероятными виновниками возникновения BSOD оказались драйверы видеокарты Intel (igdkmd64.sys) и SATA/AHCI-контроллера (iaStorA.sys).

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

Команда!analyze -v

Команда!analyze отображает информацию о текущем исключении или код ошибки, а параметр -v формирует подробный вывод данных. В рассматриваемом случае нам понадобятся данные о заблокированных IRP пакетах в значении Arg4 , и значения FAILURE_ BUCKET_ ID и BUCKET_ ID .

Выполните команду !irp добавив значение из Arg4

!irp ffffe001eb781600

В результате выполнения команды был определен проблемный драйвер - Rt630x64.sys

В данном случае драйвер Rt630x64.sys относится к сетевому адаптеру и вызывает ошибку DRIVER_POWER_STATE_FAILURE при завершении работы системы.
Для получения подробных сведений о файле драйвера выполните команду

Как видите дата драйвера довольно старая и стоит его обновить для устранения проблемы.

Заключение

Цель этой статьи рассказать об алгоритме анализа дампа памяти для выявления причины BSOD. В рамках одной статьи невозможно рассмотреть все варианты анализа, а многие тонкости приходят только с опытом. Был рассмотрен всего один код ошибки т.к. последовательность ее анализа показалась мне наиболее интересной, в отличие от ошибки 0x124, например, которая в подавляющем большинстве случаев говорит об аппаратной неполадке, или 0x116, свидетельствующей о проблеме с драйвером видео или неполадке видеокарты в 95% случаев.

Если у вас не получилось выяснить причину BSOD или попросту нужна быстрая и квалифицированная помощь в анализе проблемы, вы всегда можете обратиться в форум

Синий экран смерти (англ. Blue Screen of Death, Blue Screen of Doom, BSoD )- сообщения о критической системной ошибке в операционных системах Microsoft Windows. Многие кто сталкиваются на своем компьютере/ ноутбуке с синим экраном смерти, единственным решением видят переустановку операционной системы. Но иногда ОС здесь вовсе не причем, а проблема в "железе". Для того что бы не гадать- почему появился синий экран смерти, нужно использовать информацию, которую предоставляет сама операционная система в виде логов. В этой статье я пошагово опишу как выяснить причину появления синего экрана смерти.

Итак, появление синего экрана смерти всегда неожиданно и не вовремя, поэтому успеть увидеть что написано многие просто не успевают, а там надо сказать написано (правда не в совсем явном виде) причины сбоя. Первым делом я предлагаю настроить компьютер/ ноутбук, что бы он не перезагружался сразу после сбоя системы, а дал возможность увидеть причину сбоя, если этой информации будет недостаточно необходимо посмотреть dump файл в котором содержится информация: код ошибки с параметрами, список драйверов загруженных в оперативную память на момент краха системы и т.д., но этих сведений достаточно, для определения сбойного драйвера.

Настройки касаемые перезагрузки после сбоя системы можно указать, если нажать правой кнопкой мыши на ярлыке Мой компьютер/ Компьютер (подходит для Windows XP, Windows7, Windows8), выбрать "Свойства ", или нажать сочетание клавиш + . Все принтскирны ниже будут касаться Windows7, аналогичным способ настраивается на Windows XP, Windows8, Windows8.1.

На вкладке "Дополнительно " выберите в поле Загрузка и восстановление "Параметры ".

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

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

Если указанной там информации мало, можно воспользоваться дампом (dmp файл ). Для этого можно использовать инструмент microsoft- microsoft debugging tool, но он много весит, требует установки и наличия framework 4.5. Можно обойтись меньшими жертвами, если использовать программу BlueScreenView . На мой взгляд очень удобная программа не требующая установки и на русском языке (файл добавить в папку с программой). Запустив файл BlueScreenView.exe вам откроется интерфейс программы в котором уже будет загружен dump этого компьютера (используется путь по умолчанию C:\Windows\MiniDump, если зайти в Настройки- Дополнительные параметры можно указать другой путь, если вы скопировали dump в другое место).

Одним из наиболее часто встречающихся отказов работы Windows — системные исключения, которые пользователь видит в виде «синего экрана смерти» (BSOD). Как правило, эта фатальная ошибка возникает или из-за неисправности драйверов, оборудования (чаще при загрузке ОС) или из-за действия вирусов и антивирусов.

На синем экране смерти содержится информация о причинах, вызвавших исключение (в виде кода STOP-ошибки вида 0x0000007b), адреса в памяти, при обращении к которым произошло исключение и прочая полезная информация. Такая информация называется STOP-ошибкой, переменными параметрами которой как раз являются адреса памяти. Иногда там же содержится имя файла, вызвавшего исключение.

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

Что такое дамп

• dump (англ.) – мусорная куча; свалка; дыра; трущоба.
• dump (memory dump) – 1) дамп, вывод содержимого оперативной памяти на печать или экран; 2) «снимок» оперативной памяти; данные, получаемые в результате дампинга; 3) аварийное снятие, выключение, сброс.
• dumping – дампинг, снятие дампа.

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

Информация о дампе памяти в системном Реестре:

В разделе Реестра Windows аварийный дамп памяти определяется следующими параметрами:

– REG_DWORD-параметр AutoReboot со значением 0×1 (опция Выполнить автоматическую перезагрузку вспомогательного окна Загрузка и восстановление диалогового окна Свойства системы);

– REG_DWORD-параметр CrashDumpEnabled со значением 0×0, если дамп памяти не создается; 0×1 – Полный дамп памяти; 0×2 – Дамп памяти ядра; 0×3 – Малый дамп памяти (64КБ);

– REG_EXPAND_SZ-параметр DumpFile со значением по умолчанию %SystemRoot%\MEMORY.DMP (место хранения файла дампа);

– REG_DWORD-параметр LogEvent со значением по умолчанию 0×1 (опция Записать событие в системный журнал окна Загрузка и восстановление);

– REG_EXPAND_SZ-параметр MinidumpDir со значением по умолчанию %SystemRoot%\Minidump (опция Папка малого дампа окна Загрузка и восстановление);

– REG_DWORD-параметр Overwrite со значением по умолчанию 0×1 (опция Заменять существующий файл дампа окна Загрузка и восстановление);

– REG_DWORD-параметр SendAlert со значением по умолчанию 0×1 (опция Отправить административное оповещение окна Загрузка и восстановление).

Как система создает файл аварийного дампа памяти

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

После сбоя ядро системы проверяет целостность карты страничного файла, дискового драйвера и управляющих структур дискового драйвера. Если целостность этих структур не нарушена, то ядро системы вызывает специальные функции ввода/вывода дискового драйвера, предназначенные для сохранения образа памяти после системного сбоя. Эти функции ввода/вывода самодостаточны и не полагаются на службы ядра системы, поскольку в программах, отвечающих за запись аварийного дампа, нельзя делать никаких предположений о том, какие части ядра системы или драйверы устройств при сбое были повреждены. Ядро системы записывает данные из памяти по карте секторов файла подкачки (при этом ему не приходится использовать драйверы файловой системы).

Сначала ядро системы проверяет состояние каждого компонента, задействованного в процессе сохранения дампа. Это делается для того, чтобы при прямой записи в секторы диска не повредить данные, лежащие вне страничного файла. Размер страничного файла должен быть на 1МБ больше размера физической памяти, потому что при записи информации в дамп создается заголовок, в котором содержатся сигнатура аварийного дампа и значения нескольких важнейших переменных ядра системы. Заголовок занимает меньше 1МБ, но операционная система может увеличивать (или уменьшать) размер файла подкачки не менее чем на 1МБ.

После загрузки системы Session Manager (Диспетчер сеанса Windows NT; дисковый адрес – \WINDOWS\system32\smss.exe) инициализирует страничные файлы системы, используя для создания каждого файла собственную функцию NtCreatePagingFile. NtCreatePagingFile определяет, существует ли инициализируемый страничный файл, и если да, то имеется ли в нем заголовок дампа. Если заголовок есть, то NtCreatePagingFile посылает в Session Manager специальный код. После этого Session Manager запускает процесс Winlogon (Программа входа в систему Windows NT; дисковый адрес – \WINDOWS\system32\winlogon.exe), который извещается о существовании аварийного дампа. Winlogon запускает программу SaveDump (Программа сохранения копии памяти Windows NT; дисковый адрес – \WINDOWS\system32\savedump.exe), которая анализирует заголовок дампа и определяет дальнейшие действия в аварийной ситуации.

Если заголовок указывает на существование дампа, то SaveDump копирует данные из страничного файла в файл аварийного дампа, имя которого задано REG_EXPAND_SZ-параметром DumpFile раздела Реестра . Пока SaveDump переписывает файл дампа, операционная система не задействует ту часть страничного файла, в которой содержится аварийный дамп. В это время объем виртуальной памяти, доступной для системы и приложений, уменьшается на размер дампа (при этом на экране могут появиться сообщения, указывающие на нехватку виртуальной памяти). Затем SaveDump информирует диспетчер памяти о завершении сохранения дампа, и тот высвобождает ту часть страничного файла, в которой хранится дамп, для общего пользования.

Сохранив файл дампа, программа SaveDump делает запись о создании аварийного дампа в журнале событий Система, например: «Компьютер был перезагружен после критической ошибки: 0x100000d1 (0xc84d90a6, 0×00000010, 0×00000000, 0xc84d90a6). Копия памяти сохранена: C:\WINDOWS\Minidump\Mini060309-01.dmp».

Если включена опция Отправить административное оповещение, то SaveDump отправляет оповещение администратору.

Разновидности дампов

• Полный дамп памяти записывает всё содержимое системной памяти при возникновении неустранимой ошибки. Для этого варианта необходимо иметь на загрузочном томе файл подкачки, размер которого равен объему всей физической оперативной памяти плюс 1МБ. По умолчанию полный дамп памяти записывается в файл %SystemRoot%\Memory.dmp. При возникновении новой ошибки и создании нового файла полного дампа памяти (или дампа памяти ядра) предыдущий файл заменяется (перезаписывается). Параметр Полный дамп памяти недоступен на ПК, на которых установлена 32-битная операционная система и 2 или более гигабайта оперативной памяти.

При возникновении новой ошибки и создании нового файла полного дампа памяти предыдущий файл заменяется.

• Дамп памяти ядра записывает только память ядра, благодаря чему процесс записи данных в журнал при внезапной остановке системы протекает быстрее. В зависимости от объема физической памяти ПК в этом случае для файла подкачки требуется от 50 до 800МБ или одна треть физической памяти компьютера на загрузочном томе. По умолчанию дамп памяти ядра записывается в файл %SystemRoot%\Memory.dmp.

Этот дамп не включает нераспределенную память или память, выделенную для программ пользовательского режима. Он включает только память, выделенную для ядра и аппаратно-зависимого уровня (HAL) в Windows 2000 и более поздних версиях системы, а также память, выделенную для драйверов режима ядра и других программ режима ядра. В большинстве случаев такой дамп является наиболее предпочтительным вариантом. Он занимает намного меньше места по сравнению с полным дампом памяти, при этом исключая только те сектора памяти, которые, скорее всего, не связаны с ошибкой.
При возникновении новой ошибки и создании нового файла дампа памяти ядра предыдущий файл заменяется.

• Малый дамп памяти записывает наименьший объем полезной информации, необходимых для определения причины неполадок. Для создания малого дампа памяти необходимо, чтобы размер файла подкачки составлял как минимум 2МБ на загрузочном томе.

Файлы малого дампа памяти содержат следующие сведения:

• сообщение о неустранимой ошибке, ее параметры и прочие данные;
• список загруженных драйверов;
• контекст процессора (PRCB), на котором произошел сбой;
• сведения о процессе и контекст ядра (EPROCESS) для процесса, вызвавшего ошибку;
• сведения о процессе и контекст ядра (ETHREAD) для потока, вызвавшего ошибку;
• стек вызовов в режиме ядра для потока, вызвавшего ошибку.

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

При возникновении следующей ошибки и создании второго файла малого дампа памяти предыдущий файл сохраняется. Каждому дополнительному файлу дается уникальное имя. Дата закодирована в имени файла. Например, Mini051509-01.dmp - это первый файл дампа памяти, созданный 15 мая 2009 г. Список всех файлов малого дампа памяти хранится в папке %SystemRoot%\Minidump .

Операционная система Windows XP, несомненно, значительно надежнее предыдущих версий, – благодаря усилиям как разработчиков Microsoft, так и разработчиков драйверов аппаратного обеспечения, так и разработчиков прикладного программного обеспечения. Однако аварийные ситуации – всевозможные сбои и крахи системы – неизбежны, и от того, владеет ли пользователь ПК знаниями и навыками в их устранении, зависит, придется ему затратить несколько минут на поиск и устранение неисправности (например, на обновление/отладку драйвера или переустановку прикладной программы, вызывающей системный сбой), – или несколько часов на переустановку/настройку операционной системы и прикладного программного обеспечения (что не гарантирует отсутствия сбоев и крахов в дальнейшем!).

Многие системные администраторы всё еще пренебрегают анализом аварийных дампов Windows, считая, что работать с ними слишком трудно. Трудно, но можно: даже если, например, анализ одного дампа из десяти окажется успешным, – усилия, потраченные на освоение простейших приемов анализа аварийных дампов, будут не напрасны!..

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

В локальной сети без видимой причины («железо» в порядке, отсутствие вирусов гарантировано, пользователи – с «нормальными руками») «полегли» несколько рабочих станций с Windows XP SP1/SP2 «на борту». Компьютеры загрузить в нормальном режиме не удавалось, – доходило до «Приветствия» – и на перезагрузку до бесконечности. При этом, в Безопасном режиме ПК загружались.

Изучение дампов памяти позволило выявить причину неисправности: виновником оказался антивирус Касперского , точнее, свежие антивирусные базы (если еще точнее, то два модуля баз – base372c.avc, base032c.avc).

…Еще был такой случай. На локальном ПК с Windows XP SP3 при попытке открыть видеофайлы форматов.avi и.mpeg происходила перезагрузка. Изучение дампа памяти позволило выявить причину неисправности – файл nv4_disp.dll драйвера видеокарты NVIDIA GeForce 6600. После обновления драйвера неисправность была устранена. Вообще, драйвер nv4_disp.dll — один из самых нестабильных драйверов, который часто приводил к BSOD.

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

Анализ дампа памяти

Для анализа аварийных дампов памяти существует множество программ, например, DumpChk, Kanalyze, WinDbg.

Рассмотрим анализ аварийных дампов памяти с помощью программы WinDbg (входит в состав Debugging Tools for Windows).

Установка средств отладки

• посетите веб-узел http://www.microsoft.com/whdc/devtools/debugging/default.mspx корпорации Microsoft;
• загрузите Debugging Tools for Windows, например, для 32-битной версии Windows это можно сделать на странице Download the Debugging Tools for Windows ;
• после скачивания запустите установочный файл;
• в окне Debugging Tools for Windows Setup Wizard нажмите Next;
• в окне с лицензионным соглашением установите переключатель I agree –> Next;
• в следующем окне выберите тип установки (по умолчанию средства отладки устанавливаются в папку \Program Files\Debugging Tools for Windows) –> Next –> Install –> Finish;
• для интерпретации файлов дампа памяти необходимо также загрузить пакет символов (Symbol Packages, так называемые символьные файлы, или файлы символов отладки) для своей версии Windows, – зайдите на страницу Download Windows Symbol Packages ;
• выберите свою версию Windows, скачайте и запустите установочный файл Symbol Packages;
• в окне с лицензионным соглашением нажмите Yes;
• в следующем окне выберите папку для установки (по умолчанию предлагается \WINDOWS\Symbols) –> OK –> Да;
• в окне Microsoft Windows Symbols с сообщением «Installation is complete» нажмите OK.

Использование программы WinDbg для анализа аварийных дампов памяти

• запустите WinDbg (по умолчанию устанавливается в папку \Program Files\Debugging Tools for Windows);
• выберите меню File –> Symbol File Path…;
• в окне Symbol Search Path нажмите кнопку Browse…;
• в окне Обзор папок укажите расположение папки Symbols (по умолчанию – \WINDOWS\Symbols) –> OK –> OK;
• выберите меню File –> Open Crash Dump… (или нажмите Ctrl + D);
• в окне Open Crash Dump укажите расположение Crash Dump File (*.dmp) –> Открыть;
• в окне Workspace с вопросом «Save information for workspace?», установите флажок Don"t ask again –> No;
• в окне WinDbg откроется окно Command Dump <путь_и_имя_файла_дампа> с анализом дампа;
• просмотрите анализ дампа памяти;
• в разделе «Bugcheck Analysis» будет указана возможная причина краха, например, «Probably caused by: smwdm.sys (smwdm+454d5)»;
• для просмотра детальной информации нажмите ссылку «!analyze -v» в строке «Use !analyze -v to get detailed debugging information»;
• закройте WinDbg;
• используйте полученную информацию для устранения причины неисправности.

Например, на следующем скриншоте причина неисправности – файл nv4_disp.dll драйвера видеокарты.

Все Windows-системы при обнаружении фатальной ошибки делают аварийный дамп (снимок) содержимого оперативной памяти и сохраняет его на жесткий диск. Существуют три типа дампа памяти:

Полный дамп памяти – сохраняет все содержимое оперативной памяти. Размер снимка равен размеру оперативной памяти + 1 Мб (заголовок). Используется очень редко, так как в системах с большим объемом памяти размер дампа будет слишком большим.

Дамп памяти ядра – сохраняет информацию оперативной памяти, касающуюся только режима ядра. Информация пользовательского режима не сохраняется, так как не несет в себе информации о причине краха системы. Объем файла дампа зависит от размера оперативной памяти и варьируется от 50 Мб (для систем с 128 Мб оперативной памяти) до 800 Мб (для систем с 8 Гб оперативной памяти).

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

Настройка системы

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

Проделав все манипуляции, после каждого BSoD в папке C:\WINDOWS\Minidump будет сохраняться файл с расширение.dmp. Советую ознакомиться с материалом " ". Также можно установить галочку на “Заменить существующий файл дампа ”. В этом случае каждый новый аварийный дамп будет записываться поверх старого. Я не советую включать данную опцию.

Анализ аварийного дампа памяти с помощью программы BlueScreenView

Итак, после появления синего экрана смерти система сохранила новый аварийный дамп памяти. Для анализа дампа рекомендую использовать программу BlueScreenView. Её можно бесплатно скачать . Программа довольно удобная и имеет интуитивный интерфейс. После её установки первое, что необходимо сделать – это указать место хранение дампов памяти в системе. Для этого необходимо зайти в пункт меню “Options ” и выбрать “Advanced Options ”. Выбираем радиокнопку “Load from the following Mini Dump folder ” и указываем папку, в которой хранятся дампы. Если файлы хранятся в папке C:\WINDOWS\Minidump можно нажатием кнопки “Default ”. Нажимаем OK и попадаем в интерфейс программы.

Программа состоит из трех основных блоков:

1. Блок главного меню и панель управления;
2. Блок списка аварийных дампов памяти;
3. В зависимости от выбранных параметров может содержать в себе:

• список всех драйверов находящихся в оперативной памяти до появления синего экрана (по умолчанию);
• список драйверов находящихся в стеке оперативной памяти;
• скриншот BSoD;
• и другие значения, которые мы использовать не будем.

В блоке списка дамп памяти (на рисунке помечен цифрой 2) выбираем интересующий нас дамп и смотрим на список драйверов, которые были загружены в оперативную память (на рисунке помечен цифрой 3). Розовым цветом окрашены драйвера, которые находились в стеке памяти. Они то и являются причиной появления BSoD. Далее переходите в Главное меню драйвера, определяйте к какому устройству или программе они принадлежат. В первую очередь обращайте внимание на не системные файлы, ведь системные файлы в любом случае загружены в оперативной памяти. Легко понять, что на изображении сбойным драйвером является myfault.sys. Скажу, что это программа была специально запущена для вызова Stop ошибки. После определения сбойного драйвера, необходимо его либо обновить, либо удалить из системы.

Для того чтобы программа показывала список драйверов находящихся в стеке памяти во время возникновения BSoD необходимо зайти в пункт меню “Options ” кликаем на меню “Lower Pane Mode ” и выбираем “Only Drivers Found In Stack ” (или нажмите клавишу F7), а для показа скриншота ошибки выбираем “Blue Screen in XP Style ” (F8). Что бы вернуться к списку всех драйверов, необходимо выбрать пункт “All Drivers ” (F6).