Какие шаги требуются, чтобы отлаживать memory.dmp? (включенная пошаговая демонстрация)

Я осознал это в своем 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.

Я использую эту статью MSFT в качестве руководства по тому, как отладить ее.

1. Сначала я ищу значение 0x000000ef то, которое является Критическим Процессом, Умерло

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

3. WDK 8.1 установки устанавливает для сервера R2 2012 года рабочий 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 Server?
2. Действительно анализировал получают символы Exchange от общедоступного сервера MSFT?
3. Сделал !analyze выясните значение 0xffffe0018668f080? Это - адрес памяти провального процесса? Как я определяю местоположение того процесса?
4. Действительно ли необходимо для меня отметить **privacy** для Интернета? Я не распознал содержание.
5. Visual Studio когда-либо работает в открытии дампов памяти?
6. Что я должен был сделать по-другому в анализе этого?
7. Что я должен сделать затем?