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

Как провести анализ дампа памяти для выявления причины BSoD?

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

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

Данное явление говорит о критической неполадке, как в программном обеспечении, например, конфликт драйверов, так и в физической неисправности какого-то компонента компьютера.

Недавно у меня снова появился голубой экран в Windows 10, но я быстро от него избавился и скоро об этом вам расскажу.
Хотите смотреть фильмы онлайн в хорошем качестве? Тогда переходите по ссылке.

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

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

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

Дамп ядра – сохраняет информацию о режиме ядра.

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

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

Для анализа дампов памяти существуют различные программы, но мы воспользуемся двумя. Первая — 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», потом жмем ОК.

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

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

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

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

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

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

Зайдите в параметры: «Настройки» — «Дополнительные параметры». Откроется небольшое окошко, в котором есть пару пунктов. В первом пункте нужно указать местонахождение дампов памяти. Обычно они находятся по пути C:\WINDOWS\Minidump.

Тогда просто нажмите кнопку «По умолчанию».

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

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

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

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

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

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

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

Источник: https://computerinfo.ru/analiz-dampa-pamyati/

Kdfe — анализ аварийного дампа памяти

  BSOD, kd, Symbol

Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство — это скрипт автоматизации отладчика ядра под названием 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. Из этого следует, что нам требуется сперва установить Debugging Tools for Windows.

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

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

Скачать: kdfe

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

123456789101112131415161718192021222324252627282930

. . .::Kernel debugger path. Default is:::For version 6.8.4.0 — October 18, 2007 and olderIF 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 newerrem 32 bitIF EXIST «%PROGRAMFILES%\Debugging Tools for Windows (x86)\kd.exe» (set dbgpath=»%PROGRAMFILES%\Debugging Tools for Windows (x86)») ELSE (rem 64 bitIF 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!pauseexit /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).

exe с указанием полного пути до исполняемого файла.

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

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

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

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

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

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

ПараметрОписание

Crash date	Дата и время произошедшего сбоя.
Stop error code	Код СТОП-ошибки (BugCheck). В нашем случае это STOP 0x00000124.
Process name	Сообщает имя процесса, в контексте которого произошел сбой.
Probably caused by	Выводится возможный источник проблемы.

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

По выводу мы можем понять, что в данном конкретном случае присутствует исключительно аппаратная проблема (ключевое слово hardware). Забегая вперед скажу, что виновником оказался процессор.

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

Однако, по статистике, в большинстве случаев виновниками синих экранов являются драйвера устройств сторонних производителей, в подобном случае в строке probably caused by мы можем увидеть нечто вроде igxpdv32.dll.

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

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

Источник: http://datadump.ru/kdfe/

Аварийный дамп памяти

:   / 299

673204

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

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

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

Информация пользовательского режима не сохраняется, так как не несет в себе информации о причине краха системы.

Объем файла дампа зависит от размера оперативной памяти и варьируется от 50 Мб (для систем с 128 Мб оперативной памяти) до 800 Мб (для систем с 8 Гб оперативной памяти).

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

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

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

Для Windows Xp	Для Windows 7
Правой клавишей мыши нажать на значке Мой компьютер из контекстного меню выберите Свойства (или комбинация клавиш Win+Pause); Переходите на вкладку Дополнительно; В поле Загрузка и восстановление необходимо нажать кнопку Параметры; В поле Запись отладочной информации выбираем Малый дамп памяти (64 Кб).	Правой клавишей мыши нажать на значке Компьютер из контекстного меню выберите Свойства (или комбинация клавиш Win+Pause); В левом меню щелкаем на пункт Дополнительные параметры системы; Переходите на вкладку Дополнительно; В поле Загрузка и восстановление необходимо нажать кнопку Параметры; В поле Запись отладочной информации выбираем Малый дамп памяти (128 Кб).

Проделав все манипуляции, после каждого BSoD в папке C:\WINDOWS\Minidump будет сохраняться файл с расширение .dmp. Советую ознакомиться с материалом «Как создать папку».

