Как прочитать дамп памяти windows 11

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

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

Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

• Мини дамп памяти (Small memory dump) (256 КБ). Этот тип файла включает минимальный объем информации. Он содержит только сообщение об ошибке BSOD, информацию о драйверах, процессах, которые были активны в момент сбоя, а также какой процесс или поток ядра вызвал сбой.
• Дамп памяти ядра (Kernel memory dump). Как правило, небольшой по размеру — одна треть объема физической памяти. Дамп памяти ядра является более подробным, чем мини дамп. Он содержит информацию о драйверах и программах в режиме ядра, включает память, выделенную ядру Windows и аппаратному уровню абстракции (HAL), а также память, выделенную драйверам и другим программам в режиме ядра.
• Полный дамп памяти (Complete memory dump). Самый большой по объему и требует памяти, равной оперативной памяти вашей системы плюс 1MB, необходимый Windows для создания этого файла.
• Автоматический дамп памяти (Automatic memory dump). Соответствует дампу памяти ядра с точки зрения информации. Отличается только тем, сколько места он использует для создания файла дампа. Этот тип файлов не существовал в Windows 7. Он был добавлен в Windows 8.
• Активный дамп памяти (Active memory dump). Этот тип отсеивает элементы, которые не могут определить причину сбоя системы. Это было добавлено в Windows 10 и особенно полезно, если вы используете виртуальную машину, или если ваша система является хостом Hyper-V.

Как включить создание дампа памяти в 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 МБ.

WinDBG для Windows7 и более ранних систем включен в состав пакета «Microsoft Windows SDK for Windows 7 and .NET Framework 4». Скачать можно здесь.

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

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации .dmp файлов с WinDBG

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

1. Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы:
   cd C:Program Files (x86)Windows Kits10Debuggersx64
windbg.exe –IA
   
   для 32-разрядной системы:
   C:Program Files (x86)Windows Kits10Debuggersx86
windbg.exe –IA
2. В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.

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

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

• Откройте WinDBG;
• Перейдите в меню File –> Symbol File Path;
• Пропишите строку, содержащую URL для загрузки символов отладки с сайта Microsoft и папку для сохранения кэша:
  SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols
  В примере кэш загружается в папку E:Sym_WinDBG, можете указать любую.
• Не забывайте сохранить изменения в меню File –> Save WorkSpace;

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

SRV*E:Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:Symbols

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.

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

Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.

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

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.

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

Отладчик предлагает выполнить команду !analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?

• Она выполняет предварительный анализ дампа памяти и предоставляет подробную информацию для начала анализа.
• Эта команда отобразит STOP-код и символическое имя ошибки.
• Она показывает стек вызовов команд, которые привели к аварийному завершению.
• Кроме того, здесь отображаются неисправности IP-адреса, процессов и регистров.
• Команда может предоставить готовые рекомендации по решению проблемы.

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !analyze –v (листинг неполный).

1: kd>
!analyze -v

*****************************************************************************
* *
* 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:
------------------

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

CUSTOMER_CRASH_COUNT: 1

Основная категория текущего сбоя:

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Код STOP-ошибки в сокращенном формате:

BUGCHECK_STR: 0x139

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

PROCESS_NAME: sqlservr.exe

