本文介紹了你的整臺(tái)服務(wù)器死機(jī)后，該怎樣排除故障。

我們大多數(shù)人都遇到過(guò)這種情況：服務(wù)器毫無(wú)反應(yīng)，結(jié)果我們無(wú)法訪問(wèn)任務(wù)管理器，甚至無(wú)法訪問(wèn)服務(wù)器上的網(wǎng)絡(luò)共享區(qū)。當(dāng)然，不用說(shuō)，出問(wèn)題的似乎總是任務(wù)關(guān)鍵型服務(wù)器。這意味著，負(fù)責(zé)服務(wù)器的IT管理員難免會(huì)驚慌失措。

處理服務(wù)器死機(jī)時(shí)，區(qū)別所謂的硬死機(jī)（call hang）與軟死機(jī)（soft hang）顯得很重要。這常常可以幫助我們根據(jù)在服務(wù)器上能執(zhí)行什么操作、不能執(zhí)行什么操作，至少能夠診斷基本問(wèn)題。比如說(shuō)，如果我們無(wú)法ping測(cè)試服務(wù)器，無(wú)法通過(guò)鍵盤切換數(shù)字鎖定鍵（NumLock）或大寫鎖定鍵（Caps Lock）功能，或者鼠標(biāo)光標(biāo)沒(méi)有任何反應(yīng)， 那么我們極有可能遇到了硬死機(jī)。這些問(wèn)題一般與硬件有關(guān)（可能與驅(qū)動(dòng)程序有關(guān)），但是很少與Windows操作系統(tǒng)的配置問(wèn)題或內(nèi)存泄漏有關(guān)。遇到硬死機(jī)時(shí)，系統(tǒng)死機(jī)出現(xiàn)在內(nèi)核的很低層面，不再處理線程。如果是硬死機(jī)，***步就是聯(lián)系硬件廠商，對(duì)系統(tǒng)進(jìn)行一番診斷。除非你有具體的理由懷疑問(wèn)題出在某個(gè)硬件上（比如說(shuō)最近安裝的內(nèi)存等），否則不建議你隨便取出或更換硬件。

現(xiàn)在再來(lái)說(shuō)說(shuō)軟死機(jī)；當(dāng)服務(wù)器處于軟死機(jī)狀態(tài)下，它基本上沒(méi)有反應(yīng)，但是內(nèi)核在很低的層面仍在工作——比如說(shuō)，ping測(cè)試或切換數(shù)字鎖定鍵一切正常。在軟死機(jī)狀態(tài)下，你可能無(wú)法在本地或通過(guò)終端服務(wù)（Terminal Services）登錄到機(jī)器上，或者可能會(huì)遇到桌面一片空白，不過(guò)網(wǎng)絡(luò)和打印機(jī)共享區(qū)仍可以訪問(wèn)。對(duì)于內(nèi)存耗盡或進(jìn)程死鎖期間我們看到的那種類型的癥狀而言，這個(gè)現(xiàn)象比較常見(jiàn)。

我們看到的一種通常的死機(jī)問(wèn)題是由分頁(yè)或非分頁(yè)池內(nèi)存耗盡引起的。這些資源耗盡時(shí)，你會(huì)在系統(tǒng)事件日志（System Event Log）中看到類似下列事件的事件： 

 正如你所見(jiàn)，2019錯(cuò)誤表明非分頁(yè)池內(nèi)存已耗盡；2020錯(cuò)誤表明分頁(yè)池內(nèi)存已耗盡。如果你在死機(jī)之前看到日志中有任何這樣的事件，解決了耗盡問(wèn)題很可能連帶解決了死機(jī)問(wèn)題。我們的Platforms CPR小組去年發(fā)表了一篇博文（http://blogs.msdn.com/b/ntdebugging/archive/2006/12/18/understanding-pool-consumption-and-event-id_3a00_--2020-or-2019.aspx），介紹了如何為2019問(wèn)題和2020問(wèn)題排除故障，所以我們?cè)谶@里不作贅述。