Также можно установить галочку на “Заменить существующий файл дампа”. В этом случае каждый новый аварийный дамп будет записываться поверх старого.

Я не советую включать данную опцию.

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

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

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

Для этого необходимо зайти в пункт меню “Options” и выбрать “Advanced Options”. Выбираем радиокнопку “Load from the following Mini Dump folder” и указываем папку, в которой хранятся дампы.

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

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

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

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

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

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

Для того чтобы программа показывала список драйверов находящихся в стеке памяти во время возникновения BSoD необходимо зайти в пункт меню “Options” кликаем на меню “LowerPaneMode” и выбираем “OnlyDriversFoundInStack” (или нажмите клавишу F7), а для показа скриншота ошибки выбираем “BlueScreeninXPStyle” (F8). Что бы вернуться к списку всех драйверов, необходимо выбрать пункт “AllDrivers” (F6).

Буду признателен, если воспользуетесь кнопочками:

Источник: http://BsodStop.ru/poleznye-stati/analiz-dampa-pamyati

Аварийные дампы памяти в Windows – что это такое, как включить/выключить, анализ Memory Dump

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

  Создание и использование сервера VPN в Windows стандартными средствами

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

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

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

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

В Windows 7:

1. Запускаем Мой компьютер и в свободном месте нажимаем правой кнопочкой мышки, выбираем пункт «Свойства».
2. В открывшемся окошке о системе слева переходим в раздел «Дополнительные параметры системы».
3. На следующем этапе переходим на вкладку «Дополнительно» и щелкаем по третьей кнопке «Параметры» в области «Загрузка и восстановление».
4. Настраиваем параметры по вашему желанию. Обязательно должен быть выбран какой-либо тип.
5. Нажимаем ОК.

В Windows 8 и 10:

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

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

1. Щелкаем клавиши Win+I, открываются параметры ОС.
2. Переходим в раздел «Система».
3. Слева в самом низу выбираем подраздел «О системе».
4. В правой части окна опускаемся в низ и щелкаем по ссылке «Сведения о системе».
5. Слева выбираем «Дополнительные параметры системы».
6. Во вкладке «Дополнительно» нажимаем третью кнопку «Параметры».
7. Выбираем нужный файлик и жмём ОК.

  Установка и настройка вайбер на телефоне или компьютере

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

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

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

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

1. Открываем с помощью комбинации клавиш Win+R окошко «Выполнить» и прописываем команду cleanmgr.
2. Ищем кнопочку «Очистить системные файлы» и жмём по ней.
3. Если есть пункт о файлах дампов памяти, выделяем и очищаем.

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

Даже если вы когда-то включали их, некоторые используемые утилиты по оптимизации системы могут легко отключить некоторый функционал. Часто много чего отключается при использовании 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 и щелкаем опцию «Open Crash Dump». Расположение всех дампов указано в начале статьи.

  Что делать, если windows загружается с временным профилем

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

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

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

Запускаем и настраиваем. Нажмите «Настройки» (Options) – «Дополнительные параметры» (Advanced Options).

Выберите первый пункт «Загружать МиниДампы из этой папки» и указываем каталог — C:\WINDOWS\Minidump.

Хотя можно просто нажать кнопку «По умолчанию». Нажимаем ОК.

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

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

Источник: http://composs.ru/chto-takoe-damp/

BSOD — Синий экран смерти

Научитесь читать синий экран смерти и Вы сможете решить большинство проблем Windows без переустановки системы.

Он появляется в самый неподходящий и неожиданный момент… Он вгоняет в ужас неподготовленных пользователей… Он может пустить насмарку все Ваши многодневные труды… Кто он? Синий экран смерти

Что такое синий экран смерти

