Kernel-Power 41 是什麼?無預警重開機的果與因

來源(Source):Microsoft-Windows-Kernel-Power
事件識別碼(Event ID):41
等級(Level):重大 Critical
任務類別(Task Category):常顯示 (63)
描述:The system has rebooted without cleanly shutting down first.（系統在未乾淨關機前就重新開機。此錯誤可能是系統停止回應、當機或意外斷電所造成。)

很多人第一眼看到「Kernel Power(核心電源)」加上紅色重大,就直接下結論「一定是電源供應器壞了」或「主機板要壞了」,然後急著送修、換 PSU、甚至重灌。先別急——這一步做錯,常常是花了冤枉錢還沒解決問題。要判斷,得先展開事件下方的「詳細資料」看欄位值。

🔎 問題根因

直接結論:Event 41 本身不是一個「錯誤」,它是一張「結果通知單」。 Windows 每次開機都會檢查上一次是不是好好關機的,如果不是,就補記一筆 Kernel-Power 41,告訴你「上次沒乾淨收尾」。至於為什麼沒乾淨收尾,答案不在 41 這行字裡,而在它攜帶的 EventData 欄位與前後的其他事件。

Windows 會在關機時盡量把錯誤碼寫下來;下次開機的核心階段(kernel phase)再檢查有沒有殘留的碼,有的話就塞進 Event 41 的資料區。所以同樣是 41,底下欄位可能天差地遠:

EventData
BugcheckCode 159
BugcheckParameter1 0x3
BugcheckParameter2 0xfffffa80029c5060
BugcheckParameter3 0xfffff8000403d518
BugcheckParameter4 0xfffffa800208c010
SleepInProgress false
PowerButtonTimestamp 0

兩個關鍵欄位先記起來，後面整篇都靠它們分流：

BugcheckCode:停止碼(藍屏 Bug Check 代碼),十進位表示。上面的 159 換成十六進位就是 0x9F。若這裡是 0,代表系統連藍屏、連傾印檔都來不及生成。
PowerButtonTimestamp:長按電源鍵強制關機的時間戳。非 0(一長串數字)代表有人壓著電源鍵關機;0 代表不是這樣關的。

看懂這兩個值,就能把「一堆 41」收斂成三種完全不同的情境,對應完全不同的修法。

🔬 底層機制:這個錯誤訊號從哪裡來?

要真的搞懂 41,得看 Windows 怎麼定義「乾淨關機」。正常關機時,系統會送出 WM_QUERYENDSESSION 訊息給所有有介面的程式,請它們存檔、優雅結束;全部乖乖回應並關閉,Windows 就記一筆 Event 6006(乾淨關機)。只要有程式沒回應、或系統根本來不及走完這套流程,就變成 Event 6008(不正常 / 骯髒關機,dirty shutdown)。

Kernel-Power 這個元件負責監控電源狀態轉換(開機、睡眠、休眠、關機)。開機時,Windows 會讀取一個叫 開機狀態檔(Boot Status File,位置在 %SystemRoot%\Bootstat.dat) 的二進位檔,裡面記著 boot、shutdown、resume 三個階段上次有沒有成功走完。一旦發現上次「shutdown 階段沒乾淨完成」,核心就補記 Event 41,並把能撈到的停止碼塞進去。

所以一句話總結底層邏輯:41 是核心在開機時「回頭看」發現的異常,它是果(consequence),真正的因(cause)藏在關機那一瞬間發生了什麼。 這也是為什麼標題說它是「斷電重啟的果與因」——你要順著欄位往回追那個因。順帶一提,BugcheckCode 用十進位存,是因為事件資料的格式規範如此;但微軟停止碼文件全用十六進位,所以你一定要自己轉一次(159 → 0x9F),對照才有意義。

🛠️ 解決方案

⚠️ 高風險提醒:本段後半涉及重設 BIOS / 停用超頻 / 開機箱檢查電源供應器與散熱。動手前請完整備份重要資料、拔除電源並釋放靜電;不確定型號或沒把握就送有信譽的維修站,別硬幹。

修 Kernel-Power 41 的第一步永遠是分流,不是亂槍打鳥。先展開事件的詳細資料,看 BugcheckCode 與 PowerButtonTimestamp,再對號入座。

情境一:BugcheckCode 非 0 —— 這其實是一場藍屏

直接結論:只要 BugcheckCode 不是 0,問題本質就是一次 BSOD 停止錯誤,41 只是幫你留了證據。 這是最好處理的情境,因為你有明確的停止碼可查。

做法:

