這個藍屏是什麽意思

藍屏死機(Blue Screen of Death,縮寫為:BSoD)，指的是微軟Windows操作系統在無法從壹個系統錯誤中恢復過來時所顯示的屏幕圖像。

◆錯誤分析:通常是由有問題的驅動程序引起的(比如羅技鼠標的Logitech MouseWare 9.10和9.24版驅動程序會引發這個故障). 同時,有缺陷的內存、損壞的虛擬內存文件、某些軟件(比如多媒體軟件、殺毒軟件、備份軟件、DVD播放軟件)等也會導致這個錯誤.

◇解決方案:檢查最新安裝或升級的驅動程序(如果藍屏中出現"acpi.sys"等類似文件名, 可以非常肯定是驅動程序問題)和軟件; 測試內存是否存在問題; 進入"故障恢復控制臺", 轉到虛擬內存頁面文件Pagefile.sys所在分區, 執行"del pagefile.sys"命令, 將頁面文件刪除; 然後在頁面文件所在分區執行"chkdsk /r"命令;進入Windows後重新設置虛擬內存.如果在上網時遇到這個藍屏, 而妳恰恰又在進行大量的數據下載和上傳(比如:網絡遊戲、BT下載), 那麽應該是網卡驅動的問題, 需要升級其驅動程序.WinDbg是免費軟件，其微軟官方下載地址參考擴展閱讀，具體項目為Install Debugging Tools for Windows 32/64-bit Version。

使用WinDbg分析崩潰時的內存轉儲文件的前提是您要讓系統在崩潰時自動生成壹個內存轉儲文件，做法如下：

1、單擊開始，然後單擊運行。

2、鍵入 control sysdm.cpl

復制代碼

，然後單擊確定。您將會打開系統屬性，請切換到高級選項卡。結果如下圖所示：

3、在高級選項卡上，在啟動和故障恢復部分中單擊設置。這將打開啟動和故障恢復對話框，如下圖所示：

4、在寫入調試信息列表中，選擇“小內存轉儲(64 KB)”或“核心內存轉儲”，這樣系統在崩潰時將會自動生成對應的內存轉儲文件。如果您不想讓藍屏只閃爍壹下，而是想看清楚它直到您手動重新啟動計算機，請清除系統失敗部分中自動重新啟動(R)項目前的復選框。然後單擊確定。

5、在啟動和故障恢復對話框中，單擊確定。

6、單擊確定關閉系統屬性對話框。

7、在系統設置更改對話框中，如果要立即重新啟動計算機，則單擊是；如果要稍後重新啟動計算機，則單擊否。

註：?

Vista用戶請類似操作。? 對於原版操作系統，以上設置是默認的(除了禁止自動重新啟動)。? 對於第4點中的寫入調試信息列表內容，現給出以下參照釋義：

（以上三種轉儲文件的大小依次增大，關於三者的比較不在本文討論範圍之內，筆者僅推薦設置為“小內存轉儲”或者“核心內存轉儲”，壹般性錯誤“小內存轉儲”就足夠了，如不能完好分析請選擇“核心內存轉儲”。為了數據的豐富性，您也可以直接選擇“核心內存轉儲”，但筆者強烈不推薦完全內存轉儲。）

值得註意的是，為了確保崩潰時自動生成內存轉儲文件，您可能還須啟用虛擬內存頁面文件。特別地，當您選擇記錄核心內存轉儲時，您必須啟用虛擬內存頁面文件，而且由於核心內存轉儲文件的大小取決於該機器上操作系統和所有活動驅動程序已經分配的內核模式內存的數量，因此沒有很好的辦法來預測內核內存轉儲的大小。下表僅給出該情況下的參考虛擬內存大小設置值：

另外，除了頁面文件占用的磁盤空間，內存轉儲文件(*.DMP)的生成位置所在的磁盤還要有足夠的空閑空間來提取這個轉儲文件，否則壹樣會“生成不了”(實際上是丟失了)。

設置好這些之後，壹旦您的系統發生藍屏崩潰，系統就會在以上設置中選中的相應內存轉儲文件類型下對應的目錄處生成轉儲文件。您所要做的就是立刻拿出利器——啟動WinDbg進行分析。

筆者在此將結合壹個實例進行詳細說明，過程中包含了WinDbg調試藍屏用到的壹些命令，這些命令將不再額外整理，請於閱讀過程中註意識記。

