電腦瞓醒就藍屏：喚醒嗰刻先出事，點分驅動程式定硬件問題

引言：瞓醒嗰刻先藍屏，係一個好具體嘅線索

好多藍屏文章一開口就列晒所有可能原因：驅動程式、記憶體、硬碟、系統檔案損毀——讀者睇完都唔知由邊度入手。但係如果你嘅情況係「平時用得好哋哋，瞓醒嗰刻先藍屏」，呢個時刻本身已經將範圍縮細咗：問題好大機會出喺喚醒呢個過程——某個裝置或者驅動程式喺電源狀態轉換嗰陣未能及時回應，系統於是停止運作。呢篇專講呢個時刻：第一節藍屏之後先做嘅三件事；第二節分三種情況；第三節喚醒鏈排查；第四節睡眠、休眠同快速啟動嘅分別；第五節驅動程式排查嘅次序同紀律；第六節停用睡眠做臨時措施嘅利弊；第七節幾時停手送檢。價錢口徑先講明：檢測同維修收費視乎機型同工作範圍，一律檢測後報價，呢篇唔寫任何具體金額、成功率或者保證。

先分清楚呢篇同另一篇睡眠文章嘅界線，免得讀者對錯篇：之前嗰篇《電腦瞓咗醒唔返、半夜自己醒》講嘅係「醒唔返」同「自己醒」兩條線；呢篇講嘅係第三種情況——部機醒得返，但係醒嗰刻就藍屏。醒唔返同醒到但藍屏，排查方向唔同，唔好撈埋一齊處理。藍屏總論見《Windows 藍屏》。

仲有一個現實要先講明：好多讀者撞到藍屏嗰陣，根本冇抄低停止代碼——畫面一閃即過，部機已經自動重新啟動。呢篇唔會假設你已經抄低代碼，排查次序會由「記唔記得代碼」呢個現實出發：記得就由代碼起步，唔記得就由發生情境同事件記錄起步，一樣行得通。

第一節：藍屏之後先做三件事——唔好即刻亂改設定

藍屏之後最常見嘅錯誤反應，係即刻上網搵「一鍵修復」、一次過更新幾個驅動程式、一次過改幾個電源設定——結果好轉定惡化都唔知邊樣起作用，仲可能洗走咗判斷用嘅證據。正確次序係先做以下三件事，全部都係「保存」而唔係「改」。

第一件：記低發生情境。幾時發生：由睡眠喚醒、由休眠喚醒、定係合蓋再開？點樣喚醒：開蓋、㩒電源掣、郁滑鼠、㩒鍵盤？喚醒之前接住乜嘢：外接 mon、USB-C 擴充座、外置硬碟、USB 無線網絡卡？最近有冇改過嘢：Windows 更新、驅動程式更新、新裝軟件、新接裝置？喚醒之後幾秒出事，之後係咪自動重新啟動，重新啟動之後係咪回復正常？呢啲就係之後排查嘅時間線，寫低佢，唔好靠記憶。

第二件：盡快備份重要資料。重複藍屏期間，未儲存嘅工作隨時會再唔見。趁部機回復正常嗰陣，先將最重要嘅檔案抄去第二個地方，之後先至慢慢排查。備份先、排查後，呢個次序唔可以調轉——排查嗰陣做嘅任何改動（更新驅動程式、改電源設定、執行磁碟檢查）本身都有風險，冇備份就做，等於冇安全網咁行鋼線。

第三件：保存診斷證據。如果記得停止代碼名稱（例如 DRIVER_POWER_STATE_FAILURE）同埋有冇顯示相關檔案名稱，記低佢。唔記得都唔緊要：Windows 事件檢視器入面，Windows 記錄 → 系統，搵來源為 BugCheck、事件識別碼為 1001 嘅錯誤，入面有停止代碼同十六進位數值。小型傾印檔案喺 C:WindowsMinidump，完整傾印檔案喺 C:WindowsMEMORY.DMP；分析之前先備份傾印檔案副本，因為之後嘅當機可能會覆蓋舊檔案。點解要咁做？因為傾印分析入面顯示嘅驅動程式名稱只係線索，唔係定罪證據——顯示卡驅動程式名稱出現，唔等於顯示卡一定壞，顯示卡硬件、電源供應、記憶體等其他問題都可以令驅動程式出錯。保存證據先，之後先至慢慢對照，見第四節同第五節。

