Windows server 2008 minidump

When it comes to troubleshooting spontaneous reboots on Server Core we need to make sure that we have some sort of memory dump file.

In some cases we saw dump files such as when we were initially dealing with the CLOCK WATCHDOG TIMEOUT (blog post) issue. But that has not been consistent.

So, to set the Server Core installation to create a MiniDump file we do the following:

• wmic RECOVEROS set DebugInfoType = 3

Some further reading:

• TechNet: Configure memory dump files for Server Core installation options of Windows Server 2008
• Step 3
• Microsoft KB 254649: Overview of memory dump file options for Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2
• Microsoft KB 244139: Windows feature lets you generate a memory dump file by using the keyboard

We use the Crash Analyzer for MSDaRT Tool included in the Microsoft Desktop Optimization Pack to work with the dump files.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

В момент критического сбоя операционная система 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 вам будет достаточно малого дампа памяти.

Картинка с сайта: winitpro.ru

Теперь при возникновении 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». Скачать можно здесь.

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

Картинка с сайта: winitpro.ru

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

Картинка с сайта: winitpro.ru

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

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

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

1. Откройте командную строку от имени администратора и выполните команды для 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
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.

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

Картинка с сайта: winitpro.ru

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 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)

Картинка с сайта: winitpro.ru

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Например:

Image path: \SystemRoot\system32\drivers\cmudaxp.sys
Image name: cmudaxp.sys

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

This is a tutorial on how to set up and read your minidump files when you receive a BSOD (blue screen of death) in the attempts to gain further insight as to the cause of the problem. First thing is first. Download the latest debugging tools from the Microsoft site. Search for “debugging tools microsoft” in Google.

Then go to Start/Start Search. Type i
the command <i>cmd</i>.

Then change directories to:

C:Program FilesDebugging Tools for Windows (x86)

by using the command:

cd c:program filesdebugging tools for windows (x86)

It’s case insensitive when using the <i>cd</i> command.

Then type in:
windbg.exe -z c:windowsminidumpmini061909-01.dmp -c “!analyze -v”

Your minidump file is located at C:WindowsMinidumpMini062009-01.dmp. It’ll be in the form “MiniMMDDYY-01.dmp”.

KERNEL SYMBOLS ARE WRONG. PLEASE FIX SYMBOLS TO DO ANALYSIS

If somewhere in the output of the Bugcheck Analysis you see an error like:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Then it’s most likely that you are using previous and incompatible symbols or corrupt files or you don’t have the proper symbols at the specified location when the Windbg program was trying to analyze the minidump file. So what I did was open up the Windbg program located at C:Program FilesDebugging Tools for Windows (x86) (in Vista and I believe it’s the same location for XP).

SETTING THE SYMBOL FILE PATH VIA WINDBG COMMAND LINE:

This is an important step so ensure that your symbol path file is set correctly lest you get the kernel symbols are WRONG error or other types of errors. Now set the Symbol File Path (File/Symbol File Path) to:

SRV*e:symbols*http://msdl.microsoft.com/download/symbols

However, for some reason I found that in order to set the Symbol File Path in the “File/Symbol File Path” field you cannot change it directly with the field of “File/Symbol File Path”. So what I found that you need to change it through the Windbg command window by going to:

“View/Command”

In the bottom of the command window beside the “kd>” prompt type this in:

.sympath SRV*e:symbols*http://msdl.microsoft.com/download/symbols

The part between the two asterisks (*) is where the symbols from Microsoft’s servers will be downloaded to. It’s fairly large (approximately 22MB) so make sure that you have sufficient disk space.

SETTING SYMBOL FILE PATH IN THE ENVIRONMENT VARIABLE:

Alternatively, you can set it in your environment variable either in your system or user environment variable. To do this, click the WINDOWS KEY+e. The WINDOWS KEY is the key to the right of the LEFT CTRL key of the keyboard. This will open up Windows Explorer.

Then click on the “Advanced system settings” at the top left of the window. This step applies to Vista only. For XP users, simply click on the Advanced tab.

Then click on the button “Environment variable” at the bottom of the window.

Then click on the “New” button under System Variables. Again you can create the environment as a user environment variable instead.

In the “Variable Name” type:
_NT_SYMBOL_PATH

In the “Variable Value” type:
symsrv*symsrv.dll*e:symbols*http://msdl.microsoft.com/download/symbols

