Файл дампа памяти windows 7. Использование дампа памяти для диагностики сбоев. Анализ дампа памяти с помощью BlueScreenView

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

Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство - это скрипт автоматизации отладчика ядра под названием 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) . Посмотрим как настраивается сохранение дампа памяти в Windows 7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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