首先，您要配置WinDbg將要使用的調試符號文件(Symbol File)的位置。什麽是調試符號文件呢？符號文件隨DLL文件或者EXE文件建立時產生，提供包含在可執行文件和動態鏈接庫 (DLL) 中的函數的占位空間。此外，符號文件還可以表示達到失敗點的函數調用路線圖。當我們使用各種Microsoft工具調試應用程序時，必須擁有符號信息，這樣才能正確分析出問題根源。那我們該如何設置調試符號文件的位置呢？我們既可以從微軟官網下載完整的符號文件包(同位於WinDbg下載頁面)，也可以使用微軟的符號文件服務器(Microsoft Symbol Server)。筆者推薦後者，因為壹次分析所要用到的符號文件局限於有限的幾個而已，使用後者可以讓程序自動下載，既節省時間，又可以確保符號文件是最新的並且是正確的。在WinDbg中點擊“File”菜單，選擇“Symbol File Path …”，在打開的對話框中輸入

復制代碼

後點擊“OK”按鈕即可。當然，還有壹步就是再次點擊“File”菜單，選擇“Save Workspace”來保存當前的設置。

設置了符號文件之後，您就可以進行內存轉儲文件的分析了。同樣點擊“File”菜單，這次要選擇“Open Crash Dump …”，然後通過文件打開對話框打開生成的待分析的內存轉儲文件。本例中設置的是核心內存轉儲類型，於是應該定位至“%SystemRoot%”(即系統盤Windows文件夾下)，打開MEMORY.DMP文件。但是筆者已經事先將其轉移至“E:\Memory Dump\MEMORY.DMP”，因此在後續的圖片中，您看到的是這個地址。此時WinDbg會滾動顯示壹些信息並且會稍有掛起的感覺，直到從微軟符號文件服務器下載完分析這個崩潰文件所需要的所有符號文件。

在上圖中，我們看到就是這個打開的調試器命令窗口(Debugger Command Window)(已經將符號文件加載完畢，待命)，我們先看看位於底部的區域6，這個小的長方條就是WinDbg的命令輸入處(Command Entry)，它又分為兩個區域，左邊顯示“0: kd>”的是提示區，右邊空白區是命令輸入區。當剛打開這個窗口而符號文件尚未下載/加載完畢時，提示區域會什麽都不顯示，而命令輸入區域將顯示“Debuggee not connected”。直到符號加載完畢，窗口中顯示出最後壹行“Followup: MachineOwner”才會變為空閑狀態。在空閑狀態時，它將顯示為與上圖中類似的模樣。為什麽說類似呢？因為這個空閑待命提示根據調試類型、計算機處理器硬件配置不同，比如此例中，進行的是內核調試，於是顯示“kd>”(kernel debug)，系統為多(核)處理器，因此在“kd>”之前還顯示壹個“0:”，表明當前位於編號為0的處理器。在執行了某個命令之後，如果命令需要處理的任務較多(如“!analyze -v”)，提示區域將顯示為忙碌狀態的“*BUSY*”，壹旦顯示為這個狀態，您不論輸入什麽命令都不會立即執行，而是等待變為空閑狀態時延緩執行。

如上圖所示，圖中區域1處將顯示打開的這個內存轉儲文件的物理路經；區域2處顯示的則是當前加載的符號文件的位置，本例中表明是從微軟服務器下載；區域3***有三行，顯示的為系統信息，第壹行表明了系統為Windows XP，內核版本為2600(SP3)，多處理器(2顆)，32位，第二行表明了系統類型為NT系統，客戶端系統，第三行表明系統的詳細版本標識；區域4***兩行，第壹行表明該內存轉儲文件生成的時間，也就是系統崩潰的具體時間，本例中(這是去年12月得到的壹個崩潰轉儲文件，現用作本例進行說明)為星期六(Sat)，12月(Dec)27日，22:56:31.062，2008年，格林尼治標準時間東八區(GMT+8)，第二行顯示的是崩潰時自系統啟動以來，系統***運行了0天4小時5分15.797秒。區域5是很關鍵的錯誤信息，它的第壹行僅在加載符號文件遇到錯誤時顯示，此例中，它告訴我們“對於BaseTDI.SYS文件，模塊已經加載完畢但卻不能夠為其加載符號文件”，如果之前配置了正確的符號文件路徑，這就告訴我們BaseTDI.SYS不是微軟公司的文件，而是第三方驅動程序文件，這很可能是引起錯誤的原因，值得關註但須進壹步分析。區域5的第二行是WinDbg自動分析的結果，它告訴我們，引起崩潰的原因(Probably caused by:)很可能是HookUrl.sys文件。壹般情況下，這就是引起錯誤的罪魁禍首了，但是也有不少的例外，最典型的就是顯示壹個微軟自己的文件在此處，您可要註意了，為了避免枉殺無辜，最好進壹步分析來看看都有哪些模塊牽扯在崩潰的最後壹刻，這樣就能夠保證審判無誤了！進壹步分析的命令可以從“!analyze -v”開始。