第二節：分三種情況——間中、次次、連開機都唔穩定

喚醒藍屏首先要分三種情況，因為三種情況嘅迫切程度同排查起點都唔同。第一種：間中先出事。幾個月先一次，或者某次更新之後先出現一次，之後又回復正常。呢種多數同某次改動或者某個裝置嘅偶發電源轉換超時有關，值得記錄同觀察，唔使即刻大動作。間中先出事嘅藍屏排查，見《間中先出事嘅藍屏》，思路相通。第二種：每次喚醒都出事。每次瞓醒都藍屏，或者每次合蓋再開都藍屏，但係㩒電源掣喚醒又冇事——呢種規律性本身就係證據，指向某個特定喚醒方式或者某個裝置（見第三節）。第三種：喚醒後連開機都唔穩定。藍屏之後自動重新啟動，跟住又藍屏，或者正常開機都開始出事——呢種已經超出「喚醒時刻」嘅範圍，偏向更廣泛嘅系統或者硬件問題，應該盡快備份同送檢，唔好再自己逐樣試。開機循環嘅處理見《藍屏開機循環》，但要講清楚：喚醒藍屏同開機循環係兩種情況，唔好混為一談。

第三節：喚醒鏈排查——邊個叫醒部機，邊個喺喚醒嗰刻失靈

「喚醒鏈」呢個概念係呢篇嘅主線：由瞓之前接住乜嘢、點樣喚醒、喚醒後幾秒出事，呢幾個觀察點起步，逐項隔離，搵出邊個環節喺喚醒嗰刻失靈。排查紀律只有一句：一次只改一樣，改完測試一次，記低結果。同時更新幾個驅動程式、同時改幾個電源設定，出事定好轉都唔知邊樣起作用。

第一步：拔除外接裝置再試。USB-C 擴充座、外置硬碟、USB 無線網絡卡、集線器、藍牙裝置、外接 mon，全部都需要在睡眠同喚醒嗰陣正確協調電源狀態，任何一個協調失敗都可以觸發藍屏。先移除所有非必要外接裝置，測試睡眠同喚醒係咪仲藍屏；如果停咗，再逐一接返去，逐一測試——「逐一」呢兩個字好重要，一次過全部接返，永遠唔會知邊個先係真兇。香港用家特別要注意嘅情境：手提電腦日頭喺公司接住擴充座同外接 mon 用，夜晚返到屋企又接另一套裝置，兩邊裝置唔同，喚醒表現都可以唔同——測試嗰陣要講明自己係邊套裝置出事，唔好將公司同屋企嘅情況撈埋。仲有兩個值得懷疑嘅方向：冇獨立供電嘅平價集線器喺睡眠期間可能無法維持足夠電壓，令喚醒嗰陣裝置狀態不一致；喚醒之後擴充座上面嘅裝置未能被系統重新認到，亦係相關症狀——兩樣都只係懷疑方向，唔可以斷言某款集線器一定有問題，呢篇亦唔會點名任何品牌或者型號。

第二步：試唔同喚醒方式。每次合蓋再開都藍屏，但㩒電源掣喚醒又冇事——呢個對比本身就係證據，指向合蓋設定或者某個同開蓋相關嘅裝置；反過嚟，每種喚醒方式都藍屏，就偏向系統層面（驅動程式、快速啟動、休眠檔案）而唔係某個喚醒裝置。仲有一個邊緣情境值得留意：啱啱喚醒又即刻再入睡眠，系統未完成喚醒就再入待命，可能觸發衝突——呢個機制見於公開討論，尚待以微軟官方文件核實，呢篇只係將佢列為值得觀察嘅可能性，唔寫成定論。

第三步：對時間線。藍屏係咪喺某次 Windows 更新、驅動程式更新、新裝軟件、新接裝置之後先開始？可靠性監視器可以按時間線顯示每次當機、同當機前安裝或者更新嘅項目，幫手判斷藍屏係咪同某次改動同時出現。如果藍屏喺更新之後先開始，更新後先出藍屏嘅判斷見《更新後藍屏》；但係要小心：時間上同時出現唔等於因果關係，更新可能只係令原本已經有問題嘅驅動程式喺喚醒嗰刻暴露出嚟。

