Как понять в чем проблема при появлении синего экрана (BSOD) или чем открыть файл dump. Как с помощью дампа памяти определить драйвер, вызывающий BSOD Где находится дамп памяти windows 7

Отказ системы из-за критической ошибки (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, BSoD) — это поиск неисправности по номеру STOP-ошибки. Обычно такой подход может помочь выбрать общее направление решения проблемы, но не всегда позволяет ее локализовать. Например, определить какой конкретный драйвер устройства вызывает BSoD. Строго говоря, анализ дампов памяти — это основной метод борьбы с STOP-ошибками.

При возникновении STOP-ошибки Microsoft Windows может записать отладочную информацию. Для этого необходимо выполнить следующие действия:

1. Нажмите кнопку Пуск и выберите в меню Настройка пункт Панель управления
2. Дважды щелкните по значку Система
3. Откройте вкладку Дополнительно и нажмите кнопку
4. В области Запись отладочной информации выберите пункт Малый дамп памяти (64 КБ)

В файле малого дампа памяти записывается минимальная информация, позволяющая установить причину сбоя компьютера. Для этого на загрузочном томе требуется файл подкачки размером не менее 2 МБ. По умолчанию файлы малого дампа памяти хранятся в папке %SystemRoot%\Minidump.

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

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

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

Для анализа дампов памяти используются утилиты kd.exe и windbg.exe . Эти утилиты входят в набор Debugging Tools for Windows . Для того чтобы упростить работу с ними, рекомендую использовать скрипт (автор Alexander Suhovey). Вам так же понадобится утилита reg.exe (включена в Microsoft Windows XP и выше; для Windows 2000 входит в состав Windows 2000 Support Tools).

Скачайте и распакуйте архив со скриптом в папку D:\KDFE . Для работы отладчику требуются символьные файлы, которые можно скачать там же, где и Debugging Tools for Windows. Полный размер пакета с этими файлами довольно внушителен (может составить более 1Гб в зависимости от выбранной платформы). Поэтому скрипт настроен таким образом, чтобы автоматически скачивать с Microsoft Symbol Server только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. При необходимости можно отредактировать скрипт и изменить переменную smbpath , которая указывает на папку, в которую kd.exe будет сохранять необходимые файлы.

Для использования выполните kdfe.cmd с именем файла дампа памяти в качестве параметра. Например:

D:\KDFE>kdfe mini111208-01.dmp

Analyzing "D:\KDFE\Mini111208-01.dmp", please wait... Done.

Crash date: Wed Nov 12 08:35:56.214 2008 (GMT+2)
Stop error code: 0x50
Process name: AUM.exe
Probably caused by: nv4_disp.dll (nv4_disp+41213)

Надо отметить, что бывают ситуации, когда из-за некорректной работы одного из драйверов, STOP-ошибка впоследствии возникает в совершенно нормальном драйвере. В этом случае рекомендую использовать утилиту verifier.exe (см.

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

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

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

В 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 установленный в системе и, если он неожиданно сбрасывает или закрывается, программа даст вам знать, если аварийный дамп включен на вашем компьютере, и она будет предлагать Вам предложения о том, как их включить.

Файл дампа памяти сохраняется при возникновении ошибок СТОП (или Голубых экранов смерти, BSOD) . Посмотрим как настраивается сохранение дампа памяти в Windows 7.

Нажимаем правой кнопкой мыши значек Компьютер (Computer) в контекстном меню выбираем Свойства (Properties) .

В левой колонке выбираем Дополнительные параметры системы (Advanced system settings) .

В окне Системные параметры (System Properties) выбираем вкладку Дополнительно (Advanced) , в секции Загрузка и Восстановление (Startup and Recovery) нажимаем Параметры (Settings ).

В окне Загрузка и восстановление (Startup and Recovery ) мы настраиваем расположение дампа файла и его имя, а также другие параметры, связанные с загрузкой и восстановлением системы.

Прописываем путь к файлу в текстовом поле Файл дампа (Dump file).

%SystemRoot% - переменная окружения , которая заменяется системой на полный путь к папке Windows, в которой находятся системные файлы.

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

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