Quali passi sono necessari per eseguire il debug di una memory.dmp? (passaggio incluso)

Mi sono svegliato oggi nel mio eventlog:

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. 

Sto utilizzando questo articolo di MSFT come guida su come eseguire il debug.

  1. In primo luogo cerco il significato di 0x000000ef che è Processo critico morto

  2. Provare a utilizzare lo studio visivo, come suggerisce l'articolo, ma debugging older format crash dumps is not supported l'errore di debugging older format crash dumps is not supported

  3. Installare WDK 8.1 per installare un server 2012 R2 che esegue Exchange

  4. Apri WinDBG, che si trova in: C: \ Programmi (x86) \ Kit di Windows \ 8.1 \ Debuggers \ x64

  5. Impostare il server di simboli in srv*c:\cache*http://msdl.microsoft.com/download/symbols;

  6. Apri il file dmp e ottieni questa output:

Produzione

 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 

Digita! Analizza

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

Domanda

  1. Devo eseguire questa operazione sul server di Exchange stesso?
  2. Ha analizzato get i simboli di scambio dal pubblico MSFT server?
  3. Ha !analyze il significato di 0xffffe0018668f080 ? È un indirizzo di memory di un process fallito? Come posso individuare quel process?
  4. È necessario che io segni **privacy** per internet? Non ho riconosciuto i contenuti.
  5. Does Visual Studio funziona mai in apertura di discariche di memory?
  6. Cosa devo fare diversamente nell'analizzare questo problema?
  7. Cosa dovrei fare dopo?

    One Solution collect form web for “Quali passi sono necessari per eseguire il debug di una memory.dmp? (passaggio incluso)”

    1. No. Le discariche possono essere analizzate in modalità offline (proprio come hai fatto) .
    2. Sì, supponendo che l'impostazione del server di simboli sia corretta.
    3. Sì, questo è l'indirizzo del PEB del process fallito. Il nome del process viene fornito nell'analisi. Puoi get il PEB completo digitando !PEB 0xffffe0018668f080 in Windbg. Il nome dell'image e il nome del process mi confondono però. Il process di scambio ha schiantato il process wininit ma non mi aspettavo entrambi i nomi nella PEB. Forse qualcuno con più conoscenza può chimerizzare chiaramente (il mio) malinteso delle cose.
    4. Non ho idea di where provengano. Mai visto prima.
    5. Anche nessuna idea
    6. Niente afaik. Hai fatto tutti i passi necessari per trovare il colpevole
    7. Utilizza il tuo motore di ricerca preferito per cercare events simili. La ricerca su msexchangerepl e winit trova dopo un eventuale collegamento rilevante: Exchange e BugCheck . Scambia apparentemente crashes wininit intenzionalmente quando la scrittura nel registro degli events fallisce per un lungo periodo di tempo.

    La funzionalità di rilevamento IO in Hang 2010 in Exchange è stata progettata per rendere veloce il ripristino da IO bloccato o da un controller appeso, piuttosto che riprovare o attendere che lo stack di archiviazione solleva un errore che causa il failover. È un'ottima aggiunta all'insieme delle funzionalità di alta disponibilità integrate in Exchange 2010.

      Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.