Анализ аварийных дампов Windows

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

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

Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).

Содержание

Анализ аварийного дампа утилитой BlueScreenView

Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.

BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.

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

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

По двойному клику отображается дополнительная информация.

Анализ аварийного дампа отладчиком WinDbg

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

Установка Debugging Tools for Windows (WinDbg)

Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки.

Для анализа аварийных дампов установка SDK не требуется. Скачать Debugging Tools for Windows (WinDbg) отдельным пакетом можно здесь.

После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%\Minidump.

Настройка отладочных символов

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

При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.

Следующей строкой включаем загрузку отладочных символов из сети, задаем локальный путь для сохранения файлов и адрес для загрузки из интернета:

Анализ аварийного дампа

В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.

Указываем путь к дампу %SystemRoot%\MEMORY.DMP или %SystemRoot%\Minidump\файл.dmp.

Загрузка отладочных символов из интернета может занять некоторое время.

Для получения детальной информации выполняем команду:

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

В результате получаем следующий вывод:

Получение информации о проблемном драйвере

Если удалось обнаружить драйвер, в котором возникла ошибка, имя драйвера будет отображено в полях MODULE_NAME и IMAGE_NAME.

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%\system32\drivers.

Находим указанный файл, и изучаем его свойства.

Обновляем проблемный драйвер.

Аппаратные причины возникновения критических ошибок

Источником критических ошибок нередко бывают неисправности в дисковой подсистеме, или в подсистеме памяти.

Диагностика неисправностей диска

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

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

Проверяем параметры S.M.A.R.T жесткого диска, получить их можно, например, с помощью программы SpeedFan.

Особое внимание обращаем на параметры: «Current Pending Sector Count» и «Uncorrectable Sector Count», ненулевые значения этих параметров сигнализируют о неисправности диска.

Ненулевое значение параметра: «UltraDMA CRC Error Count», сигнализирует о проблеме с SATA-кабелем.

Подробнее о параметрах S.M.A.R.T. читаем в статье Википедии.

Диагностика неисправностей памяти

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

Выявить проблемы с памятью можно с помощью утилиты Memtest86+.

Загружаем образ по ссылке, записываем на диск, загружаемся с диска, запускается тест.

Начиная с Windows Vista, в системе имеется свой тест памяти. Для его запуска нажимаем «Пуск», в строке поиска набираем «памяти«, выбираем «Средство диагностики памяти Windows».

Проблемы с памятью в некоторых случаях могут быть устранены обновлением BIOS.

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

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

База знаний
Try 2 Fix beta

Анализ MEMORY.DMP после возникновения «Синего экрана смерти» (BSOD)

Синий экран для владельцев ПК с ОС Windows скорее норма, нежели что-то из ряда вон выходящее. Однако сам код ошибки, который мы можем увидеть на экране иногда бывает неинформативен, а ещё чаще ПК перезагружается раньше, чем мы можем его запомнить. На этот случай у нас есть файл MEMORY.DMP, который хранит всю информацию о падении системы. Показываем, как его проанализировать.

Строка, которую надо скопировать на одном из этапов:

Эти статьи будут Вам интересны

PostgreSQL 9.4.2-1.1C: Резервное копирование SQL баз данных 1С самым простым путём

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

Запуск Google Chrome в полноэкранном режиме

14 октября 2016 ВК Tw Fb

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

LAMP-Stack сервер: ещё одна инструкция по настройке Linux + Apache + MySQL + PHP + phpMyAdmin на Ubuntu 18. Установка с помощью Tasksel.

22 октября 2018 ВК Tw Fb

Ещё одна — потому что в Интернете существует уже 100500 таких инструкций. А чем мы хуже? Настраиваем легендарную связку Linux + Apache + MySQL + PHP + phpMyAdmin на чистой Ubuntu 18 старым дедовским способом. А потом посмотрим, что нам даёт инструмент Tasksel. Если Вы любите хардкор, то у нас есть инструкция по созданию WEB-сервера на основе FreeBSD. Эта настройка подойдёт скорее для выполнения университетских лабораторных работ, нежели для продакшна. Но это тот минимум, который позволит использовать все перечисленные в заголовке компоненты.

База знаний «Try 2 Fix» Beta

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

The computer has rebooted from a bugcheck — MEMORY.DMP

Over the last few days, I’ve had some issues with intermittent crashing. At first, the issue seemed to happen exclusively while running a particular game, and the crash would entail the computer screen going a solid color (such as pink), the sound glitching and no apparent way to get out of there without simply powering the machine down all the way and restarting. No actual BSOD. I cleaned out my case, just in case it was an overheating issue, checked to make sure both the CPU fans and main fans were running, etc. I also rebooted into the BIOS and performed system checks (everything passed the performance tests), the main drive doesn’t seem particularly fragmented (2%) and I updated my NVIDIA GeForce GTX 620 drivers to the latest version.