我們既可以在命令輸入區域手動鍵入命令

!analyze -v

復制代碼

，也可以在上圖中的區域7所示位置單擊藍色的這個命令。之後，提示區域將顯示為“*BUSY*”，WinDbg將分析壹段時間直到將結果顯示完畢並再次轉為空閑狀態。下面我們根據壹張例圖闡釋執行“!analyze -v”後顯示的各種結果：

WinDbg經過自動的分析，可能會顯示上圖中區域1處所示第壹行的錯誤檢查說明(Bug Check Interpretation)，而第二行則給出了詳細的解釋，從圖中信息看得出，此例錯誤由於“驅動程序在隊列工作項目完成之前卸載”造成的。這個“DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS”就應該是顯示在藍屏上方的錯誤說明字樣，後面的Arguments1~4就是藍屏時停止代碼後面的四個參數。圖中區域2所示的BUGCHECK_STR是WinDbg中分了類別的錯誤檢查(Bug Check)的壹項，此例中為0xCE，也是停止代碼的分類簡寫，我們在命令輸入區執行

.bugcheck

復制代碼

命令，可以得到停止代碼及其參數，這和上圖的區域1、藍屏上的信息是壹致的。本例中可以得到如下結果：

0: kd> .bugcheck

Bugcheck code 000000CE

Arguments bacb0a4e 00000008 bacb0a4e 00000000

我們在Bugcheck code值前補上“0x”就可以得到藍屏上的信息“***STOP: 0x000000CE (bacb0a4e, 00000008, bacb0a4e, 00000000)”。當然，關於這個錯誤如果您想了解更多，壹個是可以在微軟在線幫助和支持網站上搜索字符串“0x000000CE”，再就是可以利用上圖中區域2的BUGCHECK_STR值“0xCE”執行

.hh bug check 0xCE

復制代碼

命令，在打開的窗口左欄右下角點擊“Display”按鈕。如果要在WinDbg中顯示壹個停止代碼或者錯誤檢查類的詳細說明(以此錯誤為例)，鍵入命令

!analyze -show 0x000000CE

復制代碼

或者

!analyze -show 000000CE

復制代碼

，也可以是

!analyze -show 0xCE

復制代碼

。區域3中顯示的就是二審判決的重要信息——線程堆棧信息。特別註意紅色框內的部分，第壹行是“WARNING: Frame IP not in any known module. Following frames may be wrong.”意思就是“警告：堆棧幀IP(InstructionPtr，僅x86處理器，用於決定幀的堆棧回朔的指令指針)不存在於任何已知的模塊中，下面的幀可能出現錯誤”。這個意思的解釋已超出本文討論範圍，筆者僅告訴大家，這行文字下面的壹行右側的模塊是系統藍屏崩潰時刻使用的最後壹個模塊(除了Windows內核最後調用KeBugCheckEx犧牲自己，就是警告文字上方的三行)，往往就是它引起了崩潰！我們來細看。大家如果了解了堆棧的數據結構或是Windows內存分配機制就應該知道，Windows為線程分配額外內存時是從高地指向低地址進行的，就是說，藍色區域3中的堆棧信息我們得倒過來由下往上看，這樣才是系統崩潰之前的壹刻內核態函數的調用和傳遞情況，比如此例，系統內核執行體(nt!,即Ntoskrnl.exe)通過函數IopfCallDriver調用了BaseTDI，然後BaseTDI又調用了HookUrl.sys(Unloaded_字樣表示未加載)，再然後就藍屏了。那麽在這最後壹刻就涉及到了兩個非Windows內核的模塊——BaseTDI以及HookUrl.sys。之所以要進行這個“二審判決”，就是要避免壹種情況——萬壹HookUrl.sys與BaseTDI是來自兩個公司或者兩個軟件的模塊，而最後加載的HookUrl.sys是沒有問題的，出錯是因為BaseTDI給HookUrl.sys傳遞了格式錯誤或者已被破壞的、或者非法的參數信息，HookUrl.sys接受此無效數據而引發了崩潰。如果我們不看線程棧，就根據之前的“Probably Cause by：HookUrl.sys”進行判決，我們很有可能枉殺無辜而讓兇手逍遙法外。只有通過線程棧我們才能發現另壹個驅動程序BaseTDI也被牽連進來。(在應用程序崩潰不致系統崩潰的調試分析中，由於處於用戶態，WinDbg自動分析結果中的“Probably Cause by：”幾乎都是錯誤的。在這種情況下，使用!thread命令是不能顯示出任何信息的，因為這個命令僅對內核態的崩潰調試有效，然而kb命令也顯示不出有用的信息，只有用“~*kb”來顯示詳細的全部線程棧才可能發現問題根源，有的時候還需配合其他命令，本文不作討論)

