как проанализировать дамп памяти windows 10
Анализ аварийных дампов 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.
Настройка параметров сохранения аварийного дампа
Для изменения параметров сохранения аварийного дампа нажимаем кнопку «Пуск», щелкаем на «Компьютер» правой кнопкой мыши, в контекстном меню выбираем «Свойства». В окне «Система» слева выбираем «Дополнительные параметры системы», в группе «Загрузка и восстановление» нажимаем кнопку «Параметры».
Как проанализировать дамп памяти windows 10
Добрый день уважаемые коллеги и читатели блога pyatilistnik.org. Сегодня я хочу вам рассказать как производится анализ дампа памяти windows 10 Redstone. Делается это в большинстве случаев когда у вас выскакивает синий экран смерти с ошибкой, после чего ваш компьютер перезагружается. И данный анализ помогает понять причину сбоя.
Настраиваем дамп памяти windows 10
И так, что же такое дамп памяти в операционной системе Windows 10 Redstone. Выше я вам описал, очень частую причину при которой появляется дамп памяти системы и это синие экраны смерти. Причины их появления очень обширны:
Это лишь маленький обобщенный список, так как кодов ошибок от синих экраном, целая тьма, приведу самые последние из них.
Наша с вами задача, уметь найти эти файлы для диагностики и уметь их интерпретировать, для получения информации о проблеме.
Где настраивается аварийный дамп памяти windows 10
Для начала давайте разберемся, где производится настройка, которая отвечает за аварийный дамп памяти windows 10. Щелкаете правым кликом по кнопке пуск Windows 10 и из контекстного меню выбираете пункт Система.
В открывшемся окне Система, вы в левом верхнем углу выбираете Дополнительные параметры Системы.
Именно тут и настраивается дамп памяти windows 10. жмем пункт параметры в Загрузка и восстановление.
Из настроек, дампа памяти windows 10, хочу отметить следующие:
Виды дампов памяти
Давайте рассмотрим, чем же отличаются варианты записи отладочной информации
– сообщение о неустранимой ошибке, ее параметры и прочие данные;
– список загруженных драйверов;
– контекст процессора (PRCB), на котором произошел сбой;
– сведения о процессе и контекст ядра (EPROCESS) для процесса, вызвавшего ошибку;
– сведения о процессе и контекст ядра (ETHREAD) для потока, вызвавшего ошибку;
– стек вызовов в режиме ядра для потока, вызвавшего ошибку.
Его используют, когда у вас очень мало дискового пространства на вашем локальном диске. За счет этого мы жертвуем полезной информацией, которой может не хватить для диагностики синего экрана.
Теперь когда у вас появится синий экран, то дамп памяти windows 10, вы будите искать в папке C:\Windows.
Анализ дампа памяти windows 10
Ну и естественно давайте рассмотрим вопрос, как производится анализ дампа памяти windows 10, тут все просто, переходите по ссылке чуть выше и читаете статью Как анализировать синий экран dump memory в Windows. В которой я подробнейшим образом рассказал, как вам можно узнать причину падения и краха вашей операционной системы Windows 10. Желаю вам, чтобы экраны смерти обходили ваш компьютер стороной.
Анализ дампа памяти в Windows при BSOD с помощью WinDBG
В момент критического сбоя операционная система Windows прерывает работу и показывает синий экран смерти (BSOD). Содержимое оперативной памяти и вся информация о возникшей ошибке записывается в файл подкачки. При следующей загрузке Windows создается аварийный дамп c отладочной информацией на основе сохраненных данных. В системном журнале событий создается запись о критической ошибке.
Типы аварийных дампов памяти Windows
На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:
Как включить создание дампа памяти в Windows?
С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы» (Advanced system settings). Во вкладке «Дополнительно» (Advanced), раздел «Загрузка и восстановление» (Startup and Recovery) нажмите кнопку «Параметры» (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал» (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа» (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).
В большинстве случаев для анализа причины BSOD вам будет достаточно малого дампа памяти.
Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%\minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger).
Установка WinDBG в Windows
Утилита WinDBG входит в «Пакет SDK для Windows 10» (Windows 10 SDK). Скачать можно здесь.
Файл называется winsdksetup.exe, размер 1,3 МБ.
Запустите установку и выберите, что именно нужно сделать – установить пакет на этот компьютер или загрузить для установки на другие компьютеры. Установим пакет на локальный компьютер.
Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.
После установки ярлыки WinDBG можно найти в стартовом меню.
Настройка сервера отладочных символов в WinDBG
Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.
Настройте WinDBG на использование Microsoft Symbol Server:
WinDBG произведет поиск символов в локальной папке и, если не обнаружит в ней необходимых символов, то самостоятельно загрузит символы с указанного сайта. Если вы хотите добавить собственную папку с символами, то можно сделать это так:
Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.
Анализ аварийного дампа памяти в WinDBG
Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.
Команды вводятся в командную строку, расположенную внизу окна.
Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.
*****************************************************************************
* *
* Bugcheck Analysis *
* *
*****************************************************************************
Символическое имя STOP-ошибки (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Описание ошибки (Компонент ядра повредил критическую структуру данных. Это повреждение потенциально может позволить злоумышленнику получить контроль над этой машиной):
A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.
Аргументы ошибки:
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
——————
Счетчик показывает сколько раз система упала с аналогичной ошибкой:
Основная категория текущего сбоя:
Код STOP-ошибки в сокращенном формате:
Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):
Последний вызов в стеке:
LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0
Стек вызовов в момент сбоя:
Участок кода, где возникла ошибка:
FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr [rsp+20h],0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: MachineOwner
Имя модуля в таблице объектов ядра. Если анализатору удалось обнаружить проблемный драйвер, имя отображается в полях MODULE_NAME и IMAGE_NAME:
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
Если кликнете по ссылке модуля (nt), то увидите подробную информацию о пути и других свойствах модуля. Находите указанный файл, и изучаете его свойства.
1: kd> lmvm nt
Browse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)
В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.
Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.
Image path: \SystemRoot\system32\drivers\cmudaxp.sys
Image name: cmudaxp.sys
Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.
Анализ креш-дампов памяти Windows
Как часто Вам приходится лицезреть экран смерти Windows (BSoD)? BSoD может возникать в разных случаях: как уже при работе с системой, так и в процессе загрузки операционной системы. Как же определить, чем вызвано появление BSoD и устранить эту проблему? Операционная система Windows способна сохранять дамп памяти при появлении ошибки, чтобы системный администратор мог проанализировать данные дампа и найти причину возникновения BSoD.
Существует два вида дампов памяти — малый (minidump) и полный. В зависимости от настроек операционной системы, система может сохранять полный или малый дампы, либо не предпринимать никаких действий при возникновении ошибки.
Малый дамп располагается по пути %systemroot%\minidump и имеет имя вроде Minixxxxxx-xx.dmp
Полный дамп располагается по пути %systemroot% и имеет имя вроде Memory.dmp
Для анализа содержимого дампов памяти следует применять специальную утилиту — Microsoft Kernel Debugger.
Получить программу и компоненты, необходимые для ее работы, можно напрямую с сайта Microsoft — Debugging Tools
При выборе отладчика следует учитывать версию операционной системы, на которой Вам придется анализировать дампы памяти. Для 32-разрядной ОС необходима 32-битовая версия отладчика, а для 64-разрядной ОС предпочтительно использовать 64-битовую версию отладчика.
Помимо самого пакета Debugging Tools for Windows, также понадобятся набор отладочных символов — Debugging Symbols. Набор отладочных символов специфичен для каждой ОС, на которой был зафиксирован BSoD. Потому придется загрузить набор символов для каждой ОС, анализировать работу которой Вам придется. Для 32-разрядной Windows XP потребуются набор символов для Windows XP 32-бит, для 64-разрядной ОС потребуются набор символов для Windows XP 64-бит. Для других ОС семейства Windows наборы символов подбираются сообразно такому же принципу. Загрузить отладочные символы можно отсюда. Устанавливать их рекомендуется по адресу %systemroot%\symbols
После установки отладчика и отладочных символов, запускаем отладчик. Окно отладчика после запуска выглядит следующим образом. 
Перед анализом содержимого дампа памяти, потребуется провести небольшую настройку отладчика. Конкретно — сообщить программе, по какому пути следует искать отладочные символы. Для этого выбираем в меню File > Symbol File Path… Нажимаем кнопку Browse… и указываем папку, в которую мы установили отладочные символы для рассматриваемого дампа памяти.
Можно запрашивать информацию о требуемых отладочных символах прямо через Интернет, с публичного сервера Microsoft. Таким образом у вас будет самая новая версия символов. Сделать это можно следующим образом — в меню File > Symbol File Path… вводим: SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols
После указания пути к отладочным символам, выбираем в меню File > Save workspace и подтверждаем действие нажатием на кнопку OK.
Чтобы приступить к анализу дампа памяти, выбираем в меню File > Open Crash Dump… и выбираем требуемый для рассмотрения файл.
Система проведет анализ содержимого, по окончанию которого выдаст результат о предполагаемой причине ошибки.
Завершить отладку можно выбором пункта меню Debug > Stop Debugging
Таким образом, используя пакет Debugging Tools for Windows, всегда можно получить достаточно полное представление о причинах возникновения системных ошибок.
Упрощение анализа дампов памяти windows или Очередной твик контекстного меню
Многие пользователи операционных систем windows рано или поздно сталкиваются с необходимостью выяснить почему же любимая операционка «падает в бсод».
О том что это, как искать причину и как её (в зависимости от ситуации) устранять в интернете написано уже немало, но что делать, если нужно выяснить причину максимально быстро и делать это приходится регулярно как, например, работникам сервисов или завсегдатаям компьютерных форумов?
Упростить задачу могут пресловутые твики контекстного меню, благо делаются они довольно просто.
Для начала понадобится установить пакет с дебаггером windbg.exe, консольным вариантом kd.exe и прочим необходимым содержимым.
Это пакеты X64 Debuggers And Tools-x64_en-us.msi или X86 Debuggers And Tools-x86_en-us.msi на выбор в зависимости от разрядности используемой ОС и/или личных предпочтений.
Отдельных ссылок на сайте microsoft вы не найдете, но данные пакеты находятся в составе Windows Driver Kit, его можно скачать без установки выбрав соответствующий режим работы инсталятора, пакеты по завершении скачивания будут лежать в папке \Windows Kits\10\WDK\Installers.
Если кому-то нужно, то я загрузил их отдельно на Я.Диск:
Я решил не устанавливать дебаггер, а просто распаковать msi:
Такого «портабельного» варианта более чем достаточно. После, для собственного удобства, переместил нужное содержимое из нескольких вложенных папок в C:\Portable\Debug, чтобы получилось:
+ все остальное. От этого пути и будем отталкиваться в дальнейшем (плюс я внес его в %PATH% опять же, для удобства).
На этом подготовительные мероприятия можно считать завершенными и переходить к описанию процесса создания твика.
Так как в моей задаче предполагается, что дампов бывает много и часто, то нужно максимально ускорить процесс, при этом сделать его достаточно информативным для беглого анализа.
Разбираемся с ключами и командами дебаггера
В качестве основы для будущего твика возьмем вот такой батник, на который достаточно перетянуть нужный дамп.
Для лучшего восприятия информации, в моём понимании, я инвертировал цвета консоли и задал размер окна консоли побольше.
Тут можно увидеть параметры передаваемые kd.exe, такие как -y, -i и, собственно, -z, которые видели все, кто знает о широко известном в узких кругах kdfe.cmd.
Если брать по аналогии с распространенными инструкциями то тут есть небольшие отличия: в качестве аргументов дополнительно переданы -nosqm и -sup.
Вывод скрипта с использованием kd.exe получится практически аналогичен тому, который получился бы при работе непосредственно через windbg, но результат достигается гораздо быстрее так как ничего не нужно открывать, настраивать папки, открывать дамп через меню и вводить команды в дебаггер.
Фильтрация мусорного вывода из консоли
Для первого примера возьмем дамп памяти рандомного юзера. Возникает небольшая проблема с мусором в выводе:
Такое встречается, например, в дампах юзеров использующих активатор odin, что мы и видим в данном примере.
Полный вывод довольно массивный, потому ссылкой на pastebin.
Требуется «отфильтровать» ненужные строки оставив только полезную информацию.
Я использовал findstr, получилось вот такое некрасивое но работающее решение:
Тут findstr использует две регулярки: одна ищет строки начинающиеся с трех звездочек, одного пробела и заканчивающиеся на пробел и три звездочки. Вторая ищет строки начинающиеся с 14-ти звездочек. Ничего более вразумительного средствами findstr я сделать не смог.
Весь код предварительного батника с «фильтром» получился такой:
Полный вывод отфильтрованного варианта также на pastebin.
Результат аналогичный, но без «мусора». 290 строк текста против 894-х. Уже лучше, но еще не всё.
Быстрое создание лога работы дебаггера
Следующий шаг это добавление создания лога, который можно было бы запостить или отправить куда-нибудь.
Для файла 102516-21949-01.dmp будет сформирован лог 102516-21949-01.LOG в той же папке, что и сам дамп.
В данном случае вывод «мусора» в лог не фильтруется, фильтруется только вывод в консоль, но в моем случае это не принципиально, хотя можно исправить и это очистив лог уже после создания:
Открытие дампа в windbg
Теперь последний по порядку, но не по значимости шаг: нужна возможность передать дамп непосредственно в windbg.exe и сразу же передать ему команды, которые с большой долей вероятности понадобится вводить. Все делается по аналогии с kd.exe, аргументы и команды принимаемые windbg.exe практически идентичны kd.exe
В результате дамп откроется сразу в дебаггере и в нем автоматически выполнятся команды перечисленные в ключе -c.
Вывод аналогичный самому первому варианту с той разницей, что дамп открыт сразу в windbg, есть возможность вводить команды для дальнейшего анализа из-за отсутствия в передаваемом списке команд команды q.
(К слову если в предыдущих вариантах скрипта с kd.exe убрать команду q передаваемую в списке команд через аргумент -c, то возможность продолжить работу с дампом появится и там, в том числе с записью лога прямо в процессе.)
Создание твика
Теперь всё это нужно видоизменить, чтобы можно было прикрутить к контекстному меню *.dmp файлов. Собственно, ради чего это и затевалось.
Получились вот такие «однострочники»:
Для варианта с фильтрацией вывода консоли
Для варианта с фильтрацией вывода консоли и с созданием логфайла
(пришлось использовать отложенное расширение переменных)
Для открытия дампа непосредственно в windbg.exe
В реестре создал следующую структуру разделов:
Был создан отдельный тип файла dmp_geek в разделы реестра которого и вносились изменения. Файлы с расширением *.dmp были назначены файлами типа dmp_geek.
В каждом разделе command в строковый параметр по умолчанию были внесены соответствующие однострочники + красивости в виде иконок и удобных имен отображаемых имен пунктов в контекстном меню.
Получился твик добавляющий возможность массового открытия выделенных в папке дампов как в консоли так и в дебаггере с фильтрацией «мусора» и создания логов для каждого дампа по необходимости. Экономит довольно много времени.
После «причёсывания» реестра экспортировал всё в итоговый REG файл готовый для применения.
На этом всё. Теперь можно быстро, хоть и поверхностно, проанализировать сразу пачку дампов.