bugcheck1001藍(lán)屏,藍(lán)屏代碼1001

WIN10突然錯誤藍(lán)屏需重啟錯誤1001怎么解決

WIN10突然錯誤藍(lán)屏需重啟錯誤1001的解決方法

藍(lán)屏顯示需要重新啟動那就重新啟動，若還是藍(lán)屏的話可能原因如下：

1.虛擬內(nèi)存不足造成系統(tǒng)多任務(wù)運算錯誤

2.CPU超頻導(dǎo)致運算錯誤

3.內(nèi)存條的互不兼容或損壞引起運算錯誤

4.光驅(qū)在讀盤時被非正常打開所至

5.遭到不明的程序或病毒攻擊所至

6.版本沖突

7.注冊表中存在錯誤或損壞

8.軟硬件不兼容

9.應(yīng)用程序存在著BUG

電腦藍(lán)屏解決方法：

1.更新安全軟件，更新驅(qū)動，查殺木馬病毒

2.萬能方法：重裝系統(tǒng)

3.如果以上方法無效，那么可能是硬件損壞，建議送售后維修

WIN764藍(lán)屏提示BugCheck1000007E

你好

這種情況，一般都是由系統(tǒng)軟件、內(nèi)存、硬盤引起的。

1電腦不心裝上了惡意軟件，或上網(wǎng)時產(chǎn)生了惡意程序，建議用360衛(wèi)士、金山衛(wèi)士等軟件，清理垃圾，查殺惡意軟件，完成后重啟電腦，就可能解決。實在不行，重裝，還原過系統(tǒng)，可以解決軟件引起的問題。

2如果不能進(jìn)入系統(tǒng)，可以開機后到系統(tǒng)選擇那里按f8選起作用的最后一次正確配置(可以解決因驅(qū)動裝錯造成的錯誤)和帶網(wǎng)絡(luò)連接安全模式(進(jìn)去后是有網(wǎng)絡(luò)的，再用360軟件弄下)，可能就可以修復(fù)。

3點開始菜單運行輸入cmd回車，在命令提示符下輸入

for%1in(%windir%\system32\*.dll)doregsvr32.exe/s%1然后回車。然后讓他運行完,應(yīng)該就可能解決。

4最近電腦中毒、安裝了不穩(wěn)定的軟件、等，建議全盤殺毒，卸了那個引發(fā)問題的軟件，重新安裝其他版本，就可能解決.再不行，重新裝過系統(tǒng)就ok.

5電腦機箱里面內(nèi)存條進(jìn)灰塵，拆開機箱，拆下內(nèi)存條，清潔下內(nèi)存金手指，重新裝回去，就可能可以了。(cqjiangyong總結(jié)的,舊電腦經(jīng)常出現(xiàn)這樣的問題)

6電腦用久了內(nèi)存壞、買到水貨內(nèi)存、多條內(nèi)存一起用不兼容等，建議更換內(nèi)存即可能解決。

7很多時候由于系統(tǒng)和顯卡驅(qū)動的兼容性不好，也會出現(xiàn)這樣的錯誤，建議你換個其他版本的顯卡驅(qū)動安裝，或換個其他版本的系統(tǒng)安裝。

8電腦用久了，硬盤壞，重新分區(qū)安裝系統(tǒng)可以修復(fù)邏輯壞道，還是不行，那就到了該換硬盤的時候了，換個硬盤就可以解決。

硬件方面的問題，如果你不專業(yè)，建議拿到電腦店去測試，測試好了講好價再換。

如果幫到你，請選為滿意答案吧?。。?/p>

最近電腦總藍(lán)屏

驅(qū)動問題，進(jìn)入安全模式或者目錄恢復(fù)模式進(jìn)行以前備份的恢復(fù)。

正常進(jìn)入系統(tǒng)以后,把你的補丁下載完.

或者重裝系統(tǒng)!

電腦重啟藍(lán)屏，win8.1系統(tǒng)，偶爾藍(lán)屏，代碼如下：

這個情況很難說明具體是什么原因。但是大多數(shù)藍(lán)屏原因是用戶操作不當(dāng)，系統(tǒng)軟件沖突，驅(qū)動程序不正確，內(nèi)存不兼容，優(yōu)先級從高到低。

不管你當(dāng)時在做什么操作，只要一有卡的跡象就要停止返回，否則就會藍(lán)屏。