當然，如果您熟練以後，覺得沒有必要使用“!analyze -v”命令的話，可以直接使用

!thread

復制代碼

或者

復制代碼

命令顯示出核心的線程棧信息來二審判決。現在好了，犯罪嫌疑人目標鎖定在BaseTDI和HookUrl.sys身上。現在，我們來看看它們究竟是什麽、是哪個公司、哪個程序的模塊。(從之前不能夠自動從微軟服務器為他們加載符號文件就可以知道，它們壹定都是第三方驅動程序)

使用命令

lm kv m Basetdi*

復制代碼

(使用lm(列出模塊)命令和內核k選項、詳細v選項以及參數m，配合包含通配符*的字符串BaseTDI，來列出當時已加載於內核模式的包含字符BaseTDI的所有驅動文件詳細信息。使用通配符來取代完整的文件名後綴可以避免信息的局限性，借此也許可以發現多個相關的模塊以提供更多診斷線索)，我們得到下圖結果：

從圖中藍色框選部分，我們可以看出，當時內核態下只有壹個叫BaseTDI.SYS的文件，這個文件的路徑位於System32\Drivers下，屬於名稱為“瑞星個人防火墻”(ProductName: Rising PFW, PFW=Personal Firewall)的程序組件，軟件公司註冊商標為“瑞星”(LegalTrademarks: RISING)。文件的這些英文描述信息如果您不知道，可以百度壹下。當然，沒有被筆者高亮顯示的信息(如文件時間戳、版本、校驗和等等)也是非常有用的，比如百度壹下文件版本，也許您會發現該軟件已經提供了更新的解決此問題的文件。同樣，我們使用

lm kv m hookurl*

復制代碼

來顯示當時內核態下包含HookUrl的文件及其詳細信息。結果如下：

圖示是壹個不令人滿意的結果，因為如高亮部分所示，這個模塊未被加載，因此沒有信息被記錄。不過我們有百度，不用急，百度壹下妳就知道。在搜索完HookUrl.sys之後，發現這個也是瑞星個人防火墻的文件。其實這個案例就是著名的“瑞星個人防火墻跨版本升級到2009版時引發藍屏”事件。您可以通過關鍵字“瑞星防火墻2009升級造成藍屏”進行百度搜索。到目前為止，瑞星官方都沒有任何針對此事件的正式答復，雖然不是每個用戶都出現此問題，但是非常多的用戶都報告了此問題，瑞星也不承認這個是軟件缺陷，只有官方卡卡論壇上有壹個不知道是不是工作人員的人發帖要求大家遇到藍屏就上傳內存轉儲文件。說到這裏，我對瑞星又要失望了，但是通過這個可見藍屏內存轉儲文件的分析是多麽的有用！

在這裏，我還要給出兩個要得到更多信息時可能會使用到的命令，壹個是

!process 0 0

復制代碼

，它可以列出當時運行著的所有進程的技術信息；另壹個則是

!vm

復制代碼

，它能夠顯示出當時的虛擬內存使用情況，這對於分析系統是否耗盡了虛擬內存、換頁內存池或非換頁內存池，並結合進程列表找到可能的內存泄漏錯誤非常有用，不過已超出了本文的討論範圍。

