Какие шаги необходимы для отладки 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 в качестве руководства о том, как ее отладить.

  1. Сначала я ищу значение 0x000000ef который является критическим процессом умер

  2. Попробуйте использовать Visual Studio, как показано в статье, но получите ошибку debugging older format crash dumps is not supported

  3. Установить WDK 8.1 установить для сервера 2012 R2 под управлением Exchange

  4. Откройте WinDBG, расположенный в: C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64

  5. Установите сервер символов на srv*c:\cache*http://msdl.microsoft.com/download/symbols;

  6. Откройте файл 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
---------

Вопрос

  1. Должен ли я запустить это на самом сервере Exchange?
  2. Получил ли анализ символы Exchange от публичного сервера MSFT?
  3. Сделал !analyze выяснить смысл 0xffffe0018668f080? Это адрес памяти сбойного процесса? Как мне найти этот процесс?
  4. Нужно ли мне отмечать **privacy** для интернета? Я не узнал содержимое.
  5. Работает ли Visual Studio при открытии дампов памяти?
  6. Что я должен был сделать по-другому при анализе этого?
  7. Что я должен делать дальше?

1 ответ

  1. Нет. Свалки можно анализировать в автономном режиме (как и вы).
  2. Да, если вы правильно установили сервер символов.
  3. Да, это адрес PEB сбойного процесса. Название процесса дается в вашем анализе. Вы можете получить полный PEB, набрав !PEB 0xffffe0018668f080 в Windbg. Хотя имя изображения и имя процесса сбивают меня с толку. В процессе обмена произошел сбой процесса wininit, но я не ожидал, что оба имени в PEB. Возможно, кто-то с большим знанием может вмешаться, чтобы прояснить (мое) непонимание вещей.
  4. Я понятия не имею, откуда это. Никогда не видел этого раньше.
  5. Тоже не знаю
  6. Ничего афаик. Вы сделали все необходимые шаги, чтобы найти виновного
  7. Используйте вашу любимую поисковую систему, чтобы попытаться найти похожие события. Поиск по msexchangerepl а также winit находит следующую возможную релевантную ссылку: Exchange и BugChecks. По-видимому, Exchange намеренно аварийно завершает работу wininit, если запись в журнал событий не выполняется в течение длительного периода времени.

Функция обнаружения зависания ввода-вывода в Exchange 2010 предназначена для быстрого восстановления из зависшего ввода-вывода или зависшего контроллера, а не для повторной попытки или ожидания, пока в стеке хранения не возникнет ошибка, которая вызывает аварийное переключение. Это отличное дополнение к набору функций высокой доступности, встроенных в Exchange 2010.

Другие вопросы по тегам