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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Collecting User-Mode Dumps

Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature.

This feature is not enabled by default. Enabling the feature requires administrator privileges. To enable and configure the feature, use the following registry values under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps key.

Value	Description	Type	Default value
DumpFolder	The path where the dump files are to be stored. If you do not use the default path, then make sure that the folder contains ACLs that allow the crashing process to write data to the folder. For service crashes, the dump is written to service specific profile folders depending on the service account used. For example, the profile folder for System services is %WINDIR%\System32\Config\SystemProfile. For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.	REG_EXPAND_SZ	%LOCALAPPDATA%\CrashDumps
DumpCount	The maximum number of dump files in the folder. When the maximum value is exceeded, the oldest dump file in the folder will be replaced with the new dump file.	REG_DWORD	10
DumpType	Specify one of the following dump types: 0: Custom dump 1: Mini dump 2: Full dump	REG_DWORD	1
CustomDumpFlags	The custom dump options to be used. This value is used only when DumpType is set to 0. The options are a bitwise combination of the MINIDUMP_TYPE enumeration values.	REG_DWORD	MiniDumpWithDataSegs | MiniDumpWithUnloadedModules | MiniDumpWithProcessThreadData.

These registry values represent the global settings. You can also provide per-application settings that override the global settings. To create a per-application setting, create a new key for your application under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps (for example, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApplication.exe). Add your dump settings under the MyApplication.exe key. If your application crashes, WER will first read the global settings, and then will override any of the settings with your application-specific settings.

After an application crashes and prior to its termination, the system will check the registry settings to determine whether a local dump is to be collected. After the dump collection has completed, the application will be allowed to terminate normally. If the application supports recovery, the local dump is collected before the recovery callback is called.

These dumps are configured and controlled independently of the rest of the WER infrastructure. You can make use of the local dump collection even if WER is disabled or if the user cancels WER reporting. The local dump can be different than the dump sent to Microsoft.

User-Mode Dump Files

This section includes:

For information on analyzing a dump file, see Analyzing a User-Mode Dump File.

Varieties of User-Mode Dump Files

There are several kinds of user-mode crash dump files, but they are divided into two categories:

The difference between these dump files is one of size. Minidumps are usually more compact, and can be easily sent to an analyst.

NoteВ В Much information can be obtained by analyzing a dump file. However, no dump file can provide as much information as actually debugging the crash directly with a debugger.

Full User-Mode Dumps

A full user-mode dump is the basic user-mode dump file.

This dump file includes the entire memory space of a process, the program’s executable image itself, the handle table, and other information that will be useful to the debugger in reconstructing the memory that was in use when the dump occurred.

It is possible to «shrink» a full user-mode dump file into a minidump. Simply load the dump file into the debugger and then use the .dump (Create Dump File) command to save a new dump file in minidump format.

NoteВ В Despite their names, the largest «minidump» file actually contains more information than the full user-mode dump. For example, .dump /mf or .dump /ma will create a larger and more complete file than .dump /f.

In user mode, .dump /m[MiniOptions] is the best choice. The dump files created with this switch can vary in size from very small to very large. By specifying the proper MiniOptions you can control exactly what information is included.

Minidumps

A user-mode dump file that includes only selected parts of the memory associated with a process is called a minidump.

The size and contents of a minidump file vary depending on the program being dumped and the application doing the dumping. Sometimes, a minidump file is fairly large and includes the full memory and handle table. Other times, it is much smaller — for example, it might only contain information about a single thread, or only contain information about modules that are actually referenced in the stack.

The name «minidump» is misleading, because the largest minidump files actually contain more information than the «full» user-mode dump. For example, .dump /mf or .dump /ma will create a larger and more complete file than .dump /f. For this reason, .dump /m[MiniOptions] recommended over .dump /f for all user-mode dump file creation.

If you are creating a minidump file with the debugger, you can choose exactly what information to include. A simple .dump /m command will include basic information about the loaded modules that make up the target process, thread information, and stack information. This can be modified by using any of the following options:

/ma