第四步：先至到驅動程式同系統層面。外接裝置同喚醒方式都排除晒，先至入第五節嘅驅動程式排查。呢個次序嘅原因好實際：外接裝置測試唔使錢、唔傷資料、可逆；驅動程式改動同系統檢查就牽涉較大，應該留後。

第四節：睡眠、休眠、快速啟動——三樣嘢點解會影響喚醒

好多人將睡眠、休眠、快速啟動、關機撈埋一齊，其實佢哋對部機嘅意義完全唔同，揀錯會令問題睇落更亂。睡眠係將工作階段保留喺記憶體，耗電較低但仲需要少量電力，喚醒最快，但斷電就會唔見晒未儲存嘅嘢。休眠係將記憶體內容寫入硬碟上嘅休眠檔案 hiberfil.sys，然後幾乎完全斷電，喚醒嗰陣再讀返，慢啲但斷電都唔會唔見嘢。快速啟動係關機嗰陣登出用戶工作階段，但將 Windows 核心休眠至 hiberfil.sys，下次開機嗰陣讀返核心去加快開機。關鍵一點：即使你從來冇手動按過休眠，只要快速啟動開住，系統仍然會用 hiberfil.sys。

點解呢啲設定會同喚醒藍屏有關？因為喚醒本身就係一次電源狀態轉換：每個裝置嘅驅動程式都要喺預期時間內由低功耗狀態返去正常狀態，任何一個驅動程式未能及時回應，系統就可能停止運作。其中一種最常見嘅喚醒藍屏就係 DRIVER_POWER_STATE_FAILURE，停止代碼 0x0000009F——機制就係 Windows 要求某個裝置或者驅動程式轉換電源狀態嗰陣，驅動程式未能喺預期時間內正確回應。常見相關驅動程式類別包括儲存裝置（SATA 或者 NVMe）、晶片組、顯示卡、網絡卡、USB 裝置。但係要講清楚：0x9F 只係其中一種喚醒藍屏，唔可以將所有喚醒藍屏都寫成 0x9F，其他停止代碼有唔同成因，必須先讀取實際代碼再對照。

休眠檔案嘅數字要小心寫：完整檔案預設大約為實體記憶體嘅 40%，精簡檔案預設大約為 20% 並且只支援快速啟動——兩個數字都要加「預設大約為」，因為實際大小視乎設定而定。關閉休眠嘅指令係以系統管理員身份執行 powercfg /hibernate off，呢個指令會刪除 hiberfil.sys，同時停用休眠、混合睡眠同快速啟動。只關快速啟動而唔關休眠嘅方法係：控制台 → 電源選項 → 選擇電源按鈕嘅功能 → 變更目前無法使用嘅設定 → 取消勾選「開啟快速啟動」。呢兩個動作嘅取捨必須一齊講：關閉休眠之後，如果手提電腦喺睡眠嗰陣電池耗盡，又冇休眠做後備，未儲存嘅工作階段保護會減少。千祈唔好直接刪除 hiberfil.sys 檔案，必須用 powercfg 指令處理。仲有一點要講明：唔好寫「刪除休眠檔案可以延長固態硬碟壽命幾多」呢類具體數字——唔同使用習慣嘅寫入量差異極大，寫唔出一個可靠數字。

現代待命（Modern Standby）要提一句，但係要寫得保守：部分新款手提電腦採用較進取嘅現代待命設定，令電源轉換時序更嚴格，可能增加驅動程式超時嘅機會——呢個只係「部分機型可能」，唔可以寫成所有新機嘅通病，個別機型嘅睡眠模式要按型號核實。

第五節：驅動程式排查嘅次序同紀律

入到驅動程式層面，次序同紀律比技術本身更重要。原則係：先到電腦廠商或者裝置廠商官方網站下載對應型號嘅驅動程式，唔好只依賴第三方驅動程式更新工具，更加唔好安裝來歷不明、聲稱可以一鍵修復藍屏嘅軟件。排查次序建議如下，每做一步就測試一次睡眠同喚醒，記低結果：

