Quais etapas são necessárias para depurar um memory.dmp? (passo a passo incluído)

Question

Eu acordei com isso no meu eventlog hoje:

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.

Estou usando este artigo da MSFT como um guia sobre como depurá-lo.

1. Primeiro pesquiso o significado de 0x000000ef , que é processo crítico morreu

2. Tente usar o visual studio, como o artigo sugere, mas receba o erro debugging older format crash dumps is not supported

3. Instale WDK 8.1 instalar para um servidor 2012 R2 executando o Exchange

4. Abra o WinDBG, localizado em: C: \ Arquivos de programas (x86) \ Windows Kits \ 8.1 \ Dependentes \ x64

5. Defina o servidor de símbolos como srv*c:\cache*http://msdl.microsoft.com/download/symbols;

6. Abra o arquivo dmp e obtenha esta saída:

Resultado

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

Digite! analise

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
---------

Pergunta

1. Devo rodar isso no próprio Exchange Server?
2. Analisou os símbolos do Exchange do servidor MSFT público?
3. O !analyze descobriu o significado de 0xffffe0018668f080 ? Isso é um endereço de memória de um processo de falha? Como localizo esse processo?
4. É necessário marcar **privacy** para a internet? Eu não reconheci o conteúdo.
5. O Visual Studio já funciona na abertura de despejos de memória?
6. O que eu deveria ter feito diferente ao analisar isso?
7. O que devo fazer em seguida?

Answer 1

1. Não. Despejos podem ser analisados offline (assim como você fez) .
2. Sim, supondo que você tenha a configuração do servidor de símbolos correta.
3. Sim, esse é o endereço do PEB do processo com falha. O nome do processo é dado na sua análise. Você pode obter o PEB completo digitando !PEB 0xffffe0018668f080 no Windbg. O nome da imagem e o nome do processo são confusos para mim. O processo de troca travou o processo wininit, mas eu não esperaria os dois nomes no PEB. Talvez alguém com mais conhecimento possa concordar em esclarecer (meu) mal-entendido sobre as coisas.
4. Eu não tenho ideia de onde isso vem. Nunca vi isso antes.
5. Também não faço ideia
6. Nada afaik. Você fez todos os passos necessários para encontrar o culpado
7. Use seu mecanismo de pesquisa favorito para tentar encontrar eventos semelhantes. Pesquisando em msexchangerepl e winit encontra o seguinte possível link relevante: Exchange e BugChecks . Exchange aparentemente falha wininit intencionalmente ao escrever para o log de eventos falha por um longo período de tempo.

The hung IO detection feature in Exchange 2010 is designed to make recovery from hung IO or a hung controller fast, rather than re-trying or waiting until the storage stack raises an error that causes failover. It’s a great addition to the set of high availability features built into Exchange 2010.