查明根源更難一點(diǎn)的問(wèn)題是系統(tǒng)頁(yè)表項(xiàng)（PTE）耗盡引起的死機(jī)。我們?cè)谥瓣P(guān)于3GB切換（/3GB switch）的一篇文章中簡(jiǎn)要地介紹了系統(tǒng)PTE。PTE是用來(lái)跟蹤內(nèi)存中頁(yè)面的結(jié)構(gòu)，好比圖書索引告訴你圖書內(nèi)容在哪一頁(yè)上。PTE告訴系統(tǒng)數(shù)據(jù)駐留在內(nèi)存的哪一個(gè)物理頁(yè)面上。機(jī)器從固定數(shù)量的PTE開(kāi)始——系統(tǒng)中的內(nèi)存越多，需要越多的PTE指向內(nèi)存頁(yè)面。如果系統(tǒng)耗盡了可用的頁(yè)面表項(xiàng)，它再也無(wú)法分配內(nèi)存，因而導(dǎo)致系統(tǒng)死機(jī)或毫無(wú)反應(yīng)。

遺憾的是，系統(tǒng)PTE耗盡時(shí)，系統(tǒng)日志中沒(méi)有什么條目表明這個(gè)問(wèn)題。不過(guò)，你可以使用性能監(jiān)視器（Performance Monitor）來(lái)監(jiān)視空閑系統(tǒng)PTE。沒(méi)有計(jì)數(shù)器詳細(xì)分解每個(gè)進(jìn)程的PTE使用情況，所以單單使用性能監(jiān)視器來(lái)查明PTE耗盡的根源并非總是切實(shí)可行。你也許能夠?qū)⑦M(jìn)程的句柄數(shù)量不斷上升（句柄泄漏）與PTE耗盡關(guān)聯(lián)起來(lái)，然而除非存在明顯的根源，否則就要內(nèi)存轉(zhuǎn)儲(chǔ)或?qū)崟r(shí)調(diào)試。

所以概括起來(lái)，下面是系統(tǒng)完全死機(jī)后需要遵循的幾個(gè)簡(jiǎn)單步驟：

1. 這是硬死機(jī)還是軟死機(jī)？如果這是硬死機(jī)，那么很可能是底層硬件出了問(wèn)題，所以就要聯(lián)系硬件廠商。

2. 檢查事件日志，查找發(fā)生死機(jī)時(shí)事件日志中的任何事件。以頁(yè)面池耗盡為例，你會(huì)看到事件編號(hào)2019或2020，事件來(lái)源是SRV。

3. 啟動(dòng)性能監(jiān)視器，檢查內(nèi)存對(duì)象下面空閑系統(tǒng)PTE的起始值。如果系統(tǒng)啟動(dòng)時(shí)，空閑系統(tǒng)PTE少于正常值（大約15000或更少），那么這不是個(gè)好兆頭。這意味著，所有PTE在啟動(dòng)時(shí)已被耗盡，因而可供服務(wù)器正常操作使用的資源就比較少了。

4. 創(chuàng)建性能監(jiān)視器日志，讓它運(yùn)行一段時(shí)間。起碼要添加針對(duì)內(nèi)存、進(jìn)程、處理器和系統(tǒng)的計(jì)數(shù)器。你需要讓日志運(yùn)行多長(zhǎng)時(shí)間，取決于系統(tǒng)多久過(guò)后出現(xiàn)死機(jī)（假設(shè)死機(jī)問(wèn)題一再發(fā)生）。設(shè)好間隔時(shí)間，以便你能夠在日志有效期內(nèi)捕捉到至少100個(gè)樣本。任何內(nèi)存偏低的情況都應(yīng)該一目了然——如果這種泄漏很穩(wěn)定的話，更是如此。

5. ***，請(qǐng)遵循這篇文章（http://support.microsoft.com/default.aspx?scid=kb;EN-US;244139）里面介紹的一些步驟，讓系統(tǒng)準(zhǔn)備好捕捉完整的內(nèi)存轉(zhuǎn)儲(chǔ)，以便需要時(shí)便于分析。
 

原文鏈接：http://blogs.technet.com/b/askperf/archive/2007/09/25/troubleshooting-server-hangs-part-one.aspx