第一步：關閉快速啟動作測試。用第四節嘅方法取消勾選「開啟快速啟動」，然後重新啟動並測試睡眠同喚醒。如果藍屏停咗，線索就指向快速啟動同休眠檔案嗰邊；但係要講清楚，關閉快速啟動只係測試同臨時措施，唔等於已經修好根本原因——見第六節。第二步：更新或者回復驅動程式。先更新顯示卡、晶片組、網絡卡、儲存裝置驅動程式；如果藍屏喺某次更新之後先出現，可以考慮回復至上一個驅動程式版本。一次只改一個驅動程式，改完測試，唔好一次過更新晒。第三步：執行系統檔案檢查。以系統管理員身份執行 sfc /scannow，之後可以再執行 DISM /Online /Cleanup-Image /RestoreHealth——要講明呢兩個指令嘅用途係修復系統檔案，唔係「清理」或者「加速」工具。第四步：檢查 Windows 更新同 BIOS 或者韌體更新。BIOS 更新必須謹慎：只有喺有明確需要同正確指引之下先至進行，因為更新失敗可能令電腦無法開機，呢個警告一定要保留，唔可以將 BIOS 更新寫成安全或者簡單嘅步驟。第五步：懷疑記憶體或者磁碟嗰陣，可以執行 Windows 記憶體診斷同磁碟檢查（chkdsk），但係執行之前必須備份重要資料。呢五步做完都未解決，或者藍屏伴隨磁碟異常緩慢、開機失敗、檔案損毀等情況，就應該安排進一步硬件檢查，而唔係反覆重裝驅動程式或者重裝系統。

仲有三樣嘢絕對唔好做。第一，唔好喺未記錄停止代碼同傾印資料之前就即刻重裝 Windows——重裝會清除有用嘅診斷線索，而且如果根源係硬件或者某個外接裝置，重裝完一樣會再出事。第二，唔好憑 Minidump 顯示嘅驅動程式名稱就寫「肯定係嗰件硬件壞咗」——傾印入面嘅模組名稱只係線索，唔係定罪證據，最終判斷需要結合傾印分析同硬件測試。第三，唔好刪除、改名或者替換系統檔案（例如 pdc.sys）——公開技術文章明確提醒呢個做法危險，唔會解決問題。最後一點背景：Windows 10 已於 2025 年 10 月 14 日終止支援，呢個終止支援日期只適用於 Windows 10，唔好將佢套用到 Windows 11 用機；公司機用家喺改動驅動程式同電源設定之前，應該先通知公司資訊科技部門，唔好自行改動公司機嘅設定。

第六節：停用睡眠做臨時措施——可以頂住，但唔等於修好

好多文章一講到喚醒藍屏，就叫讀者停用睡眠、停用快速啟動、停用休眠，當成解決方法。呢度要講得誠實：停用睡眠可以減少再撞到藍屏嘅機會，但係唔等於已經修好原因——你只係避開咗觸發條件，令問題唔再出現，根本原因（某個驅動程式喺電源轉換嗰陣失靈）仲喺度。將臨時措施寫成永久修復，係誤導讀者。

臨時措施嘅代價都要講明：停用睡眠之後，部機要靠關機或者長期開住，耗電同使用習慣都會改變（具體耗電影響未證實，唔好寫數字）；如果改用關機代替睡眠，每次開機都要由頭嚟，工作階段唔會保留。合理嘅過渡做法係：未有時間徹底排查之前，暫時用關機代替睡眠頂住，同時備份資料、記錄情境，等有時間再按第三節同第五節嘅次序排查。過渡做法同永久解決方法，係兩回事，唔好撈埋。

第七節：幾時應該停手送檢

以下情況，應該停低自己試，備份資料之後送檢。第一，每次或者經常由睡眠喚醒都藍屏，而且已經試過外接裝置隔離同關閉快速啟動都冇改善。第二，藍屏伴隨檔案損毀、開機失敗、磁碟異常緩慢。第三，藍屏之後電腦進入重複重新啟動循環。第四，出現同記憶體或者磁碟相關嘅多種唔同停止代碼。第五，未儲存工作經常因為藍屏而遺失，已經影響工作。第六，懷疑硬件問題嘅訊號：藍屏唔只喺喚醒嗰陣出現，正常使用、開機、閒置嗰陣都會出現；停止代碼每次都唔同；即使重裝驅動程式或者回復驅動程式，問題依然出現；伴隨其他硬件症狀，例如磁碟異常緩慢、開機嗰陣搵唔到磁碟、記憶體測試出錯、電腦無故關機或者無法開機。以上只係方向性區分，唔係診斷結論——要寫明「偏向」而唔係「肯定」，最終判斷需要結合傾印分析同硬件測試。