硬件方面如果內(nèi)存低就加塊內(nèi)存，硬盤有無問題，驅(qū)動程序是否最新更新過，是否最新安裝過新的軟件等等。

90%的藍(lán)屏是用戶操作不正確所致。

求藍(lán)屏代碼0x000000D1所有原因和解決方案

0×0000000C存取碼錯誤。0×00000002系統(tǒng)找不到指定的檔案。

0x000000D1RIVER_IRQL_NOT_LESS_OR_EQUAL◆錯誤分析:通常是由有問題的驅(qū)動程序引起的(比如羅技鼠標(biāo)的LogitechMouseWare9.10和9.24版驅(qū)動程序會引發(fā)這個故障).同時,有缺陷的內(nèi)存、損壞的虛擬內(nèi)存文件、某些軟件(比如多媒體軟件、殺毒軟件、備份軟件、DVD播放軟件)等也會導(dǎo)致這個錯誤.◇解決方案:檢查最新安裝或升級的驅(qū)動程序(如果藍(lán)屏中出現(xiàn)"acpi.sys"等類似文件名,可以非?？隙ㄊ球?qū)動程序問題)和軟件;測試內(nèi)存是否存在問題;進(jìn)入"故障恢復(fù)控制臺",轉(zhuǎn)到虛擬內(nèi)存頁面文件Pagefile.sys所在分區(qū),執(zhí)行"delpagefile.sys"命令,將頁面文件刪除;然后在頁面文件所在分區(qū)執(zhí)行"chkdsk/r"命令;進(jìn)入Windows后重新設(shè)置虛擬內(nèi)存.如果在上網(wǎng)時遇到這個藍(lán)屏,而你恰恰又在進(jìn)行大量的數(shù)據(jù)下載和上傳(比如:網(wǎng)絡(luò)游戲、BT下載),那么應(yīng)該是網(wǎng)卡驅(qū)動的問題,需要升級其驅(qū)動程序.