記下 BugcheckCode 的十進位值(例:159)。
打開小算盤 →「檢視」→「工程 / 程式設計人員」模式 → 確認在 Dec,輸入 159 → 按 Hex,得到 0x9F。
補滿八位:0x9F 的標準寫法是 0x0000009F;0xA 是 0x0000000A。微軟官方文件就是用這種八位格式。
拿這個十六進位碼去查對應的藍屏排錯。以官方文件的範例 159 = 0x9F 來說,那就是 DRIVER_POWER_STATE_FAILURE——一支驅動程式在電源狀態轉換(睡眠 / 喚醒)時卡住。這支停止碼站長寫過完整拆解,直接看 DRIVER_POWER_STATE_FAILURE(0x9F)排錯。

換句話說,情境一的 41 = 你的藍屏排錯入口,把 BugcheckCode 轉出來,剩下就是照停止碼標準流程走。

情境二:PowerButtonTimestamp 非 0 —— 是你自己長按電源關的

直接結論:PowerButtonTimestamp 出現一長串非 0 數字(例如 131728546170882432),代表這台是被「長按電源鍵」強制關機的,不是系統故障。 這種 41 你完全不用怕。

它通常長這樣:BugcheckCode 是 0、其他參數也是 0,只有 PowerButtonTimestamp 有值。意思是當下你(或別人)壓著電源鍵把它關掉了。微軟的建議很直白:這種強制關機會打斷正常關機流程,除非電腦真的沒回應,否則別這樣關。 如果你是因為當機才不得已長按,那要處理的是「為什麼會當機」,而不是這筆 41。

情境三:全部歸零或根本沒有 41 —— 訊號指向硬體 / 電源

直接結論:Event 41 沒被記錄,或 BugcheckCode 與 PowerButtonTimestamp 全是 0,通常代表系統來不及寫任何錯誤碼——最常見的元兇是電源、記憶體、過熱這類硬體層問題,不是軟體 bug。這也是最花時間、但最不該重灌的情境。

微軟官方對這種「全 0 / 無 41」列了幾個方向:

無 41 或 BugcheckCode 為 0 → 先懷疑電源:電源一被切斷,系統可能連停止碼都寫不完就掛了。常見成因:筆電電池被拔掉或耗盡;桌機被拔插頭、跳電、停電;電源供應器瓦數不足或老化故障。
PowerButtonTimestamp 為 0:可能是某個 Windows 程序卡住磁碟寫入,你按著電源鍵 4 秒以上關機;或你對一台沒回應的電腦直接斷電。
全 0 且旁邊有 volmgr 記的 Event 46(Crash dump initialization failed!):代表開機時沒設定好傾印檔(預設傾印檔就是分頁檔 pagefile)。這時系統就算真的有 bugcheck,也寫不進 41、也生不出傾印檔。先去把傾印設定補好,下次才抓得到真兇——設定方法看關自動重啟、設好記憶體傾印。

確認往硬體查之後,照這個順序逐項排除(全部來自微軟官方建議):

停用超頻:CPU / 記憶體有超頻就先關掉,讓系統跑在原生時脈,看問題是否消失。超頻不穩是隨機 41 的頭號常客。
檢查記憶體:跑 Windows 記憶體診斷(mdsched.exe)或第三方工具;確認每條記憶體時脈一致、插槽設定正確。
檢查電源供應器:確認 PSU 瓦數足以帶動所有裝置。如果你近期加了記憶體、換更強的 CPU、多插了硬碟或外接裝置,耗電可能已超過 PSU 能穩定供應的上限。若是市電不穩導致,考慮加裝不斷電系統(UPS)。
檢查過熱:量測內部溫度,找有沒有元件過熱(積灰、風扇停轉、散熱膏乾掉都算)。
查關機前的可疑事件:用 Event 6008(不正常關機)的時間點,往前翻「應用程式」和「系統」日誌,看斷電前一刻有沒有異常。
虛擬機 / 伺服器例外:實體伺服器可能被 ASR(自動伺服器復原)重啟;Hyper-V / VMware 的 VM 可能被 heartbeat 監控判定沒回應而重啟——這類要往虛擬化平台設定查,不是 Windows 本身。

如果上述全查過還定位不到,把系統(BIOS、硬體)回復到預設設定,再確認問題是否還在。

附帶一招:讓藍屏「停住」看得到碼

如果你有看到藍屏、但 Event 41 卻沒帶到那個停止碼,可以關掉自動重新啟動,讓藍屏畫面停在螢幕上、看清楚停止碼:在「本機」按右鍵 →「內容」→「進階系統設定」→「進階」→「啟動及修復」的「設定」→ 取消勾選「自動重新啟動」。這一步不會修好問題,但能把稍縱即逝的停止碼留住,對診斷幫助很大。

✅ 驗證修復結果

改完之後,別只看「這幾天沒再重開」就當沒事,要主動驗證:

