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.

Анализ аварийных дампов 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.

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

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

Crash dump windows error reporting

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I need to configure Windows server 2016 WER or a memory dump for a specific application / executable (*.exe). The applications runs as a service and fails unexpected some times and we want to gather and analyze a memory dump and / or WER information.

We don’t want to configure a default memory dump only for that singele application.

Thank you in advance for your help

Answers

Thanks for your replying.

Have you gone through the link that I provided? It explains clearly. WER do can capture a dump for a specific application.

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.

As for the memory dump, it is usually used for the situation like blue screen, system hang.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

• Edited by cora Zhou Microsoft contingent staff Tuesday, January 15, 2019 6:04 AM
• Marked as answer by Stephan-L Wednesday, January 16, 2019 10:11 AM

All replies

A full memory dump is going to capture the contents of the memory on the system, not just the memory of a particular application. By default, Windows is not generally configured to take a full memory dump because it is rarely needed. https://support.microsoft.com/en-us/help/254649/overview-of-memory-dump-file-options-for-windows provides an overview of memory dumps. Once the dump is captured, you can read the dump to see the information for any application that is using memory.

As to WER, is the application written to write to the event log? If not, you need to talk to the developers to make it write to the event log. That is something that is handled by the application, unless the application does something the operating system does not like, such as reference memory outside its space, in which case it will be reported. But if it is a well-behaved application, but it has not been coded to write to the event log, there is nothing that can be done externally to make it write to the event log. That requires the developers.

How to post crash dumps after Blue Screen of Death in Microsoft community.

[[The article is originally written by ZigZag3143 and has been modified for some more clear instructions and updated accordingly with the newer versions of Windows. All Credits to ZigZag and his team.

Summary

This is a general proce dure on how to find and upload the files we need in order for us to help you repair your computer.

Details

When your computer crashes with a Stop code or widely known as Blue Screen of Death, a file called dump file is written by Windows that contains information about the cause of the crash.

How to find and upload the files to us for analysis.

There are 2 files that will help us find out what caused the crash.

If you cannot boot in normal mode try safe mode. Booting to Safe Mode in Windows 10 is somewhat difficult.

Restart your computer 3 times during the boot screen to boot to Advanced start-up options.

Overclocking Warning

If you are overclocking (pushing the components beyond their design) you should revert to default at least until the crashing is solved. If you dont know what it is you probably are not overclocking.

The procedure for finding and uploading the dump files

Open File Explorer and navigate to C:/Windows/Minidump folder.

Alternatively, Right-Click Start>Run. Type in C:/Windows/Minidump and Press OK.

• Select All files(Ctrl+A) present in the folder (generally have the name DDMMYY-XXXX.dmp) and copy all files (Ctrl+C).
• Make a new folder on the Desktop
• Paste the dump files to the folder on the desktop you just created (Ctrl+V). (When asked for Administrative permissions press continue)

If the minidump folder is not there or empty there may be a larger DMP file located at C:\WINDOWS called MEMORY.DMP which we can also see.

Secondly, do not share more than 6 copies of the dump files or dump files older than a month.

The Procedure for sharing System Information file

1. Right-Click Start>Run. Type in msinfo32 and Press OK.
2. On the new Window that opens, Go to File>Save as>NFO file and save it to the same folder in which the dump files were copied.

As Microsoft community does not have a file uploading service, you need to use a 3rd party File sharing service to share the folder that contains the files we need. You can use Microsoft’s own Onedrive, but we do not have problems if you use Google drive or Mediafire. These 3 are preferred.

Using Onedrive to upload and Share folder

How to Upload Logs/files on Microsoft Community

Using Onedrive to upload the folder that contains .dmp files together with System Information file.

• Open http://onedrive.live.com
• Sign in when prompted.
• Select Upload>Folder
  
• Select the folder present on your desktop that has dump and system information-created earlier. Let it upload.
• Right click the uploaded folder in the Onedrive interface and click share.
• Click get a link in the new popup and copy that link.
  
• Paste the link similar to the above picture in the reply of Microsoft community.

Troubleshooting

If there is no «minidump» folder, or if the folder is empty make sure «minidumps» are enabled .

For dumps to be produced The following should be correct

• Page file must be on the same drive as your operating system
• Page file base allocation size must be greater than installed physical RAM
• Windows Error Reporting (WER) system service should be set to MANUAL
• Set page file to system managed on the OS drive
• Try Setting system crash/recovery options to «kernel memory dump»
• User account control must be running.
• Cleaner applications like Ccleaner delete DMP files so dont run them until you are fixed.
• Defective RAM

Except for the last point, you believe everything is correct, it might be worth looking at the Event viewer logs. How to share Event logs is here.

If you receive the message «Access is denied» or «file not found» when dealing with the DMP files you will need to take ownership of the Minidump folder. See below articles: