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

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

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

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

2.CPU超頻導(dǎo)致運(yùn)算錯(cuò)誤

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

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

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

6.版本沖突

7.注冊(cè)表中存在錯(cuò)誤或損壞

8.軟硬件不兼容

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

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

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

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

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

WIN764藍(lán)屏提示BugCheck1000007E

你好

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

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

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

3點(diǎn)開始菜單運(yùn)行輸入cmd回車，在命令提示符下輸入

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

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

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

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

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

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

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

如果幫到你，請(qǐng)選為滿意答案吧！??！

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

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

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

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

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

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

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

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

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

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

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

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

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