正常關開機幾次:每次都用「開始 → 關機」正規流程關,再開機。回到事件檢視器「系統」日誌,確認不再新增 Event 41,並且開始出現 Event 6006(乾淨關機)。
對照 6008 有沒有停:如果先前一直冒 Event 6008(不正常關機),修對之後應該不再出現新的 6008。
看可靠性監視器:控制台搜尋「可靠性」→ 開啟「檢視可靠性紀錄」,用時間軸看穩定度分數有沒有回升、紅色叉叉有沒有停。
壓力測試(針對情境三):懷疑電源 / 過熱的話,跑一段遊戲或壓力測試,看在高負載下會不會複發——純電源問題往往一加重負載就現形。

只有連續幾天、包含高負載情境都不再冒新的 41 / 6008,才算真的修好,而不是暫時消失。

💡 總結:預防再次發生

站長我處理這類「電腦自己重開」的案子,心法其實只有一句:先分流,再動手。看到滿螢幕紅色 41 先深呼吸,展開詳細資料看 BugcheckCode 跟 PowerButtonTimestamp——有停止碼就往驅動程式 / 藍屏那條路走,全是 0 就往電源 / 硬體那條路走。這兩條路的修法幾乎不重疊,分錯方向就是白忙一場。

我看過太多人一遇到 Kernel-Power 41 就直接重灌,結果重灌完照樣重開——因為如果是 PSU 老化、插座接觸不良、超頻不穩或散熱膏乾掉,這些跟作業系統一點關係都沒有,重灌當然無效。反過來,平常就把記憶體傾印設定弄好、養成看事件檢視器的習慣,真出事時你手上就有停止碼可查,而不是對著一行「rebooted without cleanly shutting down」乾瞪眼。

預防三件事:一、電源相關硬體別將就,PSU 瓦數抓有餘裕、老電腦定期清灰換散熱膏;二、超頻要壓力測試過再當日常;三、傾印設定先設好、Windows 更新與晶片組 / 主機板韌體保持在合理版本,讓電源管理該有的修正都到位。

📌 證據等級說明:本文為 cornerstone 深度解析,內容依據微軟官方文件與權威技術資料整理、交叉查證(深度 E3),非站長第一手實驗室實測;文中未列任何未經證實的實測數字或特定硬體型號,請依你自己的機器實際欄位值判讀。

❓ 常見問題

Q:Kernel-Power 41 後面那個 (63) 是什麼意思?要另外查嗎?

不用。(63) 是這個事件的任務類別(Task Category)編號,只是事件檢視器的分類標籤,不是另一個獨立錯誤碼。真正要看的是 Event ID 41 底下的 BugcheckCode 與 PowerButtonTimestamp,別被 (63) 帶偏。

Q:出現 Kernel-Power 41 一定是電源供應器壞了嗎?

不一定。先看 BugcheckCode:非 0 代表是藍屏(通常是驅動程式或系統層問題),跟 PSU 未必有關;只有在「全是 0 或根本沒記到 41」時,才比較指向電源、記憶體、過熱這類硬體因素。先分流,再判斷。

Q:關掉「自動重新啟動」會修好問題嗎?

不會。它只是讓藍屏畫面停住、方便你抄下停止碼,屬於「診斷輔助」而不是「修復手段」。抄到停止碼後,還是要照對應的藍屏排錯流程處理。

Q:重灌 Windows 能解決 Kernel-Power 41 嗎?

如果根因是電源、超頻、過熱、記憶體或韌體這類硬體 / 平台問題,重灌完全無效,重開機照樣發生。只有在確定是軟體 / 驅動程式層(有明確 BugcheckCode 且指向某支驅動)時,重裝驅動或系統才可能有幫助——但那也應該先用停止碼精準定位,而不是一律重灌。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Advanced troubleshooting for Event ID 41: “The system has rebooted without cleanly shutting down first”(Microsoft Learn) — 2026-07-04 查證(官方頁面最後更新 2026-02-12)
Bug Check Code Reference(Microsoft Learn) — 2026-07-04 查證
Event ID 46 when you start a computer(Microsoft Learn) — 2026-07-04 查證

📖 第二級|權威技術媒體(補充常見處置,非規格權威):

Event ID 41: Kernel power error(ManageEngine EventLog Analyzer) — 2026-07-04 查證

⚠️ 本文核心事實以第一級官方為準,第二級僅為補充。

📅 本文查證戳記:2026-07-04 依據 Windows 10 / 11 現況與微軟官方文件撰寫。
若你在後續版本遇到欄位或步驟差異,歡迎在留言區回報,站長會更新文章。

⚡ 站長快讀:核心重點

📌 快速答案

🧰 開始前的準備

🔍 症狀描述與錯誤訊息