CURRENT_IRQL: 2

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9 : 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528 : nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50 : ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2 : nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482 : ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9 : nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d : 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951 : nt! ?? ::FNODOBFM::`string'+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac : 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600 : nt!IopSynchronousServiceTail+0x379
ffffd000`3a20d990 fffff804`0117d313 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380 : nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
000000ee`f25ed2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`475307da

Участок кода, где возникла ошибка:

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:ProgramDatadbgsymntoskrnl.exe5A9A2147787000ntoskrnl.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: SystemRootsystem32driverscmudaxp.sys
Image name: cmudaxp.sys

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

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

В Windows существуют два типа дампа памяти — малый дамп (minidump) и полный дамп.
Minidump находится в директории C:WindowsMinidump и его название имеет примерно такой вид 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 при помощи утилиты 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 и вставляем строку:

SRV*C:symbol_cache*http://msdl.microsoft.com/download/symbols

где 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.

IMAGE_NAME:  srv.sys
MODULE_NAME: srv

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

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

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

Обновлено 16.10.2016

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

Далее идем в пункт Дополнительные параметры системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Видим, что 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для чего нужен дамп памяти Windows

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

Тип записываемого дампа может задаваться в свойствах ОС, поддерживаются варианты:

1. Малый дамп памяти. Включает немного сведений, в частности это код ошибки с параметрами, список установленных в Виндовс драйверов и т. д., но этой информации бывает достаточно для выявления источника проблемы. Элемент, как правило, будет записан в каталоге C:WindowsMinidump.
2. Дамп памяти ядра. Выполняется сохранение сведений оперативной памяти, связанных только с режимом ядра, исключая информацию, не указывающую на источник появления сбоя.
3. Полный дамп системы. Содержимым является вся память операционки, что может создать проблемы при создании снимка, если объём ОЗУ составляет более 4Гб. Обычно пишется в файл C:WindowsMEMORY.DMP.
4. Автоматический дамп памяти (стал доступным с восьмой версии Виндовс). Содержит те же записи, что и memory dump ядра, при этом отличается способом управления системой размером файла подкачки.
5. Активный дамп памяти (представлен в «Десятке»). Содержит только активную память хоста из режимов ядра и пользователя* (возможность была изначально реализована для серверов, чтобы при диагностике в дамп не попадали виртуальные машины).

*Дамп пользовательского режима представляет собой дамп определённого процесса. Так, содержимым может являться полная память процесса или фрагмент, список, стек, состояние потоков, списки библиотек, состояние потоков, дескрипторы объектов ядра.

Чаще всего аварийный дамп памяти Windows 7, 8, 10 используется в целях диагностики и позволяет выяснить, как исправить критическую ошибку. Проанализировав содержимое, можно понять, что стало причиной неполадки, и приступить к её устранению.

ВАЖНО. При отказе диска или возникновении BSoD на первой стадии запуска системы аварийный дамп создан не будет.

Как включить создание дампа памяти в Windows

Чтобы активировать автоматическое сохранение memory dump в Виндовс, нужно сделать следующее:

1. Переходим к свойствам системы любым удобным способом. Например, жмём правой кнопкой мыши по значку «Мой компьютер» (или «Этот компьютер» на «Десятке»). Выбираем «Свойства», затем в перечне опций в левой колонке жмём «Дополнительные параметры системы». Альтернативный вариант – использование Панели управления, где следует перейти в раздел «Система» (то же окно появится при использовании клавиш Win+Pause), а затем в «Дополнительные параметры системы». В Виндовс 10 также можно применить оснастку «Параметры»(Win+I). В окне нужно перейти к разделу «Система – «О системе» – «Сведения о системе» и далее в дополнительные параметры ОС.
2. В открывшемся окне на вкладке «Дополнительно» в области «Загрузка и восстановление» жмём «Параметры».
3. В итоге манипуляций откроется следующее окно, где следует выбрать тип записи отладочной информации, задать параметры, проставив в нужных пунктах галочки, после чего нажать кнопку «ОК».

Как настроить дамп памяти в Windows

Настройки действий, производимых при аварийной остановке работы ОС, выполняются в том же окне, что и включение создания memory dump («Загрузка и восстановление»), куда мы попадаем из свойств системы.

Здесь можно настроить параметры запуска ОС и назначить определённые действия в случае её отказа, например:

• указать режим записи дампа со сведениями отладки (по умолчанию выбран автоматический, но может быть выставлено значение «Нет»);
• записать события в журнал (записи добавляются в логи);
• отмеченный пункт «Выполнить автоматическую перезагрузку» позволяет системе перезагрузиться после сбоя и продолжить функционировать;
• при выборе опции «Заменять существующий файл дампа», объект будет подвергаться перезаписи при каждой появляющейся ошибке.

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

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

Прочитать memory dump можно посредством специализированных утилит, таких как Microsoft Kernel Debugger, BlueScreenView и других.

Установка WinDbg в Windows

Утилита, являющаяся отладчиком для юзермодных приложений и драйверов, позволяет проанализировать снимок памяти и выяснить, что спровоцировало BSoD. Поставляется она в составе пакета SDK для Windows 10, инсталлятор скачивается на сайте Microsoft. Для Семёрки и ранних версий систем WinDbg можно найти в пакете Microsoft Windows SDK for Windows 7 and NET Framework 4.

Устанавливаем WinDbg:

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

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

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

Ассоциирование файлов .dmp с WinDbg

Для того чтобы объекты при нажатии на них открывались посредством утилиты:

1. В консоли командной строки, запущенной от имени администратора (например, через меню Пуск) выполняем команды (зависимо от разрядности ОС):
   

   cd C:Progran Files (x86)Windows Kits10Debuggersx64
   exe –IA

2. Или (для 32-разрядной Виндовс):
   

   cd C:Progran Files (x86)Windows Kits10Debuggersx86
   exe –IA

Теперь файлы типов .DMP, .HDMP, .MDMP, .KDMP, .WEW будут ассоциироваться с приложением.

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

Отладочные символы, которые генерируются в процессе компиляции приложения вместе с исполняемым файлом, нужны при отладке. Настраиваем WinDbg на извлечение символов из сети:

• в окне WinDbg жмём «File» и выбираем «Symbol Fie Path…» или жмём Ctrl+S;
• указываем путь для загрузки, прописав строчку:
  

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

  

• применяем корректировки нажатием «File» – «Save Workspace».

Анализ memory dump в WinDbg

Чтобы перейти к процедуре, открываем объект в утилите (File – Open Crash Dump) или, если предварительно настраивались ассоциации файлов, открываем элемент щелчком мыши. Утилита начнёт анализировать файл, затем выдаст результат.

В окне предполагается ввод команд. Запрос «!analyze –v» позволит получить более детальные сведения о сбое (STOP-код, имя ошибки, стек вызовов команд, приведших к проблеме и другие данные), а также рекомендации по исправлению. Для остановки отладчика в меню программы жмём «Debug» – «Stop Debugging».

Как удалить файлы дампа памяти

Если понадобилось удалить memory dump, это можно выполнить вручную, пройдя по пути месторасположения объекта на диске. Так, в системном каталоге Windows нужно найти и удалить файл MEMORY.DMP, а также элементы в каталоге Minidump. Кроме того, можно использовать штатный инструмент системы «Очистка диска»:

• вызываем консоль «Выполнить» (Win+R) и вводим команду «Cleanmgr», чтобы перейти к службе;
• жмём кнопку очищения системных файлов, затем находим и отмечаем в списке строчки, касающиеся memory dump. Если не нашлось, значит, их не создавали.

Создание снимков бывает отключено, даже если вы когда-либо активировали эту функцию по причине деятельности специального софта. Если речь о SSD-накопителе, это могут быть программы для работы с твердотельными дисками. Отключение некоторых опций ОС выполняется ими с целью оптимизации работы, поскольку многократные процессы чтения/записи сокращают продолжительность жизни диска. Также причиной отключения дампа памяти могут быть различные программы очистки компьютера и оптимизации системы.

Если вам понравилась эта статья, то пожалуйста, оцените её и поделитесь ею со своими друзьями на своей странице в социальной сети.

(7 оценок, среднее: 5,00 из 5)

Загрузка…

There are few things more frustrating than persistent blue screens or crashes that you are unable to identify the cause of. To aid in this type of troubleshooting, Microsoft offers the Windows 10/Windows 11 memory dump feature. Today, we’re going to show you how to do a complete memory dump in Windows 11 or Windows 10 today so you can get the root of your issues.

What are Windows system memory dump/crash dump files?

A Windows 10/Windows 11 memory dump is a copy of your computer’s memory at the time of a crash. It’s because of this that you may have heard to them referred to as Windows 10 or Windows 11 crash dumps.

Though it isn’t widely discussed, there are actually three types of memory dump in Windows 11 and Windows 10: a complete memory dump, a kernel memory dump, and a small memory dump.

A small memory dump comes in at just 256kb, and contains only the barebones information about the crash. Information such as the error code, a list of loaded drives, and some kernel information.

The kernel memory dump is about one-third of the size of your system’s physical memory. It contains only memory related to the Windows kernel and hardware extraction level, as well as memory allocated to kernel-mode drivers and programs.

In most cases, the kernel memory dump will give everything you need. In some cases, however, you may need the final type: a complete memory dump. A complete memory dump will create a copy of all the information in your computer’s memory at the time of the crash. So, if you’re using 16GB of RAM, that will be a 16 GB file. In some cases, this can be used to better diagnose the source of the issue.

Here’s how to generate a complete memory dump in Windows 11 / Windows 10:

How to Configure BSOD Dump Files in Windows 11 and Windows 10

If you’d like to find out more about Windows memory dumps, you can read our full guide on how to configure BSOD Dump Files in Windows 11 or Windows 10. This will better walk you through all the options and provide you with additional methods to enable them.

How to Use Reliability Monitor to Analyze System Crashes and Freezes in Windows 11 / Windows 10

If you don’t feel technically proficient enough to go trawling through crash dumps for an issue, you can try Reliability Monitor instead. Reliability Monitor is a great tool that displays all the important software events on your system. If your crash has its roots in a software issue, our Windows 10 / Windows 11 Reliability Monitor guide will help you find it.

Время прочтения
8 мин

Просмотры 13K

Многие пользователи операционных систем windows рано или поздно сталкиваются с необходимостью выяснить почему же любимая операционка «падает в бсод».

О том что это, как искать причину и как её (в зависимости от ситуации) устранять в интернете написано уже немало, но что делать, если нужно выяснить причину максимально быстро и делать это приходится регулярно как, например, работникам сервисов или завсегдатаям компьютерных форумов?

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

msiexec /a "D:DesktopX64 Debuggers And Tools-x64_en-us.msi" /qb targetdir="D:DesktopTemp"

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

Разбираемся с ключами и командами дебаггера

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

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

@echo off
title text %1
mode con: cols=170
color F0
title "%1"

kd.exe -nosqm -sup -z "%1" ^
-y srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -c ^
"!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q""

pause
exit /b

Тут можно увидеть параметры передаваемые kd.exe, такие как -y, -i и, собственно, -z, которые видели все, кто знает о широко известном в узких кругах kdfe.cmd.

-i !ImagePath! specifies the location of the executables that generated the
               fault (see _NT_EXECUTABLE_IMAGE_PATH)
-y !SymbolsPath! specifies the symbol search path (see _NT_SYMBOL_PATH)
-z !CrashDmpFile! specifies the name of a crash dump file to debug

Если брать по аналогии с распространенными инструкциями то тут есть небольшие отличия: в качестве аргументов дополнительно переданы -nosqm и -sup.

-nosqm disables SQM data collection/upload.
-sup enables full public symbol searches

В качестве команд:

!cpuid
!sysinfo cpuinfo
!sysinfo cpuspeed
!sysinfo machineid

Расписывать их не буду, так-как выйдет слишком много копипасты. Кому интересно смогут найти подробнейшую справку debugger.chm в любом из двух *.msi о которых говорилось выше или на docs.microsoft.com -cpuid -sysinfo. Если вкратце — базовая информация о железе пострадавшего.

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

Фильтрация мусорного вывода из консоли

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

Такое встречается, например, в дампах юзеров использующих активатор odin, что мы и видим в данном примере.

Полный вывод довольно массивный, потому ссылкой на pastebin.

Требуется «отфильтровать» ненужные строки оставив только полезную информацию.
Я использовал findstr, получилось вот такое некрасивое но работающее решение:

findstr /r /v /c:"^*** .* ***" /c:"^**************.*"

Тут findstr использует две регулярки: одна ищет строки начинающиеся с трех звездочек, одного пробела и заканчивающиеся на пробел и три звездочки. Вторая ищет строки начинающиеся с 14-ти звездочек. Ничего более вразумительного средствами findstr я сделать не смог.

(Использовать символы окончания строк в регулярках findstr на выхлопе kd.exe не рекомендую, могут быть проблемы с видом окончания строк выводимого kd.exe. Вместо

rn можно получить n, который findstr не считает окончанием строки.Такие себе грабли.)

Весь код предварительного батника с «фильтром» получился такой:

@echo off
title text %1
mode con: cols=170
color F0
title "%1"

kd.exe -nosqm -sup -z "%1" ^
-y srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols ^
-c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^*** .* ***" /c:"^**************.*"

pause
exit /b

Полный вывод отфильтрованного варианта также на pastebin.

Результат аналогичный, но без «мусора». 290 строк текста против 894-х. Уже лучше, но еще не всё.

Быстрое создание лога работы дебаггера

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

Для этого нужно передать kd.exe аргумент -loga <«П:уть клогу.log»>
Код принимает следующий вид:

@echo off
title text %1
mode con: cols=170
color F0
title "%1"

set "D=%1"
set L=%D:.dmp=.LOG%

kd.exe -nosqm -sup -loga "%L%" -z "%D%" ^
-y srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols ^
-c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^*** .* ***" /c:"^**************.*"

pause
exit /b

Для файла 102516-21949-01.dmp будет сформирован лог 102516-21949-01.LOG в той же папке, что и сам дамп.

В данном случае вывод «мусора» в лог не фильтруется, фильтруется только вывод в консоль, но в моем случае это не принципиально, хотя можно исправить и это очистив лог уже после создания:

@echo off
title text %1
mode con: cols=170
color F0
title "%1"

set "D=%1"
set L=%D:.dmp=.LOG%

kd.exe -nosqm -sup -loga "%L%" -z "%D%" ^
-y srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols ^
-c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^*** .* ***" /c:"^**************.*"

set CL=%L:.LOG=_CLEAN.LOG%
type "%L%" | findstr /r /v /c:"^*** .* ***" /c:"^**************.*" >> "%CL%"
del /f /q "%L%"

pause
exit /b

Открытие дампа в windbg

Теперь последний по порядку, но не по значимости шаг: нужна возможность передать дамп непосредственно в windbg.exe и сразу же передать ему команды, которые с большой долей вероятности понадобится вводить. Все делается по аналогии с kd.exe, аргументы и команды принимаемые windbg.exe практически идентичны kd.exe

@echo off

windbg.exe -z "%1" -sup -y ^
"srv*C:Symbols*http://msdl.microsoft.com/download/symbols" -i "srv*C:Symbols*http://msdl.microsoft.com/download/symbols" -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid"

exit /b

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

Вывод аналогичный самому первому варианту с той разницей, что дамп открыт сразу в windbg, есть возможность вводить команды для дальнейшего анализа из-за отсутствия в передаваемом списке команд команды q.

(К слову если в предыдущих вариантах скрипта с kd.exe убрать команду q передаваемую в списке команд через аргумент -c, то возможность продолжить работу с дампом появится и там, в том числе с записью лога прямо в процессе.)

Создание твика

Теперь всё это нужно видоизменить, чтобы можно было прикрутить к контекстному меню *.dmp файлов. Собственно, ради чего это и затевалось.

Получились вот такие «однострочники»:

Для варианта с фильтрацией вывода консоли

cmd /d /k mode con: cols=170 & color F0 & title "%1" & kd.exe -nosqm -sup -z "%1" -y srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^*** .* ***" /c:"^**************.*"

Для варианта с фильтрацией вывода консоли и с созданием логфайла
(пришлось использовать отложенное расширение переменных)

cmd /d /v /k mode con: cols=170 & color F0 & title "%1" & set "D=%1"& set L=!D:.dmp=.LOG! & kd.exe -nosqm -sup -loga "!L!" -z "!D!" -y srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:Symbols"*http://msdl.microsoft.com/download/symbols -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^*** .* ***" /c:"^**************.*"

Для открытия дампа непосредственно в windbg.exe

"C:PortableDebugwindbg.exe" -z "%1" -sup -y "srv*C:Symbols*http://msdl.microsoft.com/download/symbols" -i "srv*C:Symbols*http://msdl.microsoft.com/download/symbols" -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid"

В реестре создал следующую структуру разделов:

Был создан отдельный тип файла dmp_geek в разделы реестра которого и вносились изменения. Файлы с расширением *.dmp были назначены файлами типа dmp_geek.

В каждом разделе command в строковый параметр по умолчанию были внесены соответствующие однострочники + красивости в виде иконок и удобных имен отображаемых имен пунктов в контекстном меню.

Получился твик добавляющий возможность массового открытия выделенных в папке дампов как в консоли так и в дебаггере с фильтрацией «мусора» и создания логов для каждого дампа по необходимости. Экономит довольно много времени.

После «причёсывания» реестра экспортировал всё в итоговый REG файл готовый для применения.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT.dmp]
@="dmp_geek"

[HKEY_CLASSES_ROOTdmp_geek]
@="dmp_geek"
"FriendlyTypeName"="Дамп памяти"

[HKEY_CLASSES_ROOTdmp_geekDefaultIcon]
@="imageres.dll,142"

[HKEY_CLASSES_ROOTdmp_geekshell]

[HKEY_CLASSES_ROOTdmp_geekshellkd.exe]
"MUIVerb"="Kd.exe"
"Icon"="C:\Portable\Debug\windbg.exe,6"

[HKEY_CLASSES_ROOTdmp_geekshellkd.execommand]
@="cmd /d /k mode con: cols=170 & color F0 & title "%1" & "C:\Portable\Debug\kd.exe" -nosqm -sup -z "%1" -y srv*"C:\Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:\Symbols"*http://msdl.microsoft.com/download/symbols -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^\*\*\* .* \*\*\*" /c:"^\*\*\*\*\*\*\*\*\*\*\*\*\*\*.*""

[HKEY_CLASSES_ROOTdmp_geekshellkd.exe_-loga]
"MUIVerb"="Kd.exe -loga"
"Icon"="C:\Portable\Debug\windbg.exe,6"

[HKEY_CLASSES_ROOTdmp_geekshellkd.exe_-logacommand]
@="cmd /d /v /k mode con: cols=170 & color F0 & title "%1" & set "D=%1"& set L=!D:.dmp=.LOG! & "C:\Portable\Debug\kd.exe" -nosqm -sup -loga "!L!" -z "!D!" -y srv*"C:\Symbols"*http://msdl.microsoft.com/download/symbols -i srv*"C:\Symbols"*http://msdl.microsoft.com/download/symbols -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid; q" | findstr /r /v /c:"^\*\*\* .* \*\*\*" /c:"^\*\*\*\*\*\*\*\*\*\*\*\*\*\*.*""

[HKEY_CLASSES_ROOTdmp_geekshellOpen]
"MUIVerb"="Windbg"
"Icon"="C:\Portable\Debug\windbg.exe,6"

[HKEY_CLASSES_ROOTdmp_geekshellOpencommand]
@=""C:\Portable\Debug\windbg.exe" -z "%1" -sup -y "srv*C:\Symbols*http://msdl.microsoft.com/download/symbols" -i "srv*C:\Symbols*http://msdl.microsoft.com/download/symbols" -c "!analyze -v; !cpuid; !sysinfo cpuinfo; !sysinfo cpuspeed; !sysinfo machineid""

→ Скачать с Я.Диска GEEK_DMP.reg

На этом всё. Теперь можно быстро, хоть и поверхностно, проанализировать сразу пачку дампов.