Синий экран смерти (или 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:

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

1. The problem seems to be caused by the following file: (Проблема, скорее всего, была вызвана следующим файлом). Как правило, это второй абзац синего экрана смерти. Он содержит имя файла, в работе которого случился сбой. В ряде случаев этот параметр может быть пустым.
2. Название сбоя. Эта строка идёт сразу после предыдущей и содержит в себе название ошибки, по которому можно поискать в Интернете способы её устранения. После этой строки обычно идёт секция со стандартными советами, вроде перезагрузки компьютера и удаления всех новоустановленных программ, драйверов и устройств.
3. Technical Information: (техническая информация). Нижний блок синего экрана смерти, который содержит два важных параметра: стоп-код ошибки, по которому можно также определить сбой в Интернете, и дополнительные данные об области памяти сбойного файла, в котором случился сбой (может отсутствовать в ряде случаев).

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

Имея данные о названии сбоя, коде ошибки и зная файл, который привёл к ней, мы можем поискать в Интернете возможные варианты решения проблемы. Кстати, иногда даже искать особо не приходится, если имя сбойного файла о чём-то говорит.

К примеру, существовавшая одно время ошибка в браузере Амиго часто приводила к BSOD в Windows 7 x64. Естественно, что на экране смерти чётко и ясно была прописана ссылка на файл «amigo.

exe», а решалась проблема банальным удалением навязанного браузера

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

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

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

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

Чтобы сказать что-либо наверняка нужно воспользоваться одним из механизмов фиксации различных сбоев и ошибок, которых в Windows имеется несколько.

Во-первых, все события пишутся в Журналы Windows (Панель управления – Администрирование – Просмотр событий). Во-вторых, критические ошибки отображаются в виде синих экранов смерти.

Дампы – это файлы с расширением .DMP, которые содержат в себе образы оперативной памяти на момент возникновения критической ошибки. В современных версиях Windows различают:

• малый дамп памяти (от 64 до 256 КБ) – содержит данные о сбое системы и перечень загруженных на момент его возникновения драйверов;
• дамп памяти ядра – вмещает в себе всё содержимое памяти, задействованное ядром системы;
• полный дамп памяти – отражает полный образ всего доступного объёма оперативной памяти.

Кроме того, в новых версиях Windows (8 и 10) были добавлены режимы «автоматический дамп памяти» и «активный дамп памяти».

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

Активный же дамп, который появился в «Десятке», являет собой вариант полного, но включает в отчёт только данные активной памяти основной системы, отсекая любые функции виртуализации.

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

Вызовите Свойства значка «Компьютер» на рабочем столе. Откроется оснастка «Система».

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

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

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

• удалить или переустановить новые программы и/или драйвера;
• отключить новые устройства, которые были подключены к компьютеру;
• сбросить настройки BIOS (для этого проще всего извлечь из материнской платы батарейку-«таблетку» минут на 5).

Если Windows не загружается, произвести все эти манипуляции можно попытаться в Безопасном режиме. Чтобы его вызвать, нажимайте клавишу F8 при начале загрузки системы. Загрузившись таким образом (или стандартным), Вы можете последовать официальным рекомендациям по устранению BSOD от Microsoft.

Выводы

Синий экран смерти вовсе не означает окончательную смерть Windows. Он означает начало весьма «увлекательного» процесса поиска и устранения проблемы.

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

Но, что самое главное, примерно в 3 из 4 случаев «поднять» Windows всё же удавалось без переустановки с сохранением всех данных пользователей и собственного авторитета в их глазах Поэтому, желаю и Вам успешных поисков и быстрых устранений любых сбоев!

P.S. Разрешается свободно копировать и цитировать данную статью при условии указания открытой активной ссылки на источник и сохранения авторства Руслана Тертышного.

Источник: https://www.bestfree.ru/article/computer/bsod.php

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

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

Синий экран смерти или как его еще называют 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее выбираем компонент и жмем install

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

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

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

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

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

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

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

Помимо самого пакета 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…

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

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

Как установить Microsoft Kernel Debugger10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ткнув по ссылке в логе вы получаете самую детальную информацию об ошибке.

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

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

Материал сайта pyatilistnik.org

Источник: http://pyatilistnik.org/kak-analizirovat-siniy-ekran-dump-memory-v-windows/