最後，我們來看看以下的兩種特殊情況該如何使用WinDbg進行調試分析：

第壹種情況是系統掛起，也就是“死機”、“系統沒有響應”，在這種情況下，系統是根本無法自動生成內存轉儲文件的，而且您也不可能操作本地軟件來查明是什麽掛起了系統，這個時候我們需要手動讓系統崩潰，以生成內存轉儲文件。具體做法為，在系統掛起之前，打開註冊表編輯器並定位至

HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\i8042prt\Parameters

復制代碼

，在該項下面建立壹個名為

CrashOnCtrlScroll

復制代碼

的DWORD類型鍵值(註意大小寫)，並將其設置為1，然後重新啟動應用此更改。壹旦系統掛起，就可以通過按住右邊Ctrl鍵的同時擊ScrollLock鍵兩次來生成壹個停止代碼為0x000000E2(MANUALLY_INITIATED_CRASH)的手動崩潰。得到內存轉儲文件以後按照上面的方法分析。註意，此方法對插入USB口的USB鍵盤無效。(筆記本計算機鍵盤很多都是通過PS/2接口連接的，因此有效)

第二種情況是進不了系統就自動崩潰，無法提取出內存轉儲文件。這種情形以及當有特定的需要時，我們都可以采取雙機調試的方法。我們將發生崩潰的機器稱為“目標機”，將用來連接到“目標機”進行調試的機器稱為“調試主機”，調試主機必須安裝有WinDbg。

首先，我們需要在兩臺機器間建立連接，在新版的WinDbg中，這裏壹***有三種方式連接到目標機。第壹種方式為通過COM端口連接，使用零調制解調器線纜(Null-Modem)，也就是COM對接線——兩個頭都是孔的RS232線；第二種是利用IEEE 1394線纜連接，但是這種連接要求兩臺機器運行相同版本的至少為Windows XP的系統；第三種方式是使用特制的USB 2.0調試線纜連接，這不是普通的USB連接線，是壹種內置硬件芯片來支持調試的線纜，而且這種方式要求目標機運行的系統至少為Windows Vista。使用這三種連接方式進行雙機調試都需要在目標機上作出相應的設置調整，具體參見WinDbg幫助文件，這裏僅討論第壹種連接方式的設置，因為這是XP及以上系統默認支持的最簡單的方式。此時我們假設已經使用COM線纜連接好了兩臺機器。

其次，在調試主機上啟動WinDbg，配制好符號文件之後，我們展開“File”菜單，選擇“Kernal Debug…”，這將會打開如下的“Kernal Debugging”對話框：

默認打開的就是COM連接方式的配置頁面。這裏的“Baud Rate(傳輸速率)”以及“Port(端口)”需要根據下壹個步驟的操作方式來配置。

最後壹步，我們可以啟動目標機，在引導Windows之前按下F8，在啟動菜單中選擇“調試模式”，這樣，傳輸速率被系統默認設為19200，端口也默認被設為COM2，因此上壹步驟中應該照此設置後點擊“OK”。關於XP修改Boot.ini、Vista修改Bootcfg的方式啟用指定端口、傳輸速率的調試，請參見WinDbg幫助文件，在此不再贅述。目標機壹起動Windows，位於調試主機的WinDbg就能夠有信息的顯示，然後按照本文介紹的方法進行調試。另外，對於上面提到的系統掛起的情況，也可以采用這種雙機調試，並且有新的命令

.crash

復制代碼

強迫目標機在它的本地硬盤驅動器中生成壹個崩潰轉儲，當系統重新引導以後就可以提取此轉儲，當然，也可以使用

.dump /m COM.dmp

復制代碼

命令，在調試主機WinDbg所在目錄下生成壹個名叫“COM.dmp”的小內存轉儲文件(命令中的文件名可以改成其它的)。

編輯本段

預防電腦藍屏的九個小技巧

1 定期對重要的註冊表文件進行手工備份，避免系統出錯後，未能及時替換成備份文件而產生不可挽回的錯誤。

2 盡量避免非正常關機，減少重要文件的丟失。如．VxD ．DLL文件等。

3 對普通用戶而言，只要能正常運行，沒有必要去升級顯卡、主板的BIOS和驅動程序，避免升級造成的危害。

4 定期檢查優化系統文件，運行“系統文件檢查器”進行文件丟失檢查及版本校對。檢查步驟參見前面相關介紹。