0x000000D1RIVER_IRQL_NOT_LESS_OR_EQUAL ◆錯誤分析:通常是由有問題的驅動程序引起的(比如羅技鼠標的Logitech MouseWare 9.10和9.24版驅動程序會引發這個故障). 同時,有缺陷的內存、 損壞的虛擬內存文件、 某些軟件(比如多媒體軟件、殺毒軟件、備份軟件、DVD播放軟件)等也會導致這個錯誤. ◇解決方案:檢查最新安裝或升級的驅動程序(如果藍屏中出現"acpi.sys"等類似文件名, 可以非常肯定是驅動程序問題)和軟件; 測試內存是否存在問題; 進入"故障恢復控制臺", 轉到虛擬內存頁面文件Pagefile.sys所在分區, 執行"del pagefile.sys"命令, 將頁面文件刪除; 然後在頁面文件所在分區執行"chkdsk /r"命令;進入Windows後重新設置虛擬內存.如果在上網時遇到這個藍屏, 而妳恰恰又在進行大量的數據下載和上傳(比如:網絡遊戲、BT下載), 那麽應該是網卡驅動的問題, 需要升級其驅動程序.
以下情況會引發系統藍屏崩潰： 1、運行在內核模式下的設備驅動程序或者操作系統函數引發了壹個未被處理的異常，比如內存訪問違例（由於企圖寫壹個只讀頁面或者企圖讀壹個當前未被映射的內存地址(即無效地址)而引起）。 2、調用壹個內核支持例程導致了重新調度，比如當中斷請求級別(IRQL)為DPC/Dispatch級別或更高級別時等待壹個標記為需要等待的調度對象。 3、在DPC/Dispatch級別或更高的IRQL級別時由於數據存在於頁面文件或內存映射文件中而發生了頁面錯誤(Page Fault)。（這將要求內存管理器必須等待壹個I/O操作發生。但正如上面壹項所說，在DPC/Dispatch級別或更高IRQL級別上不能夠進行等待，因為那將要求壹次重新調度）。 4、當檢測到壹個內部狀態表明數據已遭受破壞或者在保證數據不被破壞的情況下系統無法繼續執行時，設備驅動程序或操作系統函數明確地要求系統崩潰（通過調用系統函數KeBugCheckEx）。 5、發生硬件錯誤，比如處理器的計算機檢查異常功能(Machine Check)報告有異常或者發生不可屏蔽中斷(NMI)。 在了解以上三點知識之後，相信您對Windows的大無畏犧牲精神會有所贊賞，也會原諒它的“藍臉”了。其實，在絕大多數情況下均是第三方設備驅動程序導致了Windows的崩潰。對於Windows XP用戶提交給微軟在線崩潰分析(Microsoft OCA, Microsoft Online Crash Analysis)站點的內存轉儲文件，微軟對引起崩潰的原因進行了統計分類，如下圖所示：（數據於2004年4月份生成）。 既然Windows向我們露出了無奈的“藍臉”，我們就應該打破沙鍋問到底，盡早將引發系統崩潰的罪魁禍首緝拿歸案，讓我們的系統早日康復。下面，我們來看看Windows想通過這張“藍臉”告訴我們些什麽。 如上圖所示，這是壹張顯示了所有參數的藍屏圖像。當然，我們所遇到的藍屏圖像與之可能存在差異，比如少了壹些信息等，但是大致是相同的，我們就以它為例進行全面地闡述。 首先，我們看看圖中用數字1標註的區域，這裏列出了傳遞給KeBugCheckEx函數的停止代碼和四個參數。此圖中的停止代碼為0x000000D1，四個參數為後面括號內的用逗號分隔的四段16進制數字；接下來，我們來看看圖中用數字2標註的區域，這裏顯示的是該停止代碼0x000000D1對應的英文解釋；最後，我們看看圖中用數字3標註的區域，這個區域當且僅當停止代碼的四個參數中的壹個參數包含了操作系統或設備驅動程序代碼的地址時才會顯示，顯示的內容為、該地址所處模塊的基地址以及日期戳。如此例中，該設備驅動程序的文件名為“myfault.sys”。 這些信息對我們排錯有何作用呢？如果上圖中的區域3出現了，那是最好的結果了，因為您直接就看到了罪魁禍首——“myfault.sys”文件。但是，區域3往往是不出現的，那麽我們就要在Microsoft的在線幫助和支持中查找該停止代碼等信息或者使用我們的利器——WinDbg進行手動分析了。筆者推薦後者，因為同壹個停止代碼可能由各種各樣的驅動程序錯誤造成，得到了停止代碼並不等於得到了問題文件名稱，另外，微軟的在線幫助和支持中不是所有的錯誤都能夠搜索到，而WinDbg正好克服了這兩個弱點，直接能夠抓出罪魁禍首文件，讓您痛快將其斬首。 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 復制代碼 或者 kb 復制代碼 命令顯示出核心的線程棧信息來二審判決。現在好了，犯罪嫌疑人目標鎖定在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升級造成藍屏”進行百度搜索。到目前為止，瑞星官方都沒有任何針對此事件的正式答復，雖然不是每個用戶都出現此問題，但是非常多的用戶都報告了此問題，瑞