本文介绍了你的整台服务器死机后，该怎样排除故障。

　　我们大多数人都遇到过这种情况：服务器毫无反应，结果我们无法访问任务管理器，甚至无法访问服务器上的网络共享区。当然，不用说，出问题的似乎总是任务关键型服务器。这意味着，负责服务器的IT管理员难免会惊慌失措。

　　处理服务器死机时，区别所谓的硬死机（call hang）与软死机（soft hang）显得很重要。这常常可以帮助我们根据在服务器上能执行什么操作、不能执行什么操作，至少能够诊断基本问题。比如说，如果我们无法ping测试服务器，无法通过键盘切换数字锁定键（NumLock）或大写锁定键（Caps Lock）功能，或者鼠标光标没有任何反应， 那么我们极有可能遇到了硬死机。这些问题一般与硬件有关（可能与驱动程序有关），但是很少与Windows操作系统的配置问题或内存泄漏有关。遇到硬死机时，系统死机出现在内核的很低层面，不再处理线程。如果是硬死机，第一步就是联系硬件厂商，对系统进行一番诊断。除非你有具体的理由怀疑问题出在某个硬件上（比如说最近安装的内存等），否则不建议你随便取出或更换硬件。

　　现在再来说说软死机；当服务器处于软死机状态下，它基本上没有反应，但是内核在很低的层面仍在工作——比如说，ping测试或切换数字锁定键一切正常。在软死机状态下，你可能无法在本地或通过终端服务（Terminal Services）登录到机器上，或者可能会遇到桌面一片空白，不过网络和打印机共享区仍可以访问。对于内存耗尽或进程死锁期间我们看到的那种类型的症状而言，这个现象比较常见。

　　我们看到的一种通常的死机问题是由分页或非分页池内存耗尽引起的。这些资源耗尽时，你会在系统事件日志（System Event Log）中看到类似下列事件的事件：

　　正如你所见，2019错误表明非分页池内存已耗尽；2020错误表明分页池内存已耗尽。如果你在死机之前看到日志中有任何这样的事件，解决了耗尽问题很可能连带解决了死机问题。我们的Platforms CPR小组去年发表了一篇博文（http://blogs.msdn.com/b/ntdebugging/archive/2006/12/18/understanding-pool-consumption-and-event-id_3a00_–2020-or-2019.aspx），介绍了如何为2019问题和2020问题排除故障，所以我们在这里不作赘述。

　　查明根源更难一点的问题是系统页表项（PTE）耗尽引起的死机。我们在之前关于3GB切换（/3GB switch）的一篇文章中简要地介绍了系统PTE。PTE是用来跟踪内存中页面的结构，好比图书索引告诉你图书内容在哪一页上。PTE告诉系统数据驻留在内存的哪一个物理页面上。机器从固定数量的PTE开始——系统中的内存越多，需要越多的PTE指向内存页面。如果系统耗尽了可用的页面表项，它再也无法分配内存，因而导致系统死机或毫无反应。

　　遗憾的是，系统PTE耗尽时，系统日志中没有什么条目表明这个问题。不过，你可以使用性能监视器（Performance Monitor）来监视空闲系统PTE。没有计数器详细分解每个进程的PTE使用情况，所以单单使用性能监视器来查明PTE耗尽的根源并非总是切实可行。你也许能够将进程的句柄数量不断上升（句柄泄漏）与PTE耗尽关联起来，然而除非存在明显的根源，否则就要内存转储或实时调试。

　　所以概括起来，下面是系统完全死机后需要遵循的几个简单步骤：

　　1. 这是硬死机还是软死机？如果这是硬死机，那么很可能是底层硬件出了问题，所以就要联系硬件厂商。

　　2. 检查事件日志，查找发生死机时事件日志中的任何事件。以页面池耗尽为例，你会看到事件编号2019或2020，事件来源是SRV。

　　3. 启动性能监视器，检查内存对象下面空闲系统PTE的起始值。如果系统启动时，空闲系统PTE少于正常值（大约15000或更少），那么这不是个好兆头。这意味着，所有PTE在启动时已被耗尽，因而可供服务器正常操作使用的资源就比较少了。

　　4. 创建性能监视器日志，让它运行一段时间。起码要添加针对内存、进程、处理器和系统的计数器。你需要让日志运行多长时间，取决于系统多久过后出现死机（假设死机问题一再发生）。设好间隔时间，以便你能够在日志有效期内捕捉到至少100个样本。任何内存偏低的情况都应该一目了然——如果这种泄漏很稳定的话，更是如此。

　　5. 最后，请遵循这篇文章（http://support.microsoft.com/default.aspx?scid=kb;EN-US;244139）里面介绍的一些步骤，让系统准备好捕捉完整的内存转储，以便需要时便于分析。