If you set the symbol file path as a system environment variable I believe you may have to reboot your computer in order for it to take effect.

OUTPUT OF WINDBG COMMAND

So the following is the output for my crash:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [c:windowsminidumpmini062609-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*e:symbols*http://msdl.microsoft.com/download/symbols;I:symbols
Executable search path is:
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 6001.18226.x86fre.vistasp1_gdr.090302-1506
Machine Name:
Kernel base = 0x8201d000 PsLoadedModuleList = 0x82134c70
Debug session time: Fri Jun 26 16:25:11.288 2009 (GMT-7)
System Uptime: 0 days 21:39:36.148
Loading Kernel Symbols
………………………………………………………
……………………………………………………….
…………………………………………………..
Loading User Symbols
Loading unloaded module list
……………………….
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8cb5bcc0, 1b, 1, 820d0c1f}

Unable to load image SystemRootsystem32DRIVERSSymIMv.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for SymIMv.sys
*** ERROR: Module load completed but symbols could not be loaded for SymIMv.sys
Unable to load image SystemRootsystem32DRIVERSNETw3v32.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for NETw3v32.sys
*** ERROR: Module load completed but symbols could not be loaded for NETw3v32.sys
Processing initial command ‘!analyze -v’
Probably caused by : tdx.sys ( tdx!TdxMessageTlRequestComplete+94 )

Followup: MachineOwner
———

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 8cb5bcc0, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 820d0c1f, address which referenced memory

Debugging Details:
——————

WRITE_ADDRESS: GetPointerFromAddress: unable to read from 82154868
Unable to read MiSystemVaType memory at 82134420
8cb5bcc0

CURRENT_IRQL:  1b

FAULTING_IP:
nt!KiUnwaitThread+19
820d0c1f 890a            mov     dword ptr [edx],ecx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

TRAP_FRAME:  821126c4 — (.trap 0xffffffff821126c4)
ErrCode = 00000
002
eax=85c5d4d8 ebx=00000000 ecx=8cb5bcc0 edx=8cb5bcc0 esi=85c5d420 edi=ed9c7048
eip=820d0c1f esp=82112738 ebp=8211274c iopl=0         nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010206
nt!KiUnwaitThread+0×19:
820d0c1f 890a            mov     dword ptr [edx],ecx  ds:0023:8cb5bcc0=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 820d0c1f to 82077d24

STACK_TEXT:
821126c4 820d0c1f badb0d00 8cb5bcc0 87952ed0 nt!KiTrap0E+0x2ac
8211274c 8205f486 00000002 85c5d420 ed9c7048 nt!KiUnwaitThread+0×19
82112770 8205f52a ed9c7048 ed9c7008 00000000 nt!KiInsertQueueApc+0x2a0
82112790 8205742b ed9c7048 00000000 00000000 nt!KeInsertQueueApc+0x4b
821127c8 8f989cd0 e79e1e88 e79e1f70 00000000 nt!IopfCompleteRequest+0×438
821127e0 8a869ce7 00000007 00000000 00000007 tdx!TdxMessageTlRequestComplete+0×94
82112804 8a869d33 e79e1f70 e79e1e88 00000000 tcpip!UdpEndSendMessages+0xfa
8211281c 8a560c7f e79e1e88 00000001 00000000 tcpip!UdpSendMessagesDatagramsComplete+0×22
8211284c 8a86e0ab 00000000 00000000 889a0558 NETIO!NetioDereferenceNetBufferListChain+0xcf
82112860 8a6d341e 878689e8 e79e1e88 00000000 tcpip!FlSendNetBufferListChainComplete+0x1c
82112894 8a6084f1 86c440e8 e79e1e88 00000000 NDIS!ndisMSendCompleteNetBufferListsInternal+0xb8
821128a8 8fe3f0ee 87a092b0 e79e1e88 00000000 NDIS!NdisFSendNetBufferListsComplete+0x1a
821128cc 8a6084f1 87a07230 e79e1e88 00000000 pacer!PcFilterSendNetBufferListsComplete+0xba
821128e0 8fe516f7 88940c10 e79e1e88 00000000 NDIS!NdisFSendNetBufferListsComplete+0x1a
WARNING: Stack unwind information not available. Following frames may be

Server 2008 R2 crashed