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