Ran fine for about 16 hours, but while I was away from the machine, it apparently did a random reboot. It doesn’t seem to have been a reboot necessitated by a Windows update. Event viewer shows:

Error 12/30/2017 8:43:08 PM Microsoft-Windows-WER-SystemErrorReporting 1001 None The computer has rebooted from a bugcheck. The bugcheck was: 0x00000133 (0x0000000000000001, 0x0000000000001e00, 0xfffff80115bf9370, 0x0000000000000000). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: 14966973-9f91-4d62-bb07-8c5a46f3b727.

I’ve uploaded the Minidumps to my OneDrive. The link is https://1drv.ms/u/s!Aknec6bsEBAPlU-CUioJGlqZeiSi

Windows 10 1709 Build 16299 64-Bit system

Processor Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM) 24.0 GB

Appreciate any help in isolating whether this is a bad driver or a piece of hardware failing.

The bugcheck was c windows memory dmp

This forum is closed. Thank you for your contributions.

Asked by:

Question

Kept getting the «BSOD» and took my computer back to origional settings. I had thought something was wrong with the USB drive I kept using, because it seemed connected. Didn’t have any trouble for about a week, then today BSOD. And no USB was connected. I recieved the following report:

The computer has rebooted from a bugcheck. The bug check was 0x00000d1

(0x0000000000000000, 0x0000000000000002, 0x0000000000000000, 0xfffff88005e47a45). A dump was

saved in: C:\Windows\MEMORY.DMP. Report Id: 111911-19312-01.

Log Name: System

Task Category: None

Name Microsoft-Windows-WER-SystemError Reporting

I have completed hours of searching for a solution, to no avail. Could someone PLEASE help me.

All replies

The Stop 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) indicates that a kernel-mode driver attempted to access (for reading, as indicated by the value of the third parameter) pageable memory at a process IRQL that was too high.
This bug check is usually caused by drivers that have used improper addresses.

Upload the .DMP file to your SkyDrive and post the address here so we can analyze it and try to understand the problem and suggest you a solution.

Luigi Bruno — Microsoft Community Contributor 2011 Award

Чем открыть файл дампа памяти Windows MEMORY.DMP

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

В Windows существуют два типа дампа памяти — малый дамп (minidump) и полный дамп.
Minidump находится в директории C:\Windows\Minidump и его название имеет примерно такой вид Mini051819-01.dmp.
Полный дамп располагается в папке C:\Windows и называется MEMORY.DMP.

Просмотр и анализ файла минидампа.

Для просмотра и анализа файла минидампа можно воспользоваться достаточно простой и удобной утилитой BlueScreenView от Nirsoft, которую можно скачать с официального сайта https://www.nirsoft.net/utils/blue_screen_view.html .

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

Щелкнув по имени файла минидампа можно запустить поиск решения в Google.

Но эта программа не способна обработать полный дамп памяти Windows — memory.dmp.

Просмотр полного дампа памяти MEMORY.DMP.

Чтобы посмотреть содержимое полного дампа памяти необходимо открыть файл MEMORY.DMP при помощи утилиты WinDBG, которая входит в пакет Microsoft Windows SDK. Скачать эту утилиту можно с официального сайта Майкрософт по этой ссылке https://developer.microsoft.com/ru-ru/windows/downloads/windows-10-sdk .

Установка и настройка WinDBG.

Запускаем установку пакета Windows Software Development KIT и на этапе выбора компонентов отмечаем «Debugging Tools for Windows».

При первом запуске WinDBG необходимо выполнить настройку сервера отладочных символов.
1. Переходим в меню File > Symbol File Path и вставляем строку:

где C:\symbol_cache — это директория куда будут загружаться символы.

2. Сохраняем настройку File > Save Workspace.

Просмотр и анализ файла MEMORY.DMP.

Открываем файл MEMORY.DMP: File > Open Crash Dump. Начинается процесс загрузки отладочных символов, в этот момент внизу будет видна надпись: Debugee not connected.

По окончанию загрузки появится подсказка: «для анализа этого файла запустите !analize-v».

Щелкаем по надписи !analize-v и запускается анализ дампа. В этот момент в строке состояние будет надпись *BUSY*.

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

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

После выявления драйвера послужившего причиной сбоя в работе Windows и появления «Синего экрана смерти» необходимо попытаться обновить его.

Большинство проблем с драйверами решаются их обновлением.