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