0x 000000d 1 river _ IRQL _ not _ less _ or _ equal◆錯誤分析:通常是驅動程序有故障導致的(比如羅技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級別，由於數據存在於頁面文件或內存映射文件中，所以會出現頁面錯誤。這將要求內存管理器等待I/O操作發生。但是，如前所述，您不能在DPC/調度級別或更高的IRQL級別等待，因為那需要重新安排。4.當檢測到內部狀態表明數據已經被破壞或者在保證數據不被破壞的情況下系統無法繼續執行時，設備驅動或者操作系統函數明確請求系統崩潰(通過調用系統函數KeBugCheckEx)。5.出現硬件錯誤，例如處理器的機器檢查功能報告異常或NMI。了解了以上三點，相信妳會欣賞Windows的大無畏犧牲精神，原諒它的“藍臉”。事實上，在大多數情況下，第三方設備驅動程序導致了Windows的崩潰。對於Windows XP用戶提交到微軟OCA(微軟在線崩潰分析)網站的內存轉儲文件，微軟對崩潰原因做了統計分類，如下圖所示:(數據生成於2004年4月)。既然Windows給了我們壹張無奈的“藍臉”，我們就應該刨根問底，盡快將造成系統崩潰的罪魁禍首繩之以法，讓我們的系統盡快恢復。讓我們來看看Windows想通過這張“藍臉”告訴我們什麽。如上圖所示，這是壹個顯示所有參數的藍屏圖像。當然，我們遇到的藍屏圖像可能和它不壹樣，比如漏了壹些信息，但大致都是壹樣的，所以我們就以它為例充分闡述壹下。首先，讓我們看壹下圖中用數字1標記的區域，這裏列出了傳遞給KeBugCheckEx函數的stop代碼和四個參數。本圖中的stop碼為0x000000D1，四個參數為四段16的十六進制數字，用括號中的逗號隔開；接下來我們來看看圖中用數字2標註的區域，顯示的是stop代碼0x000000D1的英文解釋；最後，我們來看看圖中用數字3標註的區域。只有當且僅當停止代碼的四個參數之壹包含操作系統或設備驅動程序代碼的地址時，才會顯示該區域。顯示的內容是，地址所在模塊的基址，日期戳。在本例中，設備驅動程序的文件名是“myfault.sys”。這些信息如何幫助我們進行調試？如果出現上圖中的3區，那就是最好的結果，因為妳直接看到了罪魁禍首——“my fault . sys”文件。但是3區往往不會出現，所以我們需要在微軟的在線幫助和支持中查找stop代碼等信息或者使用我們的利器——WindBG進行手動分析。我推薦後者，因為同壹個stop代碼可能是各種驅動錯誤造成的，得到stop代碼並不代表得到了問題文件的名稱。另外，並不是所有的錯誤都能在微軟的在線幫助和支持中搜索到，但WinDbg恰恰克服了這兩個弱點，可以直接抓住罪魁禍首文件，讓妳斬首。WinDbg是免費軟件，其微軟官方下載地址指的是延伸閱讀。具體項目是為Windows 32/64位版本安裝調試工具。使用WinDbg分析崩潰時的內存轉儲文件的前提是妳希望系統在崩潰時自動生成壹個內存轉儲文件，如下:1，點擊開始，然後點擊運行。2.鍵入控件sysdm.cpl的副本代碼，然後單擊確定。您將打開系統屬性，請切換到高級選項卡。結果如下圖所示:3。在高級選項卡上，單擊啟動和恢復部分中的設置。這將打開啟動和故障恢復對話框，如下圖所示:4 .在調試信息列表中選擇“小內存轉儲(64 KB)”或“核心內存轉儲”，這樣系統崩潰時會自動生成相應的內存轉儲文件。如果您不希望藍屏只是閃爍，而是希望在手動重新啟動計算機之前清楚地看到它，請清除“系統故障”部分中自動重新啟動(R)項目前的復選框。然後單擊確定。5.在啟動和恢復對話框中，單擊確定。6.單擊確定關閉系統屬性對話框。7.在系統設置更改對話框中，如果要立即重新啟動計算機，請單擊是；如果希望以後重新啟動計算機，請單擊“否”。註意:Vista用戶也應該這樣做。對於原操作系統，以上設置為默認(禁止自動重啟除外)。對於第4點寫的調試信息列表的內容，給出如下解釋:(以上三個轉儲文件大小依次增大，它們之間的比較不在本文討論範圍內。作者只建議設置為“小內存轉儲”或“核心內存轉儲”，壹般錯誤“小內存轉儲”就夠了。如果無法完全分析，請選擇“核心內存轉儲”。對於數據的豐富性，也可以直接選擇“核心內存轉儲”，但我強烈推薦完全內存轉儲。值得註意的是，為了確保在崩潰時自動生成內存轉儲文件，您可能還需要啟用虛擬內存分頁文件。特別是，當您選擇記錄核心內存轉儲時，您必須啟用虛擬內存分頁文件，並且因為核心內存轉儲文件的大小取決於操作系統和該機器上所有活動驅動程序已經分配的內核模式內存量，所以沒有好的方法來預測核心內存轉儲的大小。下表只給出了這種情況下的參考虛擬內存大小設置值:除了頁面文件占用的磁盤空間，內存轉儲文件(*。DMP)應該有足夠的空閑空間來提取這個轉儲文件，否則它將“未生成”(實際上丟失)。設置好這些設置後，壹旦妳的系統出現藍屏死機，系統會在上述設置中選擇的對應內存轉儲文件類型下的對應目錄下生成壹個轉儲文件。妳要做的就是馬上拿出利器——啟動WinDbg進行分析。筆者在這裏用壹個例子來詳細說明，這個例子包含了WinDbg調試藍屏時使用的壹些命令。這些命令不再另行安排，閱讀時請註意記憶。首先，您需要配置WinDbg將使用的調試符號文件的位置。什麽是調試符號文件？符號文件是隨著DLL文件或EXE文件的建立而生成的，這些文件為可執行文件和動態鏈接庫(DLL)中包含的函數提供了空間。此外，符號文件還可以表示到故障點的函數調用路線圖。當我們使用各種微軟工具調試應用程序時，必須要有符號信息，這樣才能正確分析問題的根源。那麽我們如何設置調試符號文件的位置呢？我們可以從微軟官方網站(都在WinDbg下載頁面)下載完整的符號文件包，也可以使用微軟符號服務器。我推薦後者，因為分析中使用的符號文件有限。使用後者可以使程序自動下載，既節省了時間，又保證了符號文件是最新的、正確的。點擊WinDbg中的“文件”菜單，選擇“符號文件路徑……”，在打開對話框中輸入復制代碼，點擊“確定”按鈕。當然，另壹個步驟是再次點擊“文件”菜單，選擇“保存工作區”來保存當前的設置。設置符號文件後，您可以分析內存轉儲文件。點擊“文件”菜單，這次選擇“打開崩潰轉儲…”，然後通過文件打開對話框打開生成的內存轉儲文件進行分析。在本例中，設置了核心內存轉儲類型，因此您應該導航到“%SystemRoot%”(即系統盤的Windows文件夾下)並打開內存。DMP檔案。但是我已經轉移到“E:\內存轉儲\內存。DMP”，所以在下面的圖片中，妳會看到這個地址。這時WinDbg會滾動顯示壹些信息，感覺有點懸，直到從微軟符號文件服務器下載完分析這個崩潰文件所需的所有符號文件。在上圖中，我們看到的是調試器命令窗口(符號文件已經加載並準備就緒)。我們先來看看底部的6區。這個小矩形條就是WinDbg的命令入口，分為兩個區域，左邊顯示“0: KD >”。是提示區，右邊空白區是命令輸入區。當這個窗口剛剛打開，符號文件還沒有下載/加載時，提示區什麽都不會顯示，命令輸入區會顯示“Debuggee not connected”。在符號加載之前，窗口中顯示的最後壹行“Followup: MachineOwner”將變為空閑。空閑時會出現類似上圖的情況。為什麽說類似？因為這個idle standby提示根據調試類型和電腦處理器的硬件配置不同，比如在這種情況下進行內核調試，所以顯示“KD >”。(內核調試)，系統是多核處理器，所以在“KD >”之前還顯示了壹個“0:”表示當前位於編號為0的處理器中。執行壹個命令後，如果該命令需要處理更多的任務(如"！Analyze -v”)，提示區在繁忙狀態下會顯示為“*BUSY*”。壹旦在這種狀態下顯示，無論妳輸入什麽命令，都不會立即執行，而是在空閑時延遲執行。如上圖所示，打開的內存轉儲文件的物理路徑會顯示在圖中的1區域；區域2顯示了當前加載的符號文件的位置，在這種情況下表示它是從微軟服務器下載的；區域3***有三行，顯示系統信息。第壹行表示系統是Windows XP，內核版本是2600(SP3)，有兩個多處理器(32位)。第二行表示系統類型為NT系統和客戶端系統，第三行表示系統的詳細版本標識。4***區有兩條線路。第壹行表示內存轉儲文件生成的時間，即系統崩潰的具體時間。在本例中(這是去年65438+2月獲得的壹個崩潰轉儲文件，現在用作本例的說明)，是周六(星期六)，65438+2月27日(十二月)，22: 56: 3655。區域5是壹個關鍵錯誤信息，它的第壹行僅在加載符號文件時顯示。在這種情況下，它告訴我們“對於BaseTDI。SYS文件，該模塊已加載，但無法為其加載符號文件。如果之前配置了正確的符號文件路徑，它會告訴我們BaseTDI。SYS不是微軟的文件，而是第三方的驅動文件，這很可能是錯誤的原因，值得註意，但需要進壹步分析。5區的第二行是WinDbg自動分析的結果，告訴我們崩潰的原因(很可能是由:)很可能是HookUrl.sys文件。壹般情況下，這是錯誤的罪魁禍首，但也有很多例外。最典型的就是在這裏顯示壹個微軟自己的文件。妳要註意了。為了避免濫殺無辜，最好能進壹步分析，看看墜機最後時刻涉及到哪些模塊，這樣才能保證審判正確！用於進壹步分析的命令可以從“！分析-v”開始。我們可以在命令輸入區手動輸入命令！Analyze -v復制代碼，或者點擊上圖7區所示位置的藍色命令。之後提示區會顯示為“*BUSY*”，WinDbg會分析壹段時間，直到顯示結果，再次轉為空閑狀態。讓我們來解釋壹下“的實現！“analyze -v”後顯示的各種結果:自動分析後，WinDbg可能會在上圖1區域顯示的第壹行顯示Bug檢查解釋，第二行給出詳細解釋。從圖中的信息可以看出，這個錯誤的例子是由“在隊列工作項完成之前卸載了驅動程序”引起的。這個“driver _ unloaded _ without _ canceling _ pending _ operations”應該是藍屏上面顯示的錯誤描述，下面的參數1~4是藍屏顯示時stop代碼後面的四個參數。圖中2區顯示的BUGCHECK_STR是WinDbg中的分類BUGCHECK之壹，這裏是0xCE，也是stop代碼的分類縮寫。我們可以在命令輸入區復制代碼命令，得到停止代碼及其參數，與1區和上圖藍屏的信息壹致。在這個例子中，可以獲得以下結果:0:KD & gt；。bug check Bugcheck code 000000 ce arguments bacb0a4e 000000008 BAC B0 a 4 e 00000000我們可以通過在bug check code值前加“0x”得到藍屏上的信息“* * * stop:0x 0000000 ce(BAC B0 a 4 e，0000008，BAC B0 a 4 e，000000”。當然，如果妳想知道更多關於這個錯誤的信息，妳可以在微軟在線幫助和支持網站上搜索字符串“0x000000CE ”,然後妳可以使用上圖中區域2中的BUGCHECK_STR值“0xCE”來執行hh bug check 0xCE copy code命令，並點擊打開的窗口左欄右下角的“Display”按鈕。如果妳想在WinDbg中顯示壹個停止代碼或者錯誤檢查類的詳細描述(以這個錯誤為例)，輸入命令！分析-顯示0x000000CE復制代碼或！分析-顯示000000CE復制代碼，也可以！分析-顯示0xCE復制代碼。3區顯示的是二審判決的重要信息——線程棧信息。請特別註意紅框中的部分，第壹行是“警告:幀IP不在任何已知模塊中。以下幀可能是錯誤的。表示“警告:堆棧幀IP(InstructionPtr，僅限x86處理器，用於確定幀堆棧回撤的指令指針)在任何已知模塊中都不存在，後續幀可能有錯誤”。對這壹含義的解釋超出了本文的範圍。作者只告訴妳這壹行下面壹行右邊的模塊是系統藍屏崩潰時最後使用的模塊(除了Windows內核最後調用KeBugCheckEx犧牲自己，也就是警告文字上面的三行)，經常導致崩潰！讓我們仔細看看。如果妳知道堆棧的數據結構或者Windows的內存分配機制，妳應該知道當Windows為線程分配額外的內存時，它是從高地指向低地址的。也就是說我們要從下往上看藍色區域3的堆棧信息，就是系統崩潰前壹刻內核態函數的調用和轉移。例如，在這種情況下，系統內核執行器(nt！也就是Ntoskrnl.exe)通過函數IopfCallDriver調用BaseTDI，然後BaseTDI調用Hooke rurl . sys(unloaded _這個詞的意思是卸載)，然後屏幕就藍屏了。然後在這最後的時刻，涉及到了兩個非Windows內核模塊——base TDI和HookUrl.sys。之所以這樣“二審判決”是為了避免壹種情況——萬壹HookUrl.sys和BaseTDI是兩家公司或者兩個軟件的模塊，最後加載的HookUrl.sys是沒有問題的。該錯誤是因為BaseTDI向HookUrl.sys傳遞了錯誤的格式或損壞或非法的參數信息，而HookUrl.sys接受了這些無效數據，導致了崩潰。如果不看線程棧，我們就按照前面的“可能原因by: hook URL”來判斷。sys”，而我們很可能會濫殺無辜，讓兇手逍遙法外。只有通過線程棧才能發現另壹個驅動BaseTDI也參與其中。(在應用崩潰而不導致系統崩潰的調試分析中，“可能原因:”在WinDbg的自動分析結果中幾乎總是錯誤的，因為它處於用戶模式。在這種情況下，使用！Thread命令不能顯示任何信息，因為這個命令只對內核崩潰調試有效。但是，kb命令不能顯示任何有用的信息。只有用“~*kb”詳細顯示所有線程棧，才能找到問題的根源，有時還需要配合其他命令，本文不討論。當然，如果妳精通的話，妳覺得沒必要用”！Analyze -v”命令可以直接使用！線程復制代碼或kb復制代碼命令顯示核心線程堆棧信息，用於二審判斷。現在，嫌疑人的目標是BaseTDI和HookUrl.sys，現在，我們來看看他們是什麽，是哪個公司，是哪個程序模塊。(從他們之前不能從微軟服務器自動為他們加載符號文件就可以知道，肯定都是第三方驅動。)使用命令lm kv m BaseTDI*復制代碼(使用lm (list module)命令、內核k選項、詳細v選項和參數m，配合包含通配符*的字符串Basetdi，列出當時內核模式下加載的包含字符Basetdi的所有驅動文件詳細信息。使用通配符代替完整的文件名後綴可以避免信息的限制，這樣我們可能會找到多個相關的模塊來提供更多的診斷線索。)我們得到以下結果:從圖中的藍框可以看到，只有壹個名為BaseTDI的文件。SYS，這個文件的路徑位於System32\Drivers下。它屬於壹個名為“瑞星PFW(產品名:瑞星PFW =個人防火墻)”的程序組件，軟件公司的註冊商標為“LegalTrademarks: RISING”。如果不知道文檔的英文描述信息，可以百度壹下。當然，作者沒有突出顯示的信息(如文件時間戳、版本、校驗和等。)也很有用。例如，如果您查看文件版本，您可能會發現軟件已經提供了壹個更新的文件來解決這個問題。同樣，我們使用lm kv m hookurl*來復制代碼，以在當時的內核模式下顯示包含hookurl的文件及其詳細信息。結果如下:圖是壹個不理想的結果，因為如高亮部分所示，這個模塊沒有加載，所以沒有記錄任何信息。但是我們有百度，不用擔心，妳看看百度就知道了。搜了壹下HookUrl.sys，發現這也是瑞星個人防火墻的壹個文件。這個案例其實就是著名的“瑞星個人防火墻升級到2009版時觸發藍屏”。可以通過關鍵詞“瑞星防火墻2009升級導致藍屏”搜索百度。截至目前，瑞星官方並未對此事件給出任何官方回復。雖然不是每個用戶都有這個問題，但是很多用戶都反映過，瑞。