Нередко причиной возникновения ошибок при загрузке, или работе Windows (так называемый BSOD, или синий экран смерти) является ошибка в работе свежеустановленного, или поврежденного драйвера. Решить проблему возникновения ошибки (BSODа) можно, но для этого необходимо выяснить драйвер какого же устройства работает неправильно, или какое, вновь установленное, приложение поставило неисправный драйвер. Но название драйвера не всегда отображается в тексте ошибки BSOD. На самом деле нечего невозможного нет, поэтому и в случае проблемы с синим экрапом есть способ, с помощью которого можно за пару минут выяснить какой же именно драйвер неисправен и переходить к восстановлению системы.
1. Как включить дамп памяти.
Первое, что на нужно, это убедиться, что дамп памяти включен. Для этого необходимо перейти в свойства системы нажав Win+Pause (в Vista нажать ссылку Дополнительные параметры системы), далее переходим на вкладку дополнительно и нажимаем "Загрузка и восстановление".
"Small Memory Damp 64k" для нас должно быть более чем предостаточно.
Обязательно обратите внимание на путь к папке где храниться информация о дампе памяти, эти файлы Вам помогут в дальнейшем получать информацию о поврежденных драйверах в системе.
Теперь Вы сможете в любой момент сделать архив файлов из папки minidamp прикрепить архив к сообщению и отправить на форум по решению компьютерных проблем. А дальше ждать пока Вам кто то не скажет название проблемного драйвера. Но также, ненапрягаясь, Вы можете самостоятельно узнать название драйвера.
2. Установка средств диагностики.
- установите Debugging Tools For Windows
- загрузите KDFE.CMD . Извлеките файлы из архива в папку на компьютере.
Примечание. В случае нестандартного расположения папки Program Files вам может потребоваться указать в kdfe.cmd путь к папке, в которую установлены средства Debugging Tools for Windows. Используйте переменную dbgpath в строке 41.
3. Анализ дампа памяти
Последним шагом все сводится к выполнению одной команды. Откройте командную строку и перейдите в папку, в которую был распакован kdfe.cmd. Запустите файл, указав в качестве параметра путь к файлу дампа памяти (в примере ниже файл называется Mini1110307-01.dmp)
kdfe.cmd "%systemroot%\Minidump\Mini1110307-01.dmp"
Теперь вы увидите результат.
Это и есть драйвер, послуживший причиной ошибки!
Он появляется в самый неподходящий и неожиданный момент... Он вгоняет в ужас неподготовленных пользователей... Он может пустить насмарку все Ваши многодневные труды... Кто он? Синий экран смерти:)
Что такое синий экран смерти
Синий экран смерти (или BSOD ) по сути являет собой один из многочисленных видов сообщений об ошибке. Однако, если обычные некритичные сообщения можно закрыть, продолжив работать с системой, то синий экран появляется при сбоях, несовместимых с нормальным функционированием Windows и "лечится" только перезагрузкой компьютера.
Впервые BSOD официально появился в Windows 3.1 (хотя говорят, что он был и в самой первой версии системы). С тех пор его внешний вид и содержание постепенно менялось, но суть оставалась прежней - если синий экран появился, то с системой явно что-то не так...
На экране смерти в виде текста всегда отображается причина сбоя системы и ряд технических данных. Они могут содержать упоминание файлов из-за которых произошёл сбой и/или код ошибки, благодаря которому можно попытаться найти решение по её устранению. Наиболее информативным BSOD был в Windows XP, Vista и 7. Начиная с "Восьмёрки", на нём содержится лишь код ошибки (правда, дополненный в "Десятке" QR-кодом со ссылкой на страницу её описания)
Кстати, экран смерти Windows может быть не только синим! В Windows Vista критические ошибки ядра вызывали сообщение на красном фоне (RSOD), а в Windows 10 Preview все сбои отображаются на зелёном фоне (GSOD)! Кроме того существует ряд ошибок, которые возникают обычно на этапе загрузки на чёрном фоне и некоторыми именуются не иначе как "чёрный экран смерти" или KSOD (сокр. от англ. "blacK Screen Of Death"):
Что интересно, при желании Вы сами можете поменять цвета на экране смерти:) Проще всего это сделать при помощи программы Notmyfault от небезызвестного Марка Руссиновича. Полную инструкцию можно посмотреть . Ну а мы продолжим изучать само явление BSOD.
Как выяснить причину сбоя
Как мы уже говорили выше, наиболее информативными экраны смерти были в Windows XP, Vista и 7. На их примере рассмотрим структуру типичного BSOD:
На первый взгляд здесь очень много английского текста, который и вгоняет в ступор новичков, сталкивающихся с синим экраном не так часто. Для подготовленного же пользователя пользу несёт всего три-четыре (в зависимости от типа сбоя) строчки:
- The problem seems to be caused by the following file: (Проблема, скорее всего, была вызвана следующим файлом). Как правило, это второй абзац синего экрана смерти. Он содержит имя файла, в работе которого случился сбой. В ряде случаев этот параметр может быть пустым.
- Название сбоя . Эта строка идёт сразу после предыдущей и содержит в себе название ошибки, по которому можно поискать в Интернете способы её устранения. После этой строки обычно идёт секция со стандартными советами, вроде перезагрузки компьютера и удаления всех новоустановленных программ, драйверов и устройств.
- Technical Information: (техническая информация). Нижний блок синего экрана смерти, который содержит два важных параметра: стоп-код ошибки , по которому можно также определить сбой в Интернете, и дополнительные данные об области памяти сбойного файла, в котором случился сбой (может отсутствовать в ряде случаев).
В случае же появления ошибки на Windows 8 и 10, синий экран, увы, не настолько информативен. Он выдаёт нам лишь название сбоя и иногда в скобках указывает файл, в котором этот сбой произошёл:
Имея данные о названии сбоя, коде ошибки и зная файл, который привёл к ней, мы можем поискать в Интернете возможные варианты решения проблемы. Кстати, иногда даже искать особо не приходится, если имя сбойного файла о чём-то говорит. К примеру, существовавшая одно время ошибка в браузере Амиго часто приводила к BSOD в Windows 7 x64. Естественно, что на экране смерти чётко и ясно была прописана ссылка на файл "amigo.exe", а решалась проблема банальным удалением навязанного браузера:)
Итак, мы уже поняли, что синий экран смерти даёт нам определённую информацию относительно вызвавшего его сбоя. Однако, диагностировать причину появления ошибки можно не только по описанию, но ещё и по времени появления BSOD. Например, если синий экран "вываливается" до загрузки системы, то проблема часто кроется в драйверах, запускаемых службах или повреждении файловой системы. Появление экрана смерти сразу после запуска системы может свидетельствовать о некорректно работающей программе или вирусе в автозагрузке. А стоп-экран уже после запуска может означать перегрев процессора, ошибки оперативной памяти или же некорректную работу программ.
Анализ дампов памяти
Чтобы сказать что-либо наверняка нужно воспользоваться одним из механизмов фиксации различных сбоев и ошибок, которых в Windows имеется несколько. Во-первых, все события пишутся в Журналы Windows (Панель управления - Администрирование - Просмотр событий). Во-вторых, критические ошибки отображаются в виде синих экранов смерти . Но при штатной работе системы во время появления BSOD также создаются ещё и специальные файлы, которые называются дампами памяти .
Дампы - это файлы с расширением.DMP, которые содержат в себе образы оперативной памяти на момент возникновения критической ошибки. В современных версиях Windows различают:
- малый дамп памяти (от 64 до 256 КБ) - содержит данные о сбое системы и перечень загруженных на момент его возникновения драйверов;
- дамп памяти ядра - вмещает в себе всё содержимое памяти, задействованное ядром системы;
- полный дамп памяти - отражает полный образ всего доступного объёма оперативной памяти.
Кроме того, в новых версиях Windows (8 и 10) были добавлены режимы "автоматический дамп памяти" и "активный дамп памяти". Первый тип содержит ту же информацию, что и дамп памяти ядра, но может автоматически дополнять содержимое оперативной памяти ещё и содержимым файла подкачки. Активный же дамп, который появился в "Десятке", являет собой вариант полного, но включает в отчёт только данные активной памяти основной системы, отсекая любые функции виртуализации.
Для диагностики причин появления BSOD, как правило, достаточно малого дампа памяти. Его автоматическое создание при сбое нужно активировать (хотя, в некоторых сборках Windows оно уже активировано по умолчанию). Вызовите Свойства значка "Компьютер" на рабочем столе. Откроется оснастка "Система". Теперь нажмите на левой панели ссылку "Дополнительные параметры системы" , в открывшемся окошке перейдите на вкладку "Дополнительно" и нажмите кнопку . В секции "Отказ системы" проверьте, стоит ли галочка "Записать событие в системный журнал" и в выпадающем списке ниже выберите значение "Малый дамп памяти" :
Теперь при каждом возникновении BSOD в папке C:\Windows\Minidump (путь можно при желании изменить в описанных выше настройках) должны будут создаваться файлы, из которых можно узнать дополнительную полезную информацию о причинах появления синего экрана! Однако, чтобы их открыть и посмотреть нужна некоторая предварительная подготовка.
Во-первых, требуется установить набор системных отладочных инструментов под названием Debugging Tools for Windows . Получить их официально можно в составе одного из пакетов для разработчиков на следующей странице . Я бы рекомендовал третий способ в секции "As a standalone tool set" . Вам потребуется скачать веб-установщик Windows SDK по ссылке в описании и в процессе выбора компонентов оставить только "Debugging Tools for Windows" :
Можно поступить и более простым способом, скачав и установив Debugging Tools for Windows в виде отдельного готового решения (есть в архиве, который скачивается по кнопке-ссылке в самом низу статьи). Но в данном случае установится 32-битная версия пакета утилит и на 64-битных системах может потребоваться дальнейшая перенастройка инструментов анализа дампов (в принципе, особо сложного в этом ничего нет и я покажу как это сделать).
Когда пакет Debugging Tools for Windows будет установлен, нужно будет определиться с инструментами для анализа файлов с дампами памяти. Из наиболее популярных стоит отметить консольный скрипт KDFE.CMD от Александра Суховея и утилиту с графическим интерфейсом BlueScreenView от небезызвестного разработчика Nir Sofer из NirSoft. Оба эти инструмента взаимодополняют друг друга, поэтому все их также можно скачать вместе с остальными материалами к этой статье по ссылке внизу.
Несмотря на то, что скрипт KDFE.CMD был написан нашим земляком ещё для Windows 2000, он до сих пор отлично работает даже на "Десятке"! При этом, если на компьютере корректно установлен Debugging Tools for Windows, скрипт не требует никакой перенастройки.
Чтобы начать работать с ним, скопируйте его из скачанного с нашего сайта архива в корень системного диска, а ещё лучше в специально созданную папку C:\dump (буква диска зависит от буквы Вашего системного раздела). Теперь, если запустить скрипт двойным щелчком, он выдаст нам список доступных дампов памяти и предложит ввести порядковый номер нужного нам файла (поскольку своих дампов у меня не было, то для теста я взял файлы и поместил их в C:\Windows\Minidump). После этого он автоматически проанализирует указанный дамп и выдаст результат:
В отчёте будут указаны:
- дата сбоя (Crash date);
- стоп-код ошибки, который отображался на синем экране (Stop error code);
- имя процесса, вызвавшего сбой (Process name);
- вероятный модуль, который привёл к сбою (Probably caused by).
Как видим, сбой произошёл при работе с виртуальной машиной VirtualBox и связан он, скорее всего, с ошибкой в реализации модуля виртуализации сети (такая ошибка действительно существовала, но на сегодняшний день уже давно исправлена). В данном случае причиной сбоя стал сторонний софт, который мы, как пользователи, самостоятельно исправить не можем. Поэтому верным решением в данном случае будет написать о проблеме разработчикам и ждать новой исправленной версии программы.
Теперь попробуем подсунуть этот же дамп памяти программе BlueScreenView . Преимуществом данной утилиты является то, что она позволяет просматривать не только информацию о сбойных модулях, но и всё содержимое дампа. Но для нормальной работы программу может потребоваться предварительно настроить. Запустите её, и в меню "Настройки" выберите раздел "Дополнительные параметры" (либо нажмите CTRL+O). В открывшемся окошке проверьте путь к исполняемому файлу DumpChk.exe из установленного у Вас пакета Debugging Tools for Windows:
Что интересно, если скрипт KDFE.CMD выдавал нам причину, вызвавшую сбой, то BlueScreenView выдаёт следствие, которое привело к появлению BSOD. То есть, здесь отображаются те системные файлы, которые пострадали от ошибки в работе стороннего ПО. Они отмечаются красным выделением. То есть, фактически представление программы BlueScreenView дублирует собой представление самого синего экрана смерти с указанием названия ошибки, стоп-кода и пострадавших системных файлов.
Кстати, представление данных можно менять. Чтобы сделать это откройте меню "Настройки" , перейдите в раздел "Режим нижнего окна" и выберите один из доступных пунктов. По умолчанию здесь активен первый - "Все загруженные драйверы", однако, полезными могут оказаться также режимы "Синий экран BSOD в стиле XP" (отображает непосредственно синий экран смерти на момент сбоя) или "Необработанные данные" (выводит всё содержимое дампа памяти в HEX-формате):
Таким образом, использование для анализа дампа памяти обеих инструментов позволит нам получить максимально полную картину причины появления BSOD. А точная диагностика - это уже верный путь к устранению проблемы!
Варианты устранения синего экрана
Для правильного реагирования на появление BSOD и устранения причин его вызывающих мы должны сопоставить все известные нам факты, которые предшествовали сбою и проявляются в данный момент. Если сбой проявился спонтанно и лишь один раз, то, скорее всего, он был вызван некорректной работой какой-либо программы или её драйвера. В этом случае достаточно посмотреть дамп памяти, выяснить, что за программа привела к появлению сбоя (при помощи KDFE.CMD) и написать разработчикам о найденной ошибке с описанием её названия и стоп-кода (можно и вовсе послать им файл дампа памяти).
Если же сбой повторяется периодически, то здесь, вероятнее всего, мы имеем дело либо с ошибкой в работе определённых системных компонентов (чаще всего несовместимость ПО), либо с реальной физической поломкой одного из узлов компьютера (чаще всего сбои файловой системы на жёстком диске, ошибки оперативной памяти или перегрев процессора). Как ни странно, для устранения проблемы можно вполне воспользоваться советами, которые изложены на самом синем экране смерти:
- удалить или переустановить новые программы и/или драйвера;
- отключить новые устройства, которые были подключены к компьютеру;
- сбросить настройки BIOS (для этого проще всего извлечь из материнской платы батарейку-"таблетку" минут на 5).
Если Windows не загружается, произвести все эти манипуляции можно попытаться в Безопасном режиме. Чтобы его вызвать, нажимайте клавишу F8 при начале загрузки системы. Загрузившись таким образом (или стандартным), Вы можете последовать официальным рекомендациям по устранению BSOD от Microsoft.
Выводы
Синий экран смерти вовсе не означает окончательную смерть Windows. Он означает начало весьма "увлекательного" процесса поиска и устранения проблемы. В своей практике мне не раз приходилось выводить компьютеры из состояния вечно появляющегося BSOD и почти всегда причины были разными, а на поиск их исправления порой уходило по несколько часов!
Но, что самое главное, примерно в 3 из 4 случаев "поднять" Windows всё же удавалось без переустановки с сохранением всех данных пользователей и собственного авторитета в их глазах:) Поэтому, желаю и Вам успешных поисков и быстрых устранений любых сбоев!
P.S. Разрешается свободно копировать и цитировать данную статью при условии указания открытой активной ссылки на источник и сохранения авторства Руслана Тертышного.
Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство - это скрипт автоматизации отладчика ядра под названием 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 .
Синий экран смерти или BSOD (The blue screen of death) - это всегда очень тревожный симптом проблем с компьютером. Данный экран появляется, когда Windows обнаруживает критическую ошибку, которую система не в состоянии исправить самостоятельно. В результате запрашивается перезагрузка компьютера, и очень часто это приводит к потере всех несохраненных изменений.
Синий экран смерти - это худшая ошибка, с которой может столкнуться пользователь компьютера. В отличие от сбоев приложений, критическое падение с BSOD нарушает работоспособность всей системы. Обычно синий экран смерти появляется в результате сбоев программного обеспечения низкого уровня или проблем аппаратных компонентов компьютера.
Причины появления BSOD
Обычно синие экраны смерти вызваны неисправностью оборудования компьютера или драйверами. Обычные приложения не должны вызывать BSOD. В случаи падения сторонние программы не вызывают нарушение работоспособности операционной системы. Самые частые причины BSOD - аппаратные сбои или проблемы с программным обеспечением уровня ядра Windows. Бывают падения, связанные с обновлениями антивирусов.
Синий экран обычно появляется, когда Windows обнаруживает “STOP-ошибку”. Данное критическое падение приводит к остановке работы системы Windows. В этом случае остается только принудительно выключить компьютер и перезагрузить его. Данная процедура может привести к потере несохраненных данных, потому что у приложений фактически нет шансов для сохранения изменений. В идеальном сценарии программы должны регулярно сохранять прогресс работы, чтобы BSOD или другие ошибки не привели к потере данных.
При появлении синего экрана смерти Windows автоматически создает и сохраняет на диск файл дампа памяти “minidump”, который содержит информацию о критическом сбое. Пользователи могут просматривать информацию в дампах - она может помочь идентифицировать причину падения с BSOD.
По умолчанию, Windows автоматически перезагружает компьютер при появлении синего экрана смерти. Если ваш компьютер перезагружается без видимой причины, то возможно, это связано с синим экраном.
Если вы хотите ознакомиться с детальной информацией при появлении синего экрана, то следует отключить автоматическую перезагрузку в панели управления Windows.
- Кликните по значку “Мой компьютер”.
- Нажмите правой кнопкой мыши и выбери пункт “Свойства”.
- В левом навигационном меню выберите опцию “Дополнительные параметры системы”.
- Перейдите на вкладку “Дополнительно” и в секции “Загрузка и восстановление” нажмите кнопку “Параметры”.
- В секции “Отказ системы” снимите галочку с опции “Выполнить автоматическую перезагрузку”.
Приложение BlueScreenView предлагает простой способ для просмотра информации о BSOD. Программа автоматически сканирует все файлы дампа памяти и отображает данные о сбоях.
Аналогичную информацию можно посмотреть с помощью встроенного в систему классического приложения “Просмотр событий”. Правда в этом случае сообщения BSOD будут отображаться в одном списке с падениями приложений и другими сообщениями системного журнала.
Для разработчиков или продвинутых пользователей больше подойдет мощный отладчик дампов WinDbg от Microsoft.
Поиск и устранение уязвимостей
В Windows 7 и в более новых версиях Windows, информация о BSOD также отображается в центре действия. Если вы столкнулись с ошибкой BSOD, то можете открыть Центр действия и проверить доступные решения. Windows проанализирует BSOD и другие типы ошибок на компьютере и предоставить рекомендации по устранению проблемы.
Часто можно получить дополнительную информацию об ошибке синего экрана, при поиске конкретного сообщения об ошибке - например, “Driver_IRQL_not_less_or_equal”. Новые экраны BSOD в системах Windows сами побуждают пользователей выполнить поиск в Интернете, чтобы подробно ознакомиться с возможными проблемами.
- Используйте мастер восстановления системы. Если система недавно начала испытывать сбои с BSOD, используйте функцию восстановления системы, чтобы вернуть систему в предыдущее стабильное состояние. Если это поможет, то вероятно, проблема была вызвана ошибками программного обеспечения.
- Проверьте систему на наличие вредоносных программ . Угрозы, которые проникают глубоко в ядро Windows могут вызвать проблемы стабильности системы. Выполните сканирование компьютера на наличие вредоносных программ, чтобы убедиться, что сбой системы не вызван коварными зловредами.
- Установите обновления драйверов. Некорректно установленный или неисправный драйвер может приводить к падениям. Загрузите и установите новейшие драйвера для компонентов компьютера с официального сайта производителя - это может помочь справиться с BSOD.
- Выполните загрузку в безопасном режиме . Если ваш компьютер постоянно выдает сбои с BSOD, то попытайтесь загрузиться в безопасном режиме. В безопасном режиме Windows загружает только самые основные драйвера. Если синий экран смерти появляется из-за установленного драйвера, то в безопасном режиме критической ошибки не будет, и вы сможете исправить проблему.
- Выполните диагностику аппаратных компонентов. Синие экраны могут быть вызваны неисправным оборудованием. Попробуйте выполнить тестирование памяти на предмет ошибок и проконтролируйте температуру отдельных элементов ПК, чтобы убедиться, что он не перегревается.
- Переустановите Windows. Чистая установка системы является радикальным действием, но она позволит избавиться от возможных проблем установленных программ. Если после переустановки системы, ошибки BSOD продолжаются, что, скорее всего, они связаны с оборудованием.
Даже, абсолютно исправный компьютер в редких случаях может испытывать падения с BSOD без видимой причины - из-за ошибок драйверов, установленных приложений или аппаратных компонентов.
Если вы очень редко сталкиваетесь с BSOD (скажем, раз в два года), то нет причин для беспокойства. Если ошибки с BSOD выскакивают регулярно, то нужно искать причину и устранять проблему.
Все Windows-системы при обнаружении фатальной ошибки делают аварийный дамп (снимок) содержимого оперативной памяти и сохраняет его на жесткий диск. Существуют три типа дампа памяти:
Полный дамп памяти – сохраняет все содержимое оперативной памяти. Размер снимка равен размеру оперативной памяти + 1 Мб (заголовок). Используется очень редко, так как в системах с большим объемом памяти размер дампа будет слишком большим.
Дамп памяти ядра – сохраняет информацию оперативной памяти, касающуюся только режима ядра. Информация пользовательского режима не сохраняется, так как не несет в себе информации о причине краха системы. Объем файла дампа зависит от размера оперативной памяти и варьируется от 50 Мб (для систем с 128 Мб оперативной памяти) до 800 Мб (для систем с 8 Гб оперативной памяти).
Малый дамп памяти (мини дамп) – содержит довольно небольшое количество информации: код ошибки с параметрами, список драйверов загруженных в оперативную память на момент краха системы и т.д., но этих сведений достаточно, для определения сбойного драйвера. Еще одним преимуществом данного вида дампа является маленький размер файла.
Настройка системы
Для выявления драйвера вызвавшего нам достаточно будет использовать малый дамп памяти. Для того чтобы система при крахе сохраняла мини дамп необходимо выполнить следующие действия:
| Для Windows Xp | Для Windows 7 |
|
|
Проделав все манипуляции, после каждого BSoD в папке C:\WINDOWS\Minidump будет сохраняться файл с расширение.dmp. Советую ознакомиться с материалом " ". Также можно установить галочку на “Заменить существующий файл дампа ”. В этом случае каждый новый аварийный дамп будет записываться поверх старого. Я не советую включать данную опцию.
Анализ аварийного дампа памяти с помощью программы BlueScreenView
Итак, после появления синего экрана смерти система сохранила новый аварийный дамп памяти. Для анализа дампа рекомендую использовать программу BlueScreenView. Её можно бесплатно скачать . Программа довольно удобная и имеет интуитивный интерфейс. После её установки первое, что необходимо сделать – это указать место хранение дампов памяти в системе. Для этого необходимо зайти в пункт меню “Options ” и выбрать “Advanced Options ”. Выбираем радиокнопку “Load from the following Mini Dump folder ” и указываем папку, в которой хранятся дампы. Если файлы хранятся в папке C:\WINDOWS\Minidump можно нажатием кнопки “Default ”. Нажимаем OK и попадаем в интерфейс программы.
Программа состоит из трех основных блоков:
- Блок главного меню и панель управления;
- Блок списка аварийных дампов памяти;
- В зависимости от выбранных параметров может содержать в себе:
- список всех драйверов находящихся в оперативной памяти до появления синего экрана (по умолчанию);
- список драйверов находящихся в стеке оперативной памяти;
- скриншот 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).
