При возникновении синих экранов BSoD Windows 11, 10 и другие версии системы создают дамп (снимок состояния) оперативной памяти, содержащий отладочную информацию, которую можно использовать для диагностики и определения причин сбоя. Функция обычно включена по умолчанию, но если дампы памяти не создаются, их можно включить: Как включить создание дампов памяти в Windows.
Подробным анализом дампов памяти занимаются разработчики, но и для рядового пользователя, столкнувшегося с синими экранами в Windows это может оказаться полезным: адреса в памяти ему ничего не дадут, но часто можно обнаружить имя файла приложения или драйвера, вызывающее сбой. Здесь помогут специальные программы для анализа дампов памяти, о которых и пойдёт речь далее.
WinDbg
У Майкрософт имеется собственный инструмент отладки и анализа дампов памяти — WinDbg (пока Preview). Скачать его для Windows 11 и Windows 10 можно из Microsoft Store, используя поиск в магазине приложений или прямую ссылку.
Пример простого анализа дампа памяти для обычного пользователя с целью выявления процесса, вызвавшего BSoD с помощью WinDbg:
- Запустите WinDbg от имени Администратора (правый клик по ярлыку в меню «Пуск» — «Запуск от имени администратора»).
- В главном меню программы выберите «Файл» — «Open dump File» и укажите путь к нужному мини-дампу, обычно находящемуся в папке C:\Windows\Minidump, нажмите кнопку «Open».
- Введите команду
!analyze -v
в поле ввода команд (либо нажмите по ссылке с командой в верхней панели WinDbg) и дождитесь завершения анализа.
- В панели «Command» в верхней части окна программы будет отображен результат анализа, где, при удаче, вы сможете найти информацию о том, каким процессом был инициирован сбой (PROCESS_NAME).
- Может быть информация о файле драйвера (.sys) в поле IMAGE_NAME и другая информация, позволяющая найти источник проблемы.
Далее полученную информацию можно использовать для того, чтобы найти, каким устройствам соответствуют драйверы в Интернете, выяснить назначение процессов вызвавших сбой, предпринять те или иные действия с целью их устранения.
BlueScreenView
BlueScreenView — очень простая утилита, которая позволяет выбрать файла дампа памяти в списке и посмотреть, какие файлы драйвера и процессы привели к сбою: в окне программы они будут выделены красным цветом.
Скачать BlueScreenView можно с официального сайта разработчика https://www.nirsoft.net/utils/blue_screen_view.html
WhoCrashed
Ещё одна программа для анализа дампов памяти — WhoCrashed. В бесплатной версии предоставляет не так много информации.
После нажатия кнопки «Analyze» имеющиеся дампы памяти анализируются, и на вкладке «Report» выводятся коды ошибок, а также текстовое описание на английском языке о том, что означает этот код и о возможных причинах сбоя.
Официальный сайт WhoCrashed https://www.resplendence.com/whocrashed, судя по всему, не открывается из РФ, но утилиту легко найти и скачать из сторонних источников.
В момент критического сбоя операционная система Windows прерывает работу и показывает синий экран смерти (BSOD). Содержимое оперативной памяти и вся информация о возникшей ошибке записывается в файл подкачки. При следующей загрузке Windows создается аварийный дамп c отладочной информацией на основе сохраненных данных. В системном журнале событий создается запись о критической ошибке.
Внимание! Аварийный дамп не создается, если отказала дисковая подсистема или критическая ошибка возникла на начальной стадии загрузки Windows.
Содержание:
- Типы аварийных дампов памяти Windows
- Как включить создание дампа памяти в Windows?
- Установка WinDBG в Windows
- Настройка ассоциации .dmp файлов с WinDBG
- Настройка сервера отладочных символов в WinDBG
- Анализ аварийного дампа памяти в WinDBG
Типы аварийных дампов памяти 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.
- Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы:
cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
windbg.exe –IA
для 32-разрядной системы:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
windbg.exe –IA - В результате типы файлов: .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:\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
Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.
Статья обновлена: 16 октября 2024
ID: 10659
После установки приложения «Лаборатории Касперского» могут возникнуть ситуации, при которых ОС «падает» в синий экран (BSoD — Blue Screen of Death). Это может происходить из-за того, что во время работы приложения возникает конфликт со сторонним ПО или драйверами комплектующих вашего устройства.
Чтобы выяснить причину проблемы, технической поддержке «Лаборатории Касперского» понадобится полный дамп памяти — файл, в который записывается содержимое системной памяти, когда компьютер неожиданно останавливается.
Чтобы получить полный дамп памяти:
- Включите ограничение на объем используемой физической памяти.
- Создайте полный дамп памяти в Windows 7, 8, 8.1, 10 или Windows 11.
- Отправьте полный дамп памяти в техническую поддержку «Лаборатории Касперского».
Как включить ограничение на объем используемой физической памяти
Как создать полный дамп памяти для Windows 7, 8, 8.1, 10
Как создать полный дамп памяти для Windows 11
Что делать, если в списке отсутствует полный дамп памяти
Как отправить дамп в техническую поддержку «Лаборатории Касперского»
Спасибо за ваш отзыв, вы помогаете нам становиться лучше!
Спасибо за ваш отзыв, вы помогаете нам становиться лучше!
On Windows 10, when there is a crash, the system creates a «dump» file containing the memory information at the time of the error, which can help determine the reason for the problem.
The «.dmp» file includes the stop error message, a list of the drivers loaded at the time of the problem, kernel, processor, and process details, as well as other information depending on the type of dump file you have.
Although Windows 10 automatically creates dump files, the only problem is that you won’t find any built-in tools to open this type of file, and this is when the Microsoft Windows Debugging (WinDbg) tool can help. WinDbg is an advanced tool designed for debugging kernel-mode and user-mode code, reviewing processor registries, and analyzing crash dumps.
This guide will walk you through the steps to open a dump file to determine what caused the crash to resolve the problem on your computer.
How to open dump file with WinDbg on Windows 10
On Windows 10, you may find multiple ways to open and review a dump error file, but the easiest way is to use the WinDbg tool available through the Microsoft Store.
Install WinDbg
To install the WinDbg tool on Windows 10, use these steps:
All the latest news, reviews, and guides for Windows and Xbox diehards.
- Open the WinDbg download page.
- Click the Install button.
- Click the Open button.
- Click the Install button.
Once you complete the steps, the application will install, and it will be available through the Start menu.
Analyze dump file
To open and analyze a dump file created by a crash on Windows 10, use these steps:
- Open Start.
- Search for WinDbg, right-click the top result, and select the Run as administrator option.
- Click the File menu.
- Click on Start debugging.
- Select the Open sump file option.
- Select the dump file from the folder location — for example, %SystemRoot%\Minidump.
- Click the Open button.
- Click the Open button again.
- Check the progress bar until it loads the dump file (this may take a while).
- Type the following command in the run command and press Enter: !analyze -v
- Quick tip: You can also click the !analyze -v link if available from the main area if available after loading the dump file.
- Check the progress bar until the analysis is complete (this may take a long time depending on the data size).
After you complete the steps, the application will return the dump file analyses, which you can then review to determine the reason for the problem to help you resolve the issue.
The information will be different depending on the problem. For example, this result points out that this was a manually initiated crash with an «e2» error code, which is correct since, for this guide, we use these instructions to force a dump file. The WinDbg even makes an excellent job describing the crash in a language anyone can understand («The user manually initiated this crash dump»).
As you continue reviewing the dump file, you will also find more information, such as «FAILURE_BUCKET_ID» and «MODULE_NAME,» which could indicate what is causing the problem.
The information can be overwhelming since it is not meant for regular users. If your computer keeps crashing, you can use this tool to get an idea of the problem. If you cannot figure it out, you can use the hints in the report to search online for more information.
More resources
For more helpful articles, coverage, and answers to common questions about Windows 10 and Windows 11, visit the following resources:
- Windows 11 on Windows Central — All you need to know
- Windows 10 on Windows Central — All you need to know
Mauro Huculak has been a Windows How-To Expert contributor for WindowsCentral.com for nearly a decade and has over 15 years of experience writing comprehensive guides. He also has an IT background and has achieved different professional certifications from Microsoft, Cisco, VMware, and CompTIA. He has been recognized as a Microsoft MVP for many years.
Windows 11 (including earlier version), when, encounter a Blue Screen of Death (or BSOD), accumulates all the memory information into a file. Holding Dump file as name it further helps users to identify and debug the cause of the crashes. The files also allow writing the debugging details in different file formats in order to simplify the readability of the data.
Dump file may be of various types depending on the nature of crash and bug check values. These are “Small memory dump (Minidump)”, “Kernel memory dump”, “Complete memory dump”, “Automatic memory dump”, and “Active memory dump”. However, among all these, Windows 10/11 generates Automatic memory dump all by itself as its name suggests. The following section will deal with everything related to Dump File Location Windows 11 or 10.
Dump File Location Windows 10 or 11
Here is the Dump File Location Windows 11 or 10 –
Dump File Location
Instead, you can say Dump file locations so see the following paths to find out the data –
%SystemRoot%memory.dmp which means
C:\Windows\memory.dmp
This is the default location and here, C: refers to the system drive where Windows is installed.
Windows 11/10 can also capture memory dumps that consume a small amount of space. These are created at –
%SystemRoot%Minidump.dmp i.e.,
C:\Window\Minidump.dump
Change Dump File Location Windows 11 or 10
- Go to desktop and right-click on This PC icon. From the available options, choose Properties.
- Click Advanced system settings link that shows up on the top left of the subsequent window.
- Click Settings beneath Startup and Recovery section.
- Locate the Dump File text field and insert the location of the file.
Configure the Type of Memory Dump File
As aforementioned, Windows generates Automatic memory dump files but users can choose to configure the settings as per need. Thankfully, there are certain ways using which a user can change the type of memory dump file that Windows creates.
1]Through Startup and Recovery
- Press “Win logo+R” hotkey to open Run dialog box. System properties wizard will become visible, switch to Advanced tab.
- Here, click Settings just below Startup and Recovery section.
- Click the drop-down under Write debugging information. From the list of dump file types, choose the type that you wish Windows to generate when Windows crashes.
- To apply the changes, click OK.
Note – In case the system crashes a lot, it’s better to deselect the checkbox against the option Overwrite any existing file. Doing this will eventually create incremental dump files that will have a memory dump file for each crash that occurs.
2] Use Elevated Command Prompt
- Fire up taskbar search using Win+S combination of keys. Type in cmd.exe, right-click ok Command Prompt and choose Run as administrator.
- Click Yes on the prompt of UAC to access elevated Command Prompt.
- Once into the black window, insert the applicable command from the list below to change the type of dump file and hit Enter.
| Memory Type | Command Line |
| No memory | wmic RECOVEROS set DebugInfoType = 0 |
| Small memory dump | wmic RECOVEROS set DebugInfoType = 3 |
| Kernel memory dump | wmic RECOVEROS set DebugInfoType = 2 |
| Complete memory dump | wmic RECOVEROS set DebugInfoType = 1 |
| Automatic memory dump | wmic RECOVEROS set DebugInfoType = 7 |
| Active memory dump | wmic RECOVEROS set DebugInfoType = 1 |
- Finally, close the prompt window and Restart Windows 10 PC to make the changes effective.
Note – The Command Prompt also lets you view the current memory dump file. Just open Command Prompt as Administrator and run the following command-line –
wmic RECOVEROS get DebugInfoType
Types of Memory Dump Files
It is important to know the types after finding Dump File Location Windows 11 or 10 –
Small memory dump – It is the type that contains a minimal amount of details. Basically, the file includes the stop code, list of device drivers, parameters. Furthermore, it also contains the current process and informs which kernel thread or process crashed.
Kernel memory dump – This is the most useful and comprehensive one with respect to the kernel. Moreover, this type contains information in connection with programs and drivers in kernel mode. However, the dimension of this dump file completely depends on the amount of kernel-mode memory specified by Windows and drivers. Now, in case a second crash occurs and a kernel memory dump file is generated, the earlier content gets overwritten.
Complete memory dump – A remarkably large file type which is equal to the RAM of the system. It incorporates physical memory allocation that is basically left out in other kernel dumps.
Automatic memory dump – When compared to the kernel memory option, this is quite similar to it in terms of information. The only difference between them is the size of the paging file that Windows sets for them.
Active memory dump – It is comparatively smaller than complete memory dump. This type refines the items that are not influential in spotting the cause of a crash.
That’s all!!!