我今天醒来时在事件日志中发现了这一点：
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.
我正在用这个微软文章作为如何调试它的指南。
首先我搜索
0x000000ef一下关键进程死亡尝试使用 Visual Studio，按照文章的建议，但会出现错误
debugging older format crash dumps is not supported安装WDK 8.1 安装对于运行 Exchange 的 2012 R2 服务器
打开 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
输入 !analyze
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 Server 上运行它吗？
- 分析是否从公共 MSFT 服务器获取了 Exchange 符号？
- 搞清楚了
!analyze的意思了吗0xffffe0018668f080？这是失败进程的内存地址吗？如何找到该进程？ - 我有必要
**privacy**在网上做标记吗？我不认识这些内容。 - Visual Studio 是否可以打开内存转储？
- 在分析这个问题时我应该做些什么不同的事情？
- 下一步我应该做什么？
答案1
- 否。转储可以离线分析（就像你一样）。
- 是的，假设您的符号服务器设置正确。
- 是的，这是失败进程的 PEB 地址。进程名称在您的分析中给出。您可以通过
!PEB 0xffffe0018668f080在 Windbg 中键入来获取完整的 PEB。不过，映像名称和进程名称让我感到困惑。交换进程已使 wininit 进程崩溃，但我不希望 PEB 中同时出现这两个名称。也许有更多知识的人可以加入进来，以消除（我）对事物的误解。 - 我不知道这是从哪里来的。我以前从来没见过。
- 也不知道
- 据我所知没什么。你已经完成了找到罪魁祸首所需的所有步骤
- 使用您最喜欢的搜索引擎尝试查找类似活动。搜索
msexchangerepl并winit找到以下可能的相关链接：交换和错误检查。当长时间写入事件日志失败时，Exchange 显然会故意使 wininit 崩溃。
Exchange 2010 中的挂起 IO 检测功能旨在快速从挂起 IO 或挂起控制器中恢复，而不是重试或等待直到存储堆栈引发导致故障转移的错误。这是对 Exchange 2010 内置高可用性功能集的一个很好的补充。