簡(jiǎn)介這份文檔聚焦Windows系統(tǒng)藍(lán)屏故障的快速排查面向普通電腦用戶(hù)、桌面運(yùn)維與裝機(jī)維護(hù)人員把藍(lán)屏畫(huà)面上那串令人費(fèi)解的停機(jī)碼變成可讀、可查、可對(duì)照的診斷線(xiàn)索。內(nèi)容圍繞藍(lán)屏?xí)r顯示的信息展開(kāi)先講清STOP 0x0000001E這類(lèi)提示的三段結(jié)構(gòu)停機(jī)碼標(biāo)識(shí)錯(cuò)誤類(lèi)型括號(hào)內(nèi)四個(gè)參數(shù)供驅(qū)動(dòng)開(kāi)發(fā)者定位錯(cuò)誤名與首行信息則指向出問(wèn)題的驅(qū)動(dòng)或設(shè)備再給出重啟、排查新硬件、卸載新驅(qū)動(dòng)與新服務(wù)、查殺病毒、更新BIOS、查看系統(tǒng)日志、檢索停機(jī)碼、調(diào)用「最后一次正確配置」、安裝補(bǔ)丁與Service Pack等九條處理路徑并附0x0000至0x0041常用代碼的中文釋義對(duì)照表。資源包僅含1個(gè)doc文件約133KB輕量易存可離線(xiàn)查閱或在故障機(jī)上直接打開(kāi)。已有5449人學(xué)習(xí)下載適合希望脫離搜索引擎、按圖索驥判斷藍(lán)屏成因的讀者。1. 藍(lán)屏停機(jī)碼查詢(xún)屏幕上那行 STOP 0x0000001E 到底該去哪查半夜被叫起來(lái)處理一臺(tái)反復(fù)重啟的機(jī)器屏幕上只剩一行STOP 0x0000007B其余全是英文。此時(shí)最需要的是能立刻對(duì)照的表格把停機(jī)碼查成錯(cuò)誤名再把錯(cuò)誤名對(duì)照成一個(gè)可執(zhí)行動(dòng)作而不是一篇講內(nèi)核架構(gòu)的長(zhǎng)文。這份 Windows 藍(lán)屏代碼查詢(xún)資料正好就是這類(lèi)資源前半部分說(shuō)明藍(lán)屏界面上三段信息各自負(fù)責(zé)什么即停機(jī)碼、推薦操作和調(diào)試端口后半部分是一張從 0x0000 排到 0x0528 的錯(cuò)誤碼對(duì)照表外加九條從重啟到安裝補(bǔ)丁的處置順序。它適合兩類(lèi)人手上有多臺(tái)機(jī)器要維護(hù)、不想每次藍(lán)屏都靠重裝的運(yùn)維剛接觸系統(tǒng)排錯(cuò)、需要一套能照著復(fù)述的流程的新手。有一點(diǎn)必須提前說(shuō)清楚表里的碼不是萬(wàn)能的用錯(cuò)表比不查更麻煩這也正是后面要重點(diǎn)拆開(kāi)講的地方。2. 拆開(kāi) STOP 那一行停機(jī)碼、四個(gè)參數(shù)、錯(cuò)誤名的三層結(jié)構(gòu)藍(lán)屏界面上那幾行英文看著嚇人其實(shí)結(jié)構(gòu)極其固定。以資料里給的例子為準(zhǔn)*** STOP 0x0000001E (0xC0000005, 0xFDE38AF9, 0x0000001, 0x7E8B0EB4) KMODE_EXCEPTION_NOT_HANDLED ***三部分各司其職第一部分0x0000001E是停機(jī)碼Stop Code用來(lái)標(biāo)識(shí)錯(cuò)誤類(lèi)型第二部分是括號(hào)里的四個(gè)十六進(jìn)制數(shù)是驅(qū)動(dòng)編寫(xiě)者和內(nèi)核開(kāi)發(fā)者才看得懂的現(xiàn)場(chǎng)參數(shù)第三部分是錯(cuò)誤名它才是能拿去檢索的關(guān)鍵詞。很多人卡住恰恰是因?yàn)橹欢⒅谝徊糠职阉鼜?fù)制進(jìn)搜索框然后在一堆泛泛而談的答案里繞圈。2.1 停機(jī)碼是索引不是答案停機(jī)碼本質(zhì)上是內(nèi)核在KeBugCheckEx里傳入的一個(gè)分類(lèi)編號(hào)它的價(jià)值在于把成千上萬(wàn)種崩潰現(xiàn)場(chǎng)歸到幾十個(gè)類(lèi)別里。比如0x0000001E對(duì)應(yīng)KMODE_EXCEPTION_NOT_HANDLED含義是“內(nèi)核模式下拋出了異常但沒(méi)有任何人處理它”?？吹竭@個(gè)類(lèi)別你能確定的是責(zé)任范圍在驅(qū)動(dòng)或內(nèi)核組件而不能確定是哪個(gè)驅(qū)動(dòng)。這就決定了正確的查詢(xún)順序停機(jī)碼 → 錯(cuò)誤名 → 責(zé)任方 → 動(dòng)作。跳過(guò)第二步直接搜數(shù)字命中率會(huì)明顯下降因?yàn)橥粋€(gè)數(shù)字在不同語(yǔ)境下含義完全不同這一點(diǎn)在第 3 章會(huì)展開(kāi)。真要查資料用錯(cuò)誤名去搜往往比用數(shù)字更準(zhǔn)因?yàn)殄e(cuò)誤名是全局唯一的字符串而數(shù)字會(huì)被各種錯(cuò)誤碼表重復(fù)占用。另外提醒一句不是所有藍(lán)屏都給你完整信息。有的機(jī)器一閃而過(guò)有的只顯示一個(gè)名字不顯示代碼這時(shí)候靠的是轉(zhuǎn)儲(chǔ)文件和系統(tǒng)日志而不是屏幕。屏幕只是入口取證的活兒在后面。2.2 括號(hào)里那四個(gè)數(shù)字才是給懂行的人看的資料里對(duì)這四個(gè)參數(shù)的評(píng)價(jià)很實(shí)在——普通用戶(hù)根本看不懂。但對(duì)排錯(cuò)的人來(lái)說(shuō)它們是唯一能把“某一類(lèi)錯(cuò)誤”收斂到“某一個(gè)驅(qū)動(dòng)”的線(xiàn)索。以最常見(jiàn)幾個(gè)碼為例停機(jī)碼錯(cuò)誤名參數(shù) 1 含義參數(shù) 4 常見(jiàn)含義0x0000001EKMODE_EXCEPTION_NOT_HANDLED未處理的異常碼異常發(fā)生地址0x0000000AIRQL_NOT_LESS_OR_EQUAL被引用的內(nèi)存地址觸發(fā)指令地址0x000000D1DRIVER_IRQL_NOT_LESS_OR_EQUAL被引用的內(nèi)存地址觸發(fā)指令地址0x00000050PAGE_FAULT_IN_NONPAGED_AREA被引用的虛擬地址0 內(nèi)核態(tài) / 1 用戶(hù)態(tài)0x00000133DPC_WATCHDOG_VIOLATION0 單次超時(shí) / 1 累計(jì)超時(shí)看門(mén)狗周期計(jì)數(shù)對(duì)0x0000001E真正有價(jià)值的是參數(shù) 1。當(dāng)它是0xC0000005時(shí)說(shuō)明發(fā)生了訪(fǎng)問(wèn)違例——某段代碼讀寫(xiě)了一個(gè)不屬于它的地址當(dāng)它是0x80000003時(shí)是斷點(diǎn)異常通常是驅(qū)動(dòng)里留了int 3沒(méi)清掉。同樣是0x0000001E這兩種情況的處理方向完全不同前者查驅(qū)動(dòng)與內(nèi)存后者查調(diào)試殘留。對(duì)0x0000000A和0x000000D1這一對(duì)兄弟參數(shù) 2 是出錯(cuò)時(shí)的 IRQL。IRQL 越高能訪(fǎng)問(wèn)的內(nèi)存越受限如果參數(shù) 2 顯示在DISPATCH_LEVEL以上還在碰分頁(yè)內(nèi)存基本可以鎖定是驅(qū)動(dòng)在錯(cuò)誤的中斷級(jí)別上調(diào)用了不該調(diào)用的函數(shù)。這類(lèi)判斷不需要反匯編看參數(shù)就能做。2.3 推薦操作與調(diào)試端口被忽略的兩行信息藍(lán)屏第二部分是“推薦操作”多數(shù)時(shí)候就是一句廢話(huà)——重啟。但偶爾它會(huì)給出很具體的方向比如提示去廠商站點(diǎn)更新固件、提示某個(gè)設(shè)備初始化失敗。這類(lèi)提示不要跳過(guò)它往往比停機(jī)碼更貼近具體機(jī)型。第三部分是調(diào)試端口信息告訴你有沒(méi)寫(xiě)內(nèi)存轉(zhuǎn)儲(chǔ)、有沒(méi)有通過(guò)串口或網(wǎng)絡(luò)把調(diào)試信息發(fā)到另一臺(tái)機(jī)器。這一段在實(shí)際排錯(cuò)里價(jià)值最高因?yàn)樗鼪Q定了你事后有沒(méi)有“黑匣子”可查。如果這里顯示轉(zhuǎn)儲(chǔ)被禁用或者寫(xiě)入失敗那你事后再怎么翻日志都拿不到完整現(xiàn)場(chǎng)只能靠系統(tǒng)日志里的邊角料推斷。我的一般做法是接手一臺(tái)頻繁藍(lán)屏的機(jī)器第一件事不是查碼而是確認(rèn)轉(zhuǎn)儲(chǔ)配置是否可用——系統(tǒng)盤(pán)有沒(méi)有開(kāi)頁(yè)面文件、轉(zhuǎn)儲(chǔ)類(lèi)型選的是小內(nèi)存轉(zhuǎn)儲(chǔ)還是內(nèi)核轉(zhuǎn)儲(chǔ)、自動(dòng)重啟關(guān)沒(méi)關(guān)。這三項(xiàng)不確認(rèn)后面所有分析都是碰運(yùn)氣。3. 停機(jī)碼映射表怎么讀同一個(gè) 0x00000050 為什么會(huì)有兩個(gè)答案資料后半部分那張幾百行的對(duì)照表是這份資源最容易用錯(cuò)的地方。很多人翻到80 0x0050 檔案已經(jīng)存在再看到藍(lán)屏上寫(xiě)著0x00000050就以為找到了答案——實(shí)際上兩者毫無(wú)關(guān)系。這一章專(zhuān)門(mén)把這件事講透因?yàn)楦悴磺宄@一點(diǎn)整張表都是負(fù)資產(chǎn)。3.1 先分清兩套編號(hào)STOP 碼與 Win32 錯(cuò)誤碼那張長(zhǎng)表里的編號(hào)是系統(tǒng) API 的錯(cuò)誤碼本質(zhì)上是NTSTATUS或 Win32 錯(cuò)誤碼的十進(jìn)制與十六進(jìn)制對(duì)照?！皺n案已經(jīng)存在”“磁盤(pán)已滿(mǎn)”“網(wǎng)絡(luò)名稱(chēng)重復(fù)”這些描述說(shuō)的是應(yīng)用程序調(diào)用系統(tǒng)接口失敗時(shí)返回的原因跟內(nèi)核崩潰不是一回事。藍(lán)屏上的停機(jī)碼是另一套編號(hào)體系雖然也用0x開(kāi)頭但取值范圍和語(yǔ)義完全不同。兩者撞號(hào)是必然的因?yàn)槎际?32 位數(shù)值空間。舉幾個(gè)必然踩到的例子數(shù)值在錯(cuò)誤碼表里的含義在藍(lán)屏里的含義0x00000050檔案已經(jīng)存在PAGE_FAULT_IN_NONPAGED_AREA0x0000007B文件名或卷標(biāo)語(yǔ)法錯(cuò)誤INACCESSIBLE_BOOT_DEVICE0x0000001E系統(tǒng)無(wú)法讀取指定的裝置KMODE_EXCEPTION_NOT_HANDLED0x0000000A環(huán)境不正確IRQL_NOT_LESS_OR_EQUAL區(qū)分方法很簡(jiǎn)單藍(lán)屏停機(jī)碼基本都在0x00000001到0x0000017F這個(gè)窄區(qū)間里而且總有一個(gè)全大寫(xiě)的錯(cuò)誤名跟著。如果你查到的解釋是一句生活化的中文短語(yǔ)、又沒(méi)有對(duì)應(yīng)的英文錯(cuò)誤名那八成查錯(cuò)了表。提示看到停機(jī)碼先找它旁邊的錯(cuò)誤名。有錯(cuò)誤名就以錯(cuò)誤名為準(zhǔn)檢索沒(méi)有錯(cuò)誤名才回頭用數(shù)字而且要明確加上“STOP”或“藍(lán)屏”限定詞。3.2 按「錯(cuò)誤名 → 責(zé)任方 → 動(dòng)作」三列檢索這張表最有效的用法不是當(dāng)字典查而是當(dāng)分類(lèi)器用。我在實(shí)際排錯(cuò)時(shí)會(huì)把停機(jī)碼歸成四類(lèi)責(zé)任方每類(lèi)對(duì)應(yīng)固定的動(dòng)作集合驅(qū)動(dòng)類(lèi)IRQL_NOT_LESS_OR_EQUAL、DRIVER_IRQL_NOT_LESS_OR_EQUAL、KMODE_EXCEPTION_NOT_HANDLED、SYSTEM_THREAD_EXCEPTION_NOT_HANDLED、DPC_WATCHDOG_VIOLATION。動(dòng)作是回滾近期驅(qū)動(dòng)、安全模式下逐個(gè)禁用非系統(tǒng)服務(wù)。內(nèi)存與存儲(chǔ)類(lèi)PAGE_FAULT_IN_NONPAGED_AREA、KERNEL_DATA_INPAGE_ERROR、UNMOUNTABLE_BOOT_VOLUME、NTFS_FILE_SYSTEM。動(dòng)作是先測(cè)內(nèi)存條、再查磁盤(pán)健康與數(shù)據(jù)線(xiàn)。硬件與固件類(lèi)WHEA_UNCORRECTABLE_ERROR、MACHINE_CHECK_EXCEPTION、CLOCK_WATCHDOG_TIMEOUT。動(dòng)作是查供電、散熱、插槽接觸軟件層幾乎無(wú)解。啟動(dòng)與配置類(lèi)INACCESSIBLE_BOOT_DEVICE、BAD_SYSTEM_CONFIG_INFO、CRITICAL_PROCESS_DIED。動(dòng)作是查存儲(chǔ)控制器模式、引導(dǎo)配置、系統(tǒng)文件完整性。這個(gè)分法的好處是即使你手上的碼表沒(méi)收錄某個(gè)冷門(mén)停機(jī)碼只要錯(cuò)誤名里有關(guān)鍵詞DRIVER、PAGE_FAULT、WHEA、BOOT也能大致歸位。錯(cuò)誤名的命名是有規(guī)律的前綴往往就寫(xiě)著責(zé)任方。3.3 把高頻停機(jī)碼做成自己的前二十條資料里那張表覆蓋很全但全不等于好用。真到現(xiàn)場(chǎng)翻幾百行找一條的效率極低。我的習(xí)慣是先從表里篩出二十條高頻的抄成一頁(yè)紙貼在工位上剩下的冷門(mén)碼需要時(shí)再查。這二十條的篩選標(biāo)準(zhǔn)不是“出現(xiàn)次數(shù)最多”而是“出現(xiàn)后動(dòng)作差異最大”——?jiǎng)幼饕粯拥拇a歸并成一條就行。比如0x0000000A和0x000000D1動(dòng)作幾乎一致可以合并0x0000007B和0x000000ED都指向引導(dǎo)鏈路也可以合并但0x00000124必須單獨(dú)拎出來(lái)因?yàn)樗坏┏霈F(xiàn)軟件層的所有手段都是浪費(fèi)時(shí)間直接轉(zhuǎn)硬件檢測(cè)。這張精簡(jiǎn)表的價(jià)值在于縮短決策路徑而不是覆蓋全面。順帶說(shuō)一句資料里那張長(zhǎng)表對(duì)排查應(yīng)用程序崩潰、服務(wù)啟動(dòng)失敗其實(shí)很有用——1053 服務(wù)沒(méi)有及時(shí)響應(yīng)啟動(dòng)或控制請(qǐng)求、1067 進(jìn)程意外終止這些都是運(yùn)維日常會(huì)撞上的。所以這份資源的正確姿勢(shì)是把它當(dāng)兩本書(shū)用藍(lán)屏看停機(jī)碼那一套服務(wù)和應(yīng)用報(bào)錯(cuò)看錯(cuò)誤碼那一套別混著來(lái)。4. 九步處置流程從重啟到補(bǔ)丁哪幾步可以跳過(guò)資料給出的九條處置辦法本身沒(méi)問(wèn)題但順序是并列的實(shí)際排錯(cuò)時(shí)不能照抄。真正有效的流程是收斂式的每一步都要縮小嫌疑范圍而不是把九件事都做一遍。下面把它重排成一條有依賴(lài)關(guān)系的路徑。4.1 第一步永遠(yuǎn)是取證不是重啟重啟能讓機(jī)器恢復(fù)但會(huì)摧毀現(xiàn)場(chǎng)。所以在按下重啟之前先把能記的都記下來(lái)停機(jī)碼、括號(hào)里四個(gè)參數(shù)、錯(cuò)誤名、屏幕上提到的驅(qū)動(dòng)文件名如果有.sys字樣。有條件就拍照人眼記十六進(jìn)制數(shù)極不可靠。然后確認(rèn)轉(zhuǎn)儲(chǔ)配置。三條命令分別對(duì)應(yīng)“關(guān)自動(dòng)重啟”“設(shè)內(nèi)核內(nèi)存轉(zhuǎn)儲(chǔ)”“確認(rèn)轉(zhuǎn)儲(chǔ)目錄”:: 關(guān)閉藍(lán)屏后自動(dòng)重啟讓屏幕停住 reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /v AutoReboot /t REG_DWORD /d 0 /f :: 轉(zhuǎn)儲(chǔ)類(lèi)型0 無(wú) 1 完整 2 內(nèi)核 3 小內(nèi)存轉(zhuǎn)儲(chǔ) 7 自動(dòng) reg add HKLM\SYSTEM\CurrentControlSet\Control\CrashControl /v CrashDumpEnabled /t REG_DWORD /d 2 /f :: 查看已有的小內(nèi)存轉(zhuǎn)儲(chǔ)文件按時(shí)間倒序 dir /o-d %SystemRoot%\Minidump\*.dmp參數(shù)說(shuō)明AutoReboot置 0 是讓人能看清屏幕CrashDumpEnabled選 2內(nèi)核轉(zhuǎn)儲(chǔ)是折中方案文件大小約為物理內(nèi)存的三分之一到二分之一比完整轉(zhuǎn)儲(chǔ)省空間又比小轉(zhuǎn)儲(chǔ)信息全。小內(nèi)存轉(zhuǎn)儲(chǔ)值 3只有幾百 KB夠看停機(jī)碼和調(diào)用棧但看不到完整內(nèi)存完整轉(zhuǎn)儲(chǔ)值 1在內(nèi)存 32GB 的機(jī)器上會(huì)寫(xiě)出一個(gè)巨大的文件日常排錯(cuò)沒(méi)必要。改完這兩項(xiàng)必須重啟才生效。很多人改完直接等下一次藍(lán)屏結(jié)果發(fā)現(xiàn)配置沒(méi)落地白等一場(chǎng)。4.2 安全模式、最后一次正確配置與驅(qū)動(dòng)回滾資料里提到的“最后一次正確配置”在較老的系統(tǒng)上是 F8 高級(jí)啟動(dòng)菜單里的選項(xiàng)作用是回滾到上一次成功啟動(dòng)時(shí)的注冊(cè)表與驅(qū)動(dòng)配置集合。這個(gè)功能對(duì)“裝完某個(gè)驅(qū)動(dòng)就開(kāi)始藍(lán)屏”的場(chǎng)景幾乎是特效藥因?yàn)樗貪L的是整組配置不只是單個(gè)驅(qū)動(dòng)。操作路徑開(kāi)機(jī)自檢后連按 F8 → 高級(jí)啟動(dòng)選項(xiàng) → 最后一次正確配置。新版系統(tǒng)的入口變了通常在設(shè)置里的恢復(fù)選項(xiàng)、或者開(kāi)機(jī)失敗幾次后自動(dòng)進(jìn)入的恢復(fù)界面中能找到“啟動(dòng)修復(fù)”和“系統(tǒng)還原”。如果回滾后問(wèn)題消失說(shuō)明嫌疑鎖定在最近變更的驅(qū)動(dòng)或服務(wù)上。這時(shí)候不要急著慶祝要做的是把這個(gè)變更找出來(lái)記下來(lái)最近三天裝了什么驅(qū)動(dòng)、什么安全軟件、什么帶內(nèi)核態(tài)組件的工具。殺毒軟件、虛擬化軟件、外設(shè)驅(qū)動(dòng)這三類(lèi)是重災(zāi)區(qū)因?yàn)樗鼈兌纪鶅?nèi)核里塞東西。安全模式的價(jià)值在于提供一個(gè)最小驅(qū)動(dòng)集環(huán)境。進(jìn)去之后可以做的事卸載可疑驅(qū)動(dòng)、禁用非必要的自啟動(dòng)服務(wù)、用系統(tǒng)自帶的驅(qū)動(dòng)回滾功能退回到上一版本。判斷標(biāo)準(zhǔn)很簡(jiǎn)單——安全模式不藍(lán)屏、正常啟動(dòng)藍(lán)屏那問(wèn)題幾乎必定在第三方驅(qū)動(dòng)或服務(wù)上。4.3 事件查看器與轉(zhuǎn)儲(chǔ)文件把黑匣子打開(kāi)資料里給的EventVwr.msc路徑是對(duì)的但光打開(kāi)看不夠得知道找哪幾條記錄。命令行拉取更快# 拉取最近 20 條關(guān)鍵系統(tǒng)事件意外關(guān)機(jī)、內(nèi)核電源、藍(lán)屏記錄 Get-WinEvent -FilterHashtable { LogName System Id 41, 1001, 6008 } -MaxEvents 20 -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, ProviderName, {nMsg;e{$_.Message.Substring(0,[Math]::Min(120,$_.Message.Length))}} | Format-Table -AutoSize事件 ID 的含義要記牢41是內(nèi)核電源表示系統(tǒng)沒(méi)有正常關(guān)機(jī)就重啟了不一定是藍(lán)屏也可能是斷電或死機(jī)1001是藍(lán)屏記錄里面帶著停機(jī)碼和四個(gè)參數(shù)是查碼最直接的證據(jù)6008是上一次關(guān)機(jī)是意外的。三條一起看能判斷出“到底藍(lán)屏了幾次、每次是什么碼”。轉(zhuǎn)儲(chǔ)文件本身需要工具打開(kāi)命令行解決不了得用內(nèi)核調(diào)試器加載MEMORY.DMP或用輕量的轉(zhuǎn)儲(chǔ)查看工具讀Minidump目錄下的.dmp。重點(diǎn)看兩處一是BugCheck那一行確認(rèn)碼值二是調(diào)用棧里第一個(gè)非系統(tǒng)模塊的名字。棧頂如果是ntoskrnl.exe之類(lèi)的系統(tǒng)組件往下翻兩層真正的肇事者通常在第三到第五層。這一步是整條鏈路上信息密度最高的環(huán)節(jié)也是最容易被跳過(guò)的。跳過(guò)它的代價(jià)是你只能靠猜和試而試錯(cuò)成本遠(yuǎn)高于裝一個(gè)調(diào)試工具。4.4 硬件、BIOS 與存儲(chǔ)控制器模式資料里把新硬件、BIOS、硬件兼容性列成三條其實(shí)是一件事的三個(gè)面。先把物理層排除掉內(nèi)存條重插、換插槽、單條輪流測(cè)硬盤(pán)數(shù)據(jù)線(xiàn)和電源線(xiàn)換一根獨(dú)顯拔了用核顯跑一天。這些動(dòng)作看著土但能排掉相當(dāng)比例的“查不出原因的藍(lán)屏”。存儲(chǔ)控制器模式是0x0000007B的經(jīng)典成因。BIOS 里 SATA 模式在 AHCI 與 IDE/RAID 之間切換過(guò)或者換主板后設(shè)置不一致系統(tǒng)引導(dǎo)時(shí)加載不了對(duì)應(yīng)的存儲(chǔ)驅(qū)動(dòng)直接藍(lán)屏。解決辦法是改回原來(lái)的模式或者在系統(tǒng)里提前注入對(duì)應(yīng)驅(qū)動(dòng)再切換。這個(gè)坑在遷移系統(tǒng)盤(pán)、更換主板時(shí)幾乎必踩。BIOS 更新要謹(jǐn)慎。資料說(shuō)“升級(jí)到最新版本”但實(shí)際經(jīng)驗(yàn)是只在明確查到“該型號(hào)該版本的 BIOS 修復(fù)了某類(lèi)兼容性問(wèn)題”時(shí)才升。盲目刷最新版的風(fēng)險(xiǎn)是刷錯(cuò)型號(hào)直接變磚或者新版 BIOS 改了默認(rèn)的內(nèi)存時(shí)序?qū)е略痉€(wěn)定的機(jī)器開(kāi)始隨機(jī)藍(lán)屏。注意動(dòng) BIOS 之前先記下當(dāng)前版本號(hào)和主要設(shè)置項(xiàng)尤其是存儲(chǔ)模式、內(nèi)存頻率、虛擬化開(kāi)關(guān)這三項(xiàng)。這是唯一的后悔藥。5. 避坑與排查五個(gè)把藍(lán)屏越修越亂的操作這一章記錄的是實(shí)打?qū)嵎^(guò)的車(chē)。每一條都按“現(xiàn)象 → 原因 → 解決”寫(xiě)看的時(shí)候?qū)φ兆约菏稚系臋C(jī)器。5.1 記錄與查詢(xún)階段的三個(gè)坑坑一把錯(cuò)誤碼表當(dāng)成停機(jī)碼表查?，F(xiàn)象藍(lán)屏顯示0x00000050翻資料里的長(zhǎng)表查到“檔案已經(jīng)存在”然后開(kāi)始懷疑某個(gè)文件被占用折騰半天毫無(wú)進(jìn)展。原因這張長(zhǎng)表是系統(tǒng) API 錯(cuò)誤碼和內(nèi)核停機(jī)碼是兩套編號(hào)體系撞號(hào)純屬數(shù)值空間重疊。前面第 3 章已經(jīng)列過(guò)四個(gè)撞號(hào)例子實(shí)際撞上的概率不低。解決拿到碼先看旁邊有沒(méi)有全大寫(xiě)的錯(cuò)誤名。有就按錯(cuò)誤名查沒(méi)有就用“STOP 碼值”作為檢索詞并在結(jié)果里核對(duì)錯(cuò)誤名是否匹配。查到的解釋如果是一句生活化的中文短句、沒(méi)有英文名對(duì)應(yīng)立刻判定為查錯(cuò)表?？佣挥浲C(jī)碼不記括號(hào)里的參數(shù)?，F(xiàn)象0x0000001E查出來(lái)一堆互相矛盾的答案有人說(shuō)內(nèi)存壞了有人說(shuō)驅(qū)動(dòng)沖突無(wú)法判斷該信哪個(gè)。原因0x0000001E這個(gè)類(lèi)別只說(shuō)明“內(nèi)核態(tài)有異常沒(méi)被處理”具體是訪(fǎng)問(wèn)違例、斷點(diǎn)、還是非法指令全在參數(shù) 1 里。參數(shù)不帶等于把一道多選題的選項(xiàng)全丟了。解決拍照或者抄全整行包括括號(hào)里四個(gè)數(shù)和錯(cuò)誤名。判斷時(shí)先看參數(shù) 10xC0000005是訪(fǎng)問(wèn)違例往驅(qū)動(dòng)和內(nèi)存方向查0x80000003是斷點(diǎn)往調(diào)試殘留查0xC000009A是資源不足往句柄和內(nèi)存池查。這一步花三十秒能省掉兩小時(shí)試錯(cuò)?？尤{(lán)屏一閃而過(guò)什么都沒(méi)留下?，F(xiàn)象機(jī)器自動(dòng)重啟進(jìn)系統(tǒng)后事件查看器里只有一條“意外關(guān)機(jī)”轉(zhuǎn)儲(chǔ)目錄是空的無(wú)從下手。原因自動(dòng)重啟沒(méi)關(guān)同時(shí)頁(yè)面文件被關(guān)掉或者放在非系統(tǒng)盤(pán)小內(nèi)存轉(zhuǎn)儲(chǔ)寫(xiě)不出來(lái)。還有一種情況是系統(tǒng)盤(pán)剩余空間不足寫(xiě)入失敗。解決先按 4.1 的兩條注冊(cè)表命令關(guān)掉自動(dòng)重啟、開(kāi)啟內(nèi)核轉(zhuǎn)儲(chǔ)確認(rèn)系統(tǒng)盤(pán)頁(yè)面文件為系統(tǒng)管理大小且剩余空間充足然后重啟生效。改完做一次驗(yàn)證手動(dòng)觸發(fā)一次崩潰不建議在生產(chǎn)力機(jī)器上做確認(rèn)%SystemRoot%\Minidump下真的出現(xiàn)了文件。沒(méi)驗(yàn)證過(guò)的配置等于沒(méi)配。5.2 處置階段的三個(gè)坑坑四上來(lái)就重裝系統(tǒng)?，F(xiàn)象重裝后安靜了兩周同樣的藍(lán)屏再次出現(xiàn)而且這次連錯(cuò)誤名都一樣。原因重裝只換了軟件層硬件層的劣化內(nèi)存顆粒不穩(wěn)、電源供電不足、散熱不良、主板電容老化原封不動(dòng)。隨機(jī)性藍(lán)屏里硬件占比不低尤其是那種“一天一次、時(shí)間不固定、負(fù)載高時(shí)更容易”的模式。解決先做硬件隔離再考慮重裝。內(nèi)存用系統(tǒng)自帶的內(nèi)存診斷工具跑一遍完整檢測(cè)要跑重啟后那一檔不是快速版硬盤(pán)看健康狀態(tài)和重分配扇區(qū)計(jì)數(shù)電源和散熱靠觀察——高負(fù)載時(shí)是否更容易崩。硬件沒(méi)排除就重裝等于給自己制造“問(wèn)題已解決”的錯(cuò)覺(jué)?？游逵玫谌焦ぞ吲扛买?qū)動(dòng)?，F(xiàn)象本來(lái)一天藍(lán)屏一次批量更新驅(qū)動(dòng)之后變成開(kāi)機(jī)就藍(lán)屏連安全模式都進(jìn)得磕磕絆絆。原因批量驅(qū)動(dòng)工具給你裝的未必是這顆芯片對(duì)應(yīng)的版本尤其是顯卡、網(wǎng)卡、存儲(chǔ)控制器這三類(lèi)。顯卡驅(qū)動(dòng)裝錯(cuò)版本導(dǎo)致0x0000001E或0x00000116的情況非常常見(jiàn)。更麻煩的是有些工具會(huì)順手裝一堆帶內(nèi)核組件的“優(yōu)化”程序。解決驅(qū)動(dòng)只從硬件廠商按具體型號(hào)下載一臺(tái)上裝完觀察一天再動(dòng)下一臺(tái)。已經(jīng)翻車(chē)的進(jìn)安全模式用設(shè)備管理器回滾驅(qū)動(dòng)或者用系統(tǒng)還原點(diǎn)退回去。日常維護(hù)的話(huà)把“驅(qū)動(dòng)不是越新越好”當(dāng)鐵律穩(wěn)定版本沒(méi)出問(wèn)題就不要?jiǎng)印Ｌ崾救绻慌_(tái)機(jī)器在裝完某個(gè)外設(shè)驅(qū)動(dòng)后開(kāi)始藍(lán)屏哪怕藍(lán)屏碼看起來(lái)跟這個(gè)外設(shè)毫無(wú)關(guān)系也優(yōu)先懷疑它。內(nèi)核里的問(wèn)題經(jīng)常在最不相干的地方表現(xiàn)出來(lái)。6. 把速查表變成本地工具一條腳本加一個(gè)復(fù)盤(pán)習(xí)慣翻表這件事做得多了就會(huì)煩。尤其是手上機(jī)器多的時(shí)候每次都要開(kāi)文檔、找碼、對(duì)錯(cuò)誤名效率很低。我的做法是把最常用的那二十來(lái)?xiàng)l停機(jī)碼固化成一張哈希表再寫(xiě)一小段腳本直接從系統(tǒng)日志里把歷史上所有藍(lán)屏記錄撈出來(lái)自動(dòng)查表輸出。這樣一臺(tái)機(jī)器接手十分鐘內(nèi)就能拿到它的“藍(lán)屏履歷”。# 高頻停機(jī)碼表碼值 - 錯(cuò)誤名 處置方向 $stopMap { 0x0000000a { Name IRQL_NOT_LESS_OR_EQUAL; Hint 驅(qū)動(dòng)在高 IRQL 訪(fǎng)問(wèn)分頁(yè)內(nèi)存先回滾近期驅(qū)動(dòng) } 0x0000001e { Name KMODE_EXCEPTION_NOT_HANDLED; Hint 看參數(shù)1的異常碼0xC0000005 即訪(fǎng)問(wèn)違例 } 0x00000050 { Name PAGE_FAULT_IN_NONPAGED_AREA; Hint 非法地址被引用查內(nèi)存條與驅(qū)動(dòng) } 0x0000007b { Name INACCESSIBLE_BOOT_DEVICE; Hint 存儲(chǔ)控制器驅(qū)動(dòng)或 BIOS 里的 SATA 模式被改過(guò) } 0x000000d1 { Name DRIVER_IRQL_NOT_LESS_OR_EQUAL; Hint 某驅(qū)動(dòng)越界訪(fǎng)問(wèn)參數(shù)4指向出錯(cuò)指令地址 } 0x00000124 { Name WHEA_UNCORRECTABLE_ERROR; Hint 硬件級(jí)報(bào)錯(cuò)先查內(nèi)存/供電/散熱軟件層無(wú)解 } 0x00000133 { Name DPC_WATCHDOG_VIOLATION; Hint 某驅(qū)動(dòng) DPC 超時(shí)常見(jiàn)于存儲(chǔ)驅(qū)動(dòng)與固件 } } # 抓取藍(lán)屏事件ID 1001提取停機(jī)碼后查表 Get-WinEvent -FilterHashtable { LogName System; Id 1001 } -MaxEvents 50 -ErrorAction SilentlyContinue | ForEach-Object { if ($_.Message -match 0x[0-9a-fA-F]{8}) { $code $Matches[0].ToLower() $item $stopMap[$code] [pscustomobject]{ Time $_.TimeCreated Code $code Name if ($item) { $item.Name } else { 未收錄 } Hint if ($item) { $item.Hint } else { 去官方知識(shí)庫(kù)按錯(cuò)誤名檢索 } } } } | Sort-Object Time -Descending | Format-Table -AutoSize邏輯說(shuō)明Get-WinEvent用哈希表過(guò)濾只取系統(tǒng)日志里 ID 為 1001 的記錄這是內(nèi)核寫(xiě)完轉(zhuǎn)儲(chǔ)后固定會(huì)寫(xiě)的一條。每條記錄的Message里帶著形如0x0000000a (0x..., ...)的文本用正則抓第一個(gè)八位十六進(jìn)制數(shù)就是停機(jī)碼。查不到表里就輸出“未收錄”提示回去按錯(cuò)誤名檢索而不是硬套一個(gè)答案。參數(shù)上可以調(diào)的只有-MaxEvents我一般設(shè) 50夠覆蓋幾個(gè)月的歷史機(jī)器老、日志滾動(dòng)快的話(huà)可以調(diào)大但沒(méi)必要超過(guò) 200再往前翻價(jià)值不大。跑出來(lái)的結(jié)果比單看一條有用得多。如果同一臺(tái)機(jī)器反復(fù)出現(xiàn)同一個(gè)碼那是穩(wěn)定的軟件沖突如果碼值五花八門(mén)、錯(cuò)誤名橫跨驅(qū)動(dòng)類(lèi)與硬件類(lèi)那基本可以判定是內(nèi)存或供電問(wèn)題直接轉(zhuǎn)硬件檢測(cè)別再逐條查碼。這個(gè)判斷單看一次藍(lán)屏是做不出來(lái)的必須靠履歷。最后說(shuō)個(gè)血淚教訓(xùn)。早些年我修一臺(tái)隨機(jī)藍(lán)屏的機(jī)器查了四次碼換了兩次驅(qū)動(dòng)重裝了一遍系統(tǒng)前后折騰了一周最后發(fā)現(xiàn)是內(nèi)存條金手指氧化。從那以后我給自己定了個(gè)死規(guī)矩任何隨機(jī)性藍(lán)屏先跑完內(nèi)存診斷、拔插一遍內(nèi)存和硬盤(pán)線(xiàn)再碰軟件。這個(gè)順序看著笨但它把最容易忽略的一層放在了最前面省下的時(shí)間比任何技巧都多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取