Creates a minidump with all optional additions. The /ma option is equivalent to /mfFhut — it adds full memory data, handle data, unloaded module information, basic memory information, and thread time information to the minidump.

/mf

Adds full memory data to the minidump. All accessible committed pages owned by the target application will be included.

/mF

Adds all basic memory information to the minidump. This adds a stream to the minidump that contains all basic memory information, not just information about valid memory. This allows the debugger to reconstruct the complete virtual memory layout of the process when the minidump is being debugged.

/mh

Adds data about the handles associated with the target application to the minidump.

/mu

Adds unloaded module information to the minidump. This is only available in Windows Server 2003 and later versions of Windows.

/mt

Adds additional thread information to the minidump. This includes thread times, which can be displayed by using .ttime (Display Thread Times) when debugging the minidump.

/mi

Adds secondary memory to the minidump. Secondary memory is any memory referenced by a pointer on the stack or backing store, plus a small region surrounding this address.

/mp

Adds process environment block (PEB) and thread environment block (TEB) data to the minidump. This can be useful if you need access to Windows system information regarding the application’s processes and threads.

/mw

Adds all committed read-write private pages to the minidump.

/md

Adds all read-write data segments within the executable image to the minidump.

/mc

Adds code sections within images.

/mr

Deletes from the minidump those portions of the stack and store memory that are not useful for recreating the stack trace. Local variables and other data type values are deleted as well. This option does not make the minidump smaller (since these memory sections are simply zeroed), but it is useful if you wish to protect the privacy of other applications.

/mR

Deletes the full module paths from the minidump. Only the module names will be included. This is a useful option if you wish to protect the privacy of the user’s directory structure.

/mk « FileName «

(Windows Vista only) Creates a kernel-mode minidump in addition to the user-mode minidump. The kernel-mode minidump will be restricted to the same threads that are stored in the user-mode minidump. FileName must be enclosed in quotation marks.

These options can be combined. For example, the command .dump /mfiu can be used to create a fairly large minidump, or the command .dump /mrR can be used to create a minidump that preserves the user’s privacy. For full syntax details, see .dump (Create Dump File).

Creating a User-Mode Dump File

There are several different tools that can be used to create a user-mode dump file: CDB, WinDbg and Procdump.

ProcDump

ProcDump is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike. ProcDump also includes hung window monitoring (using the same definition of a window hang that Windows and Task Manager use), unhandled exception monitoring and can generate dumps based on the values of system performance counters. It also can serve as a general process dump utility that you can embed in other scripts.

For information about creating a user-mode dump file using the Sysinternals ProcDump utility, see ProcDump.

CDB and WinDbg

CDB and WinDbg can create user-mode dump files in a variety of ways.

Creating a Dump File Automatically

When an application error occurs, Windows can respond in several different ways, depending on the postmortem debugging settings. If these settings instruct a debugging tool to create a dump file, a user-mode memory dump file will be created. For more information, see Enabling Postmortem Debugging.

Creating Dump Files While Debugging

When CDB or WinDbg is debugging a user-mode application, you can also use the .dump (Create Dump File) command to create a dump file.

This command does not cause the target application to terminate. By selecting the proper command options, you can create a minidump file that contains exactly the amount of information you wish.

Shrinking an Existing Dump File

CDB and WinDbg can also be used to shrink a dump file. To do this, begin debugging an existing dump file, and then use the .dump command to create a dump file of smaller size.

Time Travel Debugging (TTD)

In addition to CDB, WinDbg and Procdump, another option to debug user mode applications is Time Travel Debugging (TTD). Time Travel Debugging, is a tool that allows you to record an execution of your process running, then replay it later both forwards and backwards. Time Travel Debugging (TTD) can help you debug issues easier by letting you «rewind» your debugger session, instead of having to reproduce the issue until you find the bug.

TTD allows you to go back in time to better understand the conditions that lead up to the bug and replay it multiple times to learn how best to fix the problem.

TTD can have advantages over crash dump files, which often are missing the code execution that led up to the ultimate failure.

For more information on Time Travel Debugging (TTD), see Time Travel Debugging — Overview.

.dump option	Effect on dump file