以下情況會引發(fā)系統(tǒng)藍(lán)屏崩潰：1、運行在內(nèi)核模式下的設(shè)備驅(qū)動程序或者操作系統(tǒng)函數(shù)引發(fā)了一個未被處理的異常，比如內(nèi)存訪問違例（由于企圖寫一個只讀頁面或者企圖讀一個當(dāng)前未被映射的內(nèi)存地址(即無效地址)而引起）。2、調(diào)用一個內(nèi)核支持例程導(dǎo)致了重新調(diào)度，比如當(dāng)中斷請求級別(IRQL)為DPC/Dispatch級別或更高級別時等待一個標(biāo)記為需要等待的調(diào)度對象。3、在DPC/Dispatch級別或更高的IRQL級別時由于數(shù)據(jù)存在于頁面文件或內(nèi)存映射文件中而發(fā)生了頁面錯誤(PageFault)。（這將要求內(nèi)存管理器必須等待一個I/O操作發(fā)生。但正如上面一項所說，在DPC/Dispatch級別或更高IRQL級別上不能夠進(jìn)行等待，因為那將要求一次重新調(diào)度）。4、當(dāng)檢測到一個內(nèi)部狀態(tài)表明數(shù)據(jù)已遭受破壞或者在保證數(shù)據(jù)不被破壞的情況下系統(tǒng)無法繼續(xù)執(zhí)行時，設(shè)備驅(qū)動程序或操作系統(tǒng)函數(shù)明確地要求系統(tǒng)崩潰（通過調(diào)用系統(tǒng)函數(shù)KeBugCheckEx）。5、發(fā)生硬件錯誤，比如處理器的計算機檢查異常功能(MachineCheck)報告有異?；蛘甙l(fā)生不可屏蔽中斷(NMI)。在了解以上三點知識之后，相信您對Windows的大無畏犧牲精神會有所贊賞，也會原諒它的“藍(lán)臉”了。其實，在絕大多數(shù)情況下均是第三方設(shè)備驅(qū)動程序?qū)е铝薟indows的崩潰。對于WindowsXP用戶提交給微軟在線崩潰分析(MicrosoftOCA,MicrosoftOnlineCrashAnalysis)站點的內(nèi)存轉(zhuǎn)儲文件，微軟對引起崩潰的原因進(jìn)行了統(tǒng)計分類，如下圖所示：（數(shù)據(jù)于2004年4月份生成）。既然Windows向我們露出了無奈的“藍(lán)臉”，我們就應(yīng)該打破沙鍋問到底，盡早將引發(fā)系統(tǒng)崩潰的罪魁禍?zhǔn)拙兡脷w案，讓我們的系統(tǒng)早日康復(fù)。下面，我們來看看Windows想通過這張“藍(lán)臉”告訴我們些什么。如上圖所示，這是一張顯示了所有參數(shù)的藍(lán)屏圖像。當(dāng)然，我們所遇到的藍(lán)屏圖像與之可能存在差異，比如少了一些信息等，但是大致是相同的，我們就以它為例進(jìn)行全面地闡述。首先，我們看看圖中用數(shù)字1標(biāo)注的區(qū)域，這里列出了傳遞給KeBugCheckEx函數(shù)的停止代碼和四個參數(shù)。此圖中的停止代碼為0x000000D1，四個參數(shù)為后面括號內(nèi)的用逗號分隔的四段16進(jìn)制數(shù)字；接下來，我們來看看圖中用數(shù)字2標(biāo)注的區(qū)域，這里顯示的是該停止代碼0x000000D1對應(yīng)的英文解釋；最后，我們看看圖中用數(shù)字3標(biāo)注的區(qū)域，這個區(qū)域當(dāng)且僅當(dāng)停止代碼的四個參數(shù)中的一個參數(shù)包含了操作系統(tǒng)或設(shè)備驅(qū)動程序代碼的地址時才會顯示，顯示的內(nèi)容為、該地址所處模塊的基地址以及日期戳。如此例中，該設(shè)備驅(qū)動程序的文件名為“myfault.sys”。這些信息對我們排錯有何作用呢？如果上圖中的區(qū)域3出現(xiàn)了，那是最好的結(jié)果了，因為您直接就看到了罪魁禍?zhǔn)住癿yfault.sys”文件。但是，區(qū)域3往往是不出現(xiàn)的，那么我們就要在Microsoft的在線幫助和支持中查找該停止代碼等信息或者使用我們的利器——WinDbg進(jìn)行手動分析了。筆者推薦后者，因為同一個停止代碼可能由各種各樣的驅(qū)動程序錯誤造成，得到了停止代碼并不等于得到了問題文件名稱，另外，微軟的在線幫助和支持中不是所有的錯誤都能夠搜索到，而WinDbg正好克服了這兩個弱點，直接能夠抓出罪魁禍?zhǔn)孜募?，讓您痛快將其斬首。WinDbg是免費軟件，其微軟官方下載地址參考擴展閱讀，具體項目為InstallDebuggingToolsforWindows32/64-bitVersion。使用WinDbg分析崩潰時的內(nèi)存轉(zhuǎn)儲文件的前提是您要讓系統(tǒng)在崩潰時自動生成一個內(nèi)存轉(zhuǎn)儲文件，做法如下：1、單擊開始，然后單擊運行。2、鍵入controlsysdm.cpl復(fù)制代碼，然后單擊確定。您將會打開系統(tǒng)屬性，請切換到高級選項卡。結(jié)果如下圖所示：3、在高級選項卡上，在啟動和故障恢復(fù)部分中單擊設(shè)置。這將打開啟動和故障恢復(fù)對話框，如下圖所示：4、在寫入調(diào)試信息列表中，選擇“小內(nèi)存轉(zhuǎn)儲(64KB)”或“核心內(nèi)存轉(zhuǎn)儲”，這樣系統(tǒng)在崩潰時將會自動生成對應(yīng)的內(nèi)存轉(zhuǎn)儲文件。如果您不想讓藍(lán)屏只閃爍一下，而是想看清楚它直到您手動重新啟動計算機，請清除系統(tǒng)失敗部分中自動重新啟動(R)項目前的復(fù)選框。然后單擊確定。5、在啟動和故障恢復(fù)對話框中，單擊確定。6、單擊確定關(guān)閉系統(tǒng)屬性對話框。7、在系統(tǒng)設(shè)置更改對話框中，如果要立即重新啟動計算機，則單擊是；如果要稍后重新啟動計算機，則單擊否。注：Vista用戶請類似操作。對于原版操作系統(tǒng)，以上設(shè)置是默認(rèn)的(除了禁止自動重新啟動)。對于第4點中的寫入調(diào)試信息列表內(nèi)容，現(xiàn)給出以下參照釋義：（以上三種轉(zhuǎn)儲文件的大小依次增大，關(guān)于三者的比較不在本文討論范圍之內(nèi)，筆者僅推薦設(shè)置為“小內(nèi)存轉(zhuǎn)儲”或者“核心內(nèi)存轉(zhuǎn)儲”，一般性錯誤“小內(nèi)存轉(zhuǎn)儲”就足夠了，如不能完好分析請選擇“核心內(nèi)存轉(zhuǎn)儲”。為了數(shù)據(jù)的豐富性，您也可以直接選擇“核心內(nèi)存轉(zhuǎn)儲”，但筆者強烈不推薦完全內(nèi)存轉(zhuǎn)儲。）值得注意的是，為了確保崩潰時自動生成內(nèi)存轉(zhuǎn)儲文件，您可能還須啟用虛擬內(nèi)存頁面文件。特別地，當(dāng)您選擇記錄核心內(nèi)存轉(zhuǎn)儲時，您必須啟用虛擬內(nèi)存頁面文件，而且由于核心內(nèi)存轉(zhuǎn)儲文件的大小取決于該機器上操作系統(tǒng)和所有活動驅(qū)動程序已經(jīng)分配的內(nèi)核模式內(nèi)存的數(shù)量，因此沒有很好的辦法來預(yù)測內(nèi)核內(nèi)存轉(zhuǎn)儲的大小。下表僅給出該情況下的參考虛擬內(nèi)存大小設(shè)置值：另外，除了頁面文件占用的磁盤空間，內(nèi)存轉(zhuǎn)儲文件(*.DMP)的生成位置所在的磁盤還要有足夠的空閑空間來提取這個轉(zhuǎn)儲文件，否則一樣會“生成不了”(實際上是丟失了)。設(shè)置好這些之后，一旦您的系統(tǒng)發(fā)生藍(lán)屏崩潰，系統(tǒng)就會在以上設(shè)置中選中的相應(yīng)內(nèi)存轉(zhuǎn)儲文件類型下對應(yīng)的目錄處生成轉(zhuǎn)儲文件。您所要做的就是立刻拿出利器——啟動WinDbg進(jìn)行分析。筆者在此將結(jié)合一個實例進(jìn)行詳細(xì)說明，過程中包含了WinDbg調(diào)試藍(lán)屏用到的一些命令，這些命令將不再額外整理，請于閱讀過程中注意識記。首先，您要配置WinDbg將要使用的調(diào)試符號文件(SymbolFile)的位置。什么是調(diào)試符號文件呢？符號文件隨DLL文件或者EXE文件建立時產(chǎn)生，提供包含在可執(zhí)行文件和動態(tài)鏈接庫(DLL)中的函數(shù)的占位空間。此外，符號文件還可以表示達(dá)到失敗點的函數(shù)調(diào)用路線圖。當(dāng)我們使用各種Microsoft工具調(diào)試應(yīng)用程序時，必須擁有符號信息，這樣才能正確分析出問題根源。那我們該如何設(shè)置調(diào)試符號文件的位置呢？我們既可以從微軟官網(wǎng)下載完整的符號文件包(同位于WinDbg下載頁面)，也可以使用微軟的符號文件服務(wù)器(MicrosoftSymbolServer)。筆者推薦后者，因為一次分析所要用到的符號文件局限于有限的幾個而已，使用后者可以讓程序自動下載，既節(jié)省時間，又可以確保符號文件是最新的并且是正確的。在WinDbg中點擊“File”菜單，選擇“SymbolFilePath…”，在打開的對話框中輸入復(fù)制代碼后點擊“OK”按鈕即可。當(dāng)然，還有一步就是再次點擊“File”菜單，選擇“SaveWorkspace”來保存當(dāng)前的設(shè)置。設(shè)置了符號文件之后，您就可以進(jìn)行內(nèi)存轉(zhuǎn)儲文件的分析了。同樣點擊“File”菜單，這次要選擇“OpenCrashDump…”，然后通過文件打開對話框打開生成的待分析的內(nèi)存轉(zhuǎn)儲文件。本例中設(shè)置的是核心內(nèi)存轉(zhuǎn)儲類型，于是應(yīng)該定位至“%SystemRoot%”(即系統(tǒng)盤Windows文件夾下)，打開MEMORY.DMP文件。但是筆者已經(jīng)事先將其轉(zhuǎn)移至“E:\MemoryDump\MEMORY.DMP”，因此在后續(xù)的圖片中，您看到的是這個地址。此時WinDbg會滾動顯示一些信息并且會稍有掛起的感覺，直到從微軟符號文件服務(wù)器下載完分析這個崩潰文件所需要的所有符號文件。在上圖中，我們看到就是這個打開的調(diào)試器命令窗口(DebuggerCommandWindow)(已經(jīng)將符號文件加載完畢，待命)，我們先看看位于底部的區(qū)域6，這個小的長方條就是WinDbg的命令輸入處(CommandEntry)，它又分為兩個區(qū)域，左邊顯示“0:kd”的是提示區(qū)，右邊空白區(qū)是命令輸入?yún)^(qū)。當(dāng)剛打開這個窗口而符號文件尚未下載/加載完畢時，提示區(qū)域會什么都不顯示，而命令輸入?yún)^(qū)域?qū)@示“Debuggeenotconnected”。直到符號加載完畢，窗口中顯示出最后一行“Followup:MachineOwner”才會變?yōu)榭臻e狀態(tài)。在空閑狀態(tài)時，它將顯示為與上圖中類似的模樣。為什么說類似呢？因為這個空閑待命提示根據(jù)調(diào)試類型、計算機處理器硬件配置不同，比如此例中，進(jìn)行的是內(nèi)核調(diào)試，于是顯示“kd”(kerneldebug)，系統(tǒng)為多(核)處理器，因此在“kd”之前還顯示一個“0:”，表明當(dāng)前位于編號為0的處理器。在執(zhí)行了某個命令之后，如果命令需要處理的任務(wù)較多(如“!analyze-v”)，提示區(qū)域?qū)@示為忙碌狀態(tài)的“*BUSY*”，一旦顯示為這個狀態(tài)，您不論輸入什么命令都不會立即執(zhí)行，而是等待變?yōu)榭臻e狀態(tài)時延緩執(zhí)行。如上圖所示，圖中區(qū)域1處將顯示打開的這個內(nèi)存轉(zhuǎn)儲文件的物理路經(jīng)；區(qū)域2處顯示的則是當(dāng)前加載的符號文件的位置，本例中表明是從微軟服務(wù)器下載；區(qū)域3共有三行，顯示的為系統(tǒng)信息，第一行表明了系統(tǒng)為WindowsXP，內(nèi)核版本為2600(SP3)，多處理器(2顆)，32位，第二行表明了系統(tǒng)類型為NT系統(tǒng)，客戶端系統(tǒng)，第三行表明系統(tǒng)的詳細(xì)版本標(biāo)識；區(qū)域4共兩行，第一行表明該內(nèi)存轉(zhuǎn)儲文件生成的時間，也就是系統(tǒng)崩潰的具體時間，本例中(這是去年12月得到的一個崩潰轉(zhuǎn)儲文件，現(xiàn)用作本例進(jìn)行說明)為星期六(Sat)，12月(Dec)27日，22:56:31.062，2008年，格林尼治標(biāo)準(zhǔn)時間東八區(qū)(GMT+8)，第二行顯示的是崩潰時自系統(tǒng)啟動以來，系統(tǒng)共運行了0天4小時5分15.797秒。區(qū)域5是很關(guān)鍵的錯誤信息，它的第一行僅在加載符號文件遇到錯誤時顯示，此例中，它告訴我們“對于BaseTDI.SYS文件，模塊已經(jīng)加載完畢但卻不能夠為其加載符號文件”，如果之前配置了正確的符號文件路徑，這就告訴我們BaseTDI.SYS不是微軟公司的文件，而是第三方驅(qū)動程序文件，這很可能是引起錯誤的原因，值得關(guān)注但須進(jìn)一步分析。區(qū)域5的第二行是WinDbg自動分析的結(jié)果，它告訴我們，引起崩潰的原因(Probablycausedby:)很可能是HookUrl.sys文件。一般情況下，這就是引起錯誤的罪魁禍?zhǔn)琢?，但是也有不少的例外，最典型的就是顯示一個微軟自己的文件在此處，您可要注意了，為了避免枉殺無辜，最好進(jìn)一步分析來看看都有哪些模塊牽扯在崩潰的最后一刻，這樣就能夠保證審判無誤了！進(jìn)一步分析的命令可以從“!analyze-v”開始。我們既可以在命令輸入?yún)^(qū)域手動鍵入命令!analyze-v復(fù)制代碼，也可以在上圖中的區(qū)域7所示位置單擊藍(lán)色的這個命令。之后，提示區(qū)域?qū)@示為“*BUSY*”，WinDbg將分析一段時間直到將結(jié)果顯示完畢并再次轉(zhuǎn)為空閑狀態(tài)。下面我們根據(jù)一張例圖闡釋執(zhí)行“!analyze-v”后顯示的各種結(jié)果：WinDbg經(jīng)過自動的分析，可能會顯示上圖中區(qū)域1處所示第一行的錯誤檢查說明(BugCheckInterpretation)，而第二行則給出了詳細(xì)的解釋，從圖中信息看得出，此例錯誤由于“驅(qū)動程序在隊列工作項目完成之前卸載”造成的。這個“DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS”就應(yīng)該是顯示在藍(lán)屏上方的錯誤說明字樣，后面的Arguments1~4就是藍(lán)屏?xí)r停止代碼后面的四個參數(shù)。圖中區(qū)域2所示的BUGCHECK_STR是WinDbg中分了類別的錯誤檢查(BugCheck)的一項，此例中為0xCE，也是停止代碼的分類簡寫，我們在命令輸入?yún)^(qū)執(zhí)行.bugcheck復(fù)制代碼命令，可以得到停止代碼及其參數(shù)，這和上圖的區(qū)域1、藍(lán)屏上的信息是一致的。本例中可以得到如下結(jié)果：0:kd.bugcheckBugcheckcode000000CEArgumentsbacb0a4e00000008bacb0a4e00000000我們在Bugcheckcode值前補上“0x”就可以得到藍(lán)屏上的信息“***STOP:0x000000CE(bacb0a4e,00000008,bacb0a4e,00000000)”。當(dāng)然，關(guān)于這個錯誤如果您想了解更多，一個是可以在微軟在線幫助和支持網(wǎng)站上搜索字符串“0x000000CE”，再就是可以利用上圖中區(qū)域2的BUGCHECK_STR值“0xCE”執(zhí)行.hhbugcheck0xCE復(fù)制代碼命令，在打開的窗口左欄右下角點擊“Display”按鈕。如果要在WinDbg中顯示一個停止代碼或者錯誤檢查類的詳細(xì)說明(以此錯誤為例)，鍵入命令!analyze-show0x000000CE復(fù)制代碼或者!analyze-show000000CE復(fù)制代碼，也可以是!analyze-show0xCE復(fù)制代碼。區(qū)域3中顯示的就是二審判決的重要信息——線程堆棧信息。特別注意紅色框內(nèi)的部分，第一行是“WARNING:FrameIPnotinanyknownmodule.Followingframesmaybewrong.”意思就是“警告：堆棧幀IP(InstructionPtr，僅x86處理器，用于決定幀的堆?；厮返闹噶钪羔?不存在于任何已知的模塊中，下面的幀可能出現(xiàn)錯誤”。這個意思的解釋已超出本文討論范圍，筆者僅告訴大家，這行文字下面的一行右側(cè)的模塊是系統(tǒng)藍(lán)屏崩潰時刻使用的最后一個模塊(除了Windows內(nèi)核最后調(diào)用KeBugCheckEx犧牲自己，就是警告文字上方的三行)，往往就是它引起了崩潰！我們來細(xì)看。大家如果了解了堆棧的數(shù)據(jù)結(jié)構(gòu)或是Windows內(nèi)存分配機制就應(yīng)該知道，Windows為線程分配額外內(nèi)存時是從高地指向低地址進(jìn)行的，就是說，藍(lán)色區(qū)域3中的堆棧信息我們得倒過來由下往上看，這樣才是系統(tǒng)崩潰之前的一刻內(nèi)核態(tài)函數(shù)的調(diào)用和傳遞情況，比如此例，系統(tǒng)內(nèi)核執(zhí)行體(nt!,即Ntoskrnl.exe)通過函數(shù)IopfCallDriver調(diào)用了BaseTDI，然后BaseTDI又調(diào)用了HookUrl.sys(Unloaded_字樣表示未加載)，再然后就藍(lán)屏了。那么在這最后一刻就涉及到了兩個非Windows內(nèi)核的模塊——BaseTDI以及HookUrl.sys。之所以要進(jìn)行這個“二審判決”，就是要避免一種情況——萬一HookUrl.sys與BaseTDI是來自兩個公司或者兩個軟件的模塊，而最后加載的HookUrl.sys是沒有問題的，出錯是因為BaseTDI給HookUrl.sys傳遞了格式錯誤或者已被破壞的、或者非法的參數(shù)信息，HookUrl.sys接受此無效數(shù)據(jù)而引發(fā)了崩潰。如果我們不看線程棧，就根據(jù)之前的“ProbablyCauseby：HookUrl.sys”進(jìn)行判決，我們很有可能枉殺無辜而讓兇手逍遙法外。只有通過線程棧我們才能發(fā)現(xiàn)另一個驅(qū)動程序BaseTDI也被牽連進(jìn)來。(在應(yīng)用程序崩潰不致系統(tǒng)崩潰的調(diào)試分析中，由于處于用戶態(tài)，WinDbg自動分析結(jié)果中的“ProbablyCauseby：”幾乎都是錯誤的。在這種情況下，使用!thread命令是不能顯示出任何信息的，因為這個命令僅對內(nèi)核態(tài)的崩潰調(diào)試有效，然而kb命令也顯示不出有用的信息，只有用“~*kb”來顯示詳細(xì)的全部線程棧才可能發(fā)現(xiàn)問題根源，有的時候還需配合其他命令，本文不作討論)當(dāng)然，如果您熟練以后，覺得沒有必要使用“!analyze-v”命令的話，可以直接使用!thread復(fù)制代碼或者kb復(fù)制代碼命令顯示出核心的線程棧信息來二審判決?，F(xiàn)在好了，犯罪嫌疑人目標(biāo)鎖定在BaseTDI和HookUrl.sys身上?，F(xiàn)在，我們來看看它們究竟是什么、是哪個公司、哪個程序的模塊。(從之前不能夠自動從微軟服務(wù)器為他們加載符號文件就可以知道，它們一定都是第三方驅(qū)動程序)使用命令lmkvmBasetdi*復(fù)制代碼(使用lm(列出模塊)命令和內(nèi)核k選項、詳細(xì)v選項以及參數(shù)m，配合包含通配符*的字符串BaseTDI，來列出當(dāng)時已加載于內(nèi)核模式的包含字符BaseTDI的所有驅(qū)動文件詳細(xì)信息。使用通配符來取代完整的文件名后綴可以避免信息的局限性，借此也許可以發(fā)現(xiàn)多個相關(guān)的模塊以提供更多診斷線索)，我們得到下圖結(jié)果：從圖中藍(lán)色框選部分，我們可以看出，當(dāng)時內(nèi)核態(tài)下只有一個叫BaseTDI.SYS的文件，這個文件的路徑位于System32\Drivers下，屬于名稱為“瑞星個人防火墻”(ProductName:RisingPFW,PFW=PersonalFirewall)的程序組件，軟件公司注冊商標(biāo)為“瑞星”(LegalTrademarks:RISING)。文件的這些英文描述信息如果您不知道，可以百度一下。當(dāng)然，沒有被筆者高亮顯示的信息(如文件時間戳、版本、校驗和等等)也是非常有用的，比如百度一下文件版本，也許您會發(fā)現(xiàn)該軟件已經(jīng)提供了更新的解決此問題的文件。同樣，我們使用lmkvmhookurl*復(fù)制代碼來顯示當(dāng)時內(nèi)核態(tài)下包含HookUrl的文件及其詳細(xì)信息。結(jié)果如下：圖示是一個不令人滿意的結(jié)果，因為如高亮部分所示，這個模塊未被加載，因此沒有信息被記錄。不過我們有百度，不用急，百度一下你就知道。在搜索完HookUrl.sys之后，發(fā)現(xiàn)這個也是瑞星個人防火墻的文件。其實這個案例就是著名的“瑞星個人防火墻跨版本升級到2009版時引發(fā)藍(lán)屏”事件。您可以通過關(guān)鍵字“瑞星防火墻2009升級造成藍(lán)屏”進(jìn)行百度搜索。到目前為止，瑞星官方都沒有任何針對此事件的正式答復(fù)，雖然不是每個用戶都出現(xiàn)此問題，但是非常多的用戶都報告了此問題，瑞