送檢之前準備好嘅資料：發生頻率（間中定次次）、喚醒方式（開蓋定㩒掣）、外接裝置清單、最近改動（更新、新裝置、新軟件）、停止代碼（如果記得）、已經試過邊啲步驟同結果。帶埋呢啲資料，檢測嗰陣就唔使由頭估過，亦可以避免換錯零件。最後總結一句：瞓醒藍屏最忌即刻亂改——先記低情境、備份、保存證據，再由喚醒鏈逐項隔離，一次只改一樣。分清楚「避開觸發條件」同「修好根本原因」，先至唔會白白重裝一次系統，結果喚醒藍屏依然存在。

常見問題

Q1：電腦瞓醒藍屏之後自動重新啟動，未儲存嘅文件仲有冇機會搵得返？
A：要睇情況。藍屏重新啟動之後，之前未儲存嘅工作階段多數已經唔見咗，但係有啲程式本身有自動回復功能（例如文書程式嘅自動回復檔案），重新開啟嗰個程式嗰陣可能會提示回復——呢個要睇個別程式嘅設定，唔可以保證。更重要嘅係之後：趁部機回復正常嗰陣即刻備份重要檔案，唔好等下一次藍屏先至後悔。

Q2：我冇抄低藍屏上面嘅停止代碼，仲有冇方法由發生情境起步排查？
A：有。事件檢視器 → Windows 記錄 → 系統，搵來源為 BugCheck、事件識別碼為 1001 嘅錯誤，入面有停止代碼同十六進位數值；小型傾印檔案喺 C:WindowsMinidump。即使完全冇代碼，都可以由發生情境起步：邊種喚醒方式出事、接住邊啲外接裝置、最近改過乜嘢——第三節嘅喚醒鏈排查就係為呢種情況而設。

Q3：每次合蓋再開都藍屏，但㩒電源掣喚醒又冇事，係咪代表問題喺合蓋設定或者某個裝置度？
A：好大機會係。呢個對比本身就係證據：唔同喚醒方式行唔同路徑，合蓋再開出事而㩒掣喚醒冇事，指向合蓋設定或者某個同開蓋相關嘅裝置。排查方法係先試拔除外接裝置、再試唔同喚醒方式、再對時間線，一次只改一樣，唔好一次過改晒。

Q4：停用睡眠、停用快速啟動之後冇再藍屏，係咪即係已經修好，定係只係避開咗觸發條件？
A：只係避開咗觸發條件，唔等於修好。停用睡眠令部機唔再經歷喚醒呢個電源轉換過程，問題自然唔再出現，但係根本原因（某個驅動程式喺電源轉換嗰陣失靈）仲喺度。合理做法係將停用當成臨時措施頂住，同時備份同記錄，等有時間再按次序排查。

Q5：更新完 Windows 或者驅動程式之後先開始瞓醒藍屏，應該先回滾驅動程式，定係先懷疑其他最近改動？
A：先對時間線，再決定次序。藍屏開始嘅時間同邊次更新最接近，邊次更新改過邊個驅動程式，先至係第一懷疑對象；但係時間接近唔等於因果，更新可能只係令原本已經有問題嘅驅動程式喺喚醒嗰刻暴露出嚟。所以正確次序係：記錄情境同代碼 → 拔除外接裝置測試 → 關閉快速啟動測試 → 先至到更新或者回復驅動程式，而且一次只改一個，改完測試一次。

搵 CentralComputer 幫手

電腦瞓醒就藍屏、分唔清係驅動程式定硬件問題，或者已經試過外接裝置同快速啟動都未解決？歡迎搵我哋檢測。收費一律檢測後報價，唔會未睇過部機就開價。

電話：+(852) 2115 9219　|　WhatsApp：+(852) 6558 6806
地址：香港九龍觀塘開源道 55 號開聯工業中心 A 座 712 室
營業時間：星期一至六 10:00–19:00