Какие шаги необходимы для отладки memory.dmp? (прохождение включено)
Я проснулся с этим в моем журнале событий:
The computer has rebooted from a bugcheck.
The bugcheck was: 0x000000ef (0xffffe0018668f080, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 082615-29515-01.
Я использую эту статью MSFT в качестве руководства о том, как ее отладить.
Сначала я ищу значение
0x000000ef
который является критическим процессом умерПопробуйте использовать Visual Studio, как показано в статье, но получите ошибку
debugging older format crash dumps is not supported
Установить WDK 8.1 установить для сервера 2012 R2 под управлением Exchange
Откройте WinDBG, расположенный в: C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64
Установите сервер символов на
srv*c:\cache*http://msdl.microsoft.com/download/symbols;
Откройте файл DMP и получите этот вывод:
Выход
Executable search path is:
Windows 8 Kernel Version 9600 MP (32 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 9600.17936.amd64fre.winblue_ltsb.150715-0840
Machine Name:
Kernel base = 0xfffff801`c307c000 PsLoadedModuleList = 0xfffff801`c33517b0
Debug session time: Wed Aug 26 08:58:08.719 2015 (UTC - 4:00)
System Uptime: 0 days 8:12:03.493
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
................................................................
................................................................
..............................................
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck EF, {ffffe0018668f080, 0, 0, 0}
*** WARNING: Unable to verify checksum for System.ni.dll
Probably caused by : wininit.exe
Followup: MachineOwner
Введите! Проанализировать
23: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
CRITICAL_PROCESS_DIED (ef)
A critical system process died
Arguments:
Arg1: ffffe0018668f080, Process object or thread object
Arg2: 0000000000000000, If this is 0, a process died. If this is 1, a thread died.
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
PROCESS_OBJECT: ffffe0018668f080
IMAGE_NAME: wininit.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 0
MODULE_NAME: wininit
FAULTING_MODULE: 0000000000000000
PROCESS_NAME: msexchangerepl
BUGCHECK_STR: 0xEF_msexchangerepl
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x0 (23)
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
Child-SP RetAddr Caller, Callee
LAST_CONTROL_TRANSFER: from fffff801c368e160 to fffff801c31cb9a0
STACK_TEXT:
**privacy** : nt!KeBugCheckEx
**privacy** : nt!PspCatchCriticalBreak+0xa4
**privacy** : nt! ?? ::NNGAKEGL::`string'+**privacy**
**privacy** : nt!PspTerminateProcess+0xe5
**privacy** : nt!NtTerminateProcess+0x9e
**privacy** : nt!KiSystemServiceCopyEnd+0x13
**privacy** : ntdll!NtTerminateProcess+0xa
**privacy**: KERNELBASE!TerminateProcess+0x25
**privacy** : System_ni+**privacy**
STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
IMAGE_VERSION:
FAILURE_BUCKET_ID: 0xEF_msexchangerepl_IMAGE_wininit.exe
BUCKET_ID: 0xEF_msexchangerepl_IMAGE_wininit.exe
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0xef_msexchangerepl_image_wininit.exe
FAILURE_ID_HASH: {9cb4f9d6-5f45-6583-d4ab-0dae45299dee}
Followup: MachineOwner
---------
Вопрос
- Должен ли я запустить это на самом сервере Exchange?
- Получил ли анализ символы Exchange от публичного сервера MSFT?
- Сделал
!analyze
выяснить смысл0xffffe0018668f080
? Это адрес памяти сбойного процесса? Как мне найти этот процесс? - Нужно ли мне отмечать
**privacy**
для интернета? Я не узнал содержимое. - Работает ли Visual Studio при открытии дампов памяти?
- Что я должен был сделать по-другому при анализе этого?
- Что я должен делать дальше?
1 ответ
- Нет. Свалки можно анализировать в автономном режиме (как и вы).
- Да, если вы правильно установили сервер символов.
- Да, это адрес PEB сбойного процесса. Название процесса дается в вашем анализе. Вы можете получить полный PEB, набрав
!PEB 0xffffe0018668f080
в Windbg. Хотя имя изображения и имя процесса сбивают меня с толку. В процессе обмена произошел сбой процесса wininit, но я не ожидал, что оба имени в PEB. Возможно, кто-то с большим знанием может вмешаться, чтобы прояснить (мое) непонимание вещей. - Я понятия не имею, откуда это. Никогда не видел этого раньше.
- Тоже не знаю
- Ничего афаик. Вы сделали все необходимые шаги, чтобы найти виновного
- Используйте вашу любимую поисковую систему, чтобы попытаться найти похожие события. Поиск по
msexchangerepl
а такжеwinit
находит следующую возможную релевантную ссылку: Exchange и BugChecks. По-видимому, Exchange намеренно аварийно завершает работу wininit, если запись в журнал событий не выполняется в течение длительного периода времени.
Функция обнаружения зависания ввода-вывода в Exchange 2010 предназначена для быстрого восстановления из зависшего ввода-вывода или зависшего контроллера, а не для повторной попытки или ожидания, пока в стеке хранения не возникнет ошибка, которая вызывает аварийное переключение. Это отличное дополнение к набору функций высокой доступности, встроенных в Exchange 2010.