即使現在的系統相比 20 年前已經穩定了很多了，使用電腦時也難免會遇到藍屏、意外重啟、甚至是意外關機的情況。儘管這種問題可能只是偶然發生，可以說是不太走運；但更多的時候放著不管，反而會讓電腦的問題出現得越來越頻繁。
一個藍屏小「貼士」
所以，這篇文章就旨在幫助大家快速找到讓電腦不能正常工作的罪魁禍首，雖然不一定能「藥到病除」，但也能讓你離正確答案更近一步。
▍macOS
儘管 macOS 是 Apple 為 Mac 產品線定製的作業系統，但實際上出現問題的機會還是很多的。雖然在 macOS 中我們可以通過控制台獲取日誌信息，但從 macOS Sierra 及更高版本開始，考慮到安全和隱私問題，控制台只允許訪問最近的日誌條目，而不是整個日誌文件。
所以想要分析日誌中所有和關機有關的事件，就需要通過「終端」和相應的指令進行分析。如果你的 Mac 近期出現了意外重啟等問題，不妨跟著下面的步驟試一試，打開「終端」，並輸入如下指令：
log show --predicate 'eventMessage contains "Previous shutdown cause"' --last 24h
上面這一串指令會使用 log show 檢索系統日誌，predicate 可以進一步篩選日誌，在本文中我們篩選的日誌類型是 eventMessage 中包含 Previous shutdown cause（此前關機的原因）的信息，而篩選的時間範圍 --last 24h 則是過去 24 小時，如果有必要的話可以擴展到 36 小時甚至更長。
來自作者群的一個朋友
靜靜等待一段，你就能看到如上圖一樣的、將日誌篩選後到結果，我們需要注意的信息就是 Previous shutdown cause後續跟隨的數字，這個數字代表著 Mac 電腦上次是因為什麼原因而關閉的。
總的來說，負數的代碼通常是因硬體而關機的，該信息由系統管理控制器（SMC）或處理器本身報告；而正數因軟體而關機的。以下是每個代碼所包含的含義：
如果你的 Mac 出現大量因為 0（斷電）導致的意外關閉，那麼就需要進行一定的排查。對於沒有電池的台式 Mac 而言，主要檢查的就是電源線有沒有牢牢插入到電源接口中；如果依然出現這樣的問題則很有可能是計算機內的電源出現了問題，需要進行維修。
對於有電池的筆記本型 Mac 而言，需要同時檢查電源線和電池；筆記本型 Mac 通常會在電池耗盡之前進入休眠狀態；出現斷電而導致的關機很有可能是電池或讀取電量的電池控制器有硬體問題，對於 Intel 款 Mac 而言需要根據官方文檔重置 smc，而 M 系列 Mac 需要手動重啟一次。如果上述步驟依然不起作用的話，也需要進行維修。
長時間未響應可能會讓整個系統崩潰，嚴重時還會導致相關數據丟失。定時器超時作為 macOS 中一項功能，它可以有效防止未響應的程序導致的內核崩潰。
偶然發生的 -61/-62 錯誤可能沒什麼問題，但短時間內出現大量的類似錯誤就要對電腦進行排查了；-61 表示系統認為不能自動恢復的情況只能進行關機，而 -62 用於系統確定重啟後可能解決的情況並進行重啟。
排查的辦法很簡單，在 macOS 啟動時進入安全模式，在安全模式下啟動項目和守護程序都被禁用；如果沒有再次意外關機則是最近安裝或更新的程序出現了問題，如果再次意外關機則和系統本身有關。
以上就是 macOS 的部分了，相信這個指令可以簡單幫你定位問題，並為你後續的問題解決打下一個不錯的基礎。
▍Windows
除了 macOS，Windows 系統日誌同樣可以在時間查看器中查看並進行篩選，但考慮介面相對「復古」且用於篩選的 UI 選項更為複雜，因此我也更推薦大家使用命令行工具獲取和篩選日誌。
有的時候用 UI 介面反而會讓一件事情變得更複雜
如果你的 PC 電腦近期出現了意外重啟等問題，不妨跟著下面的步驟試一試：
#命令 1
Get-Eventlog -LogName System -Source "User32" | group EventID
# 命令 2
Get-EventLog -LogName System -Source "Microsoft-Windows-Kernel-Power" | Where-Object { $_.EventID -eq 41 }
Get-EventLog是 Windows 中獲取日誌的命令，-LogName System則限定了查找由系統生成的命令。-Source則是來源，User32和 Microsoft-Windows-Kernel-Power則是兩個不同的來源。
從用戶或程序層面進行分析
User32 是一個 Windows 系統應用程式源，它包含了許多與用戶介面相關的函數，如窗口創建、消息處理、控制項操作等等；它還會負責處理用戶交互方面的任務，例如滑鼠、鍵盤輸入和窗口管理等。
因此由用戶或是程序發起的事件，如登錄、註銷、鎖定或解鎖計算機等，都可以通過 User32 來源來定位。而後 | 用於進一步處理 Get-EventLog 得到的數據，這裡按照 EventID 事件 ID 來group 成組。
目前我電腦中只有 1074 這個事件，這個 1074 事件是計算機的正常關機的主要表現形式。如果 User32 有其他的 EventID 那麼用下面的命令進一步分析：
#本例中依然用 1074 做分析
Get-Eventlog -LogName System -Source "User32" -Newest 1 | Where-Object { $_.EventID -eq 1074} | fl *
前面的命令就不再贅述了，-Newest 1 表示選取最近的一個日誌， | 用於進一步篩選 Get-EventLog 得到的數據。Where-Object 表示篩選一個對象數組，$_ 表示當前處理的對象（也就是 | 傳遞過來的數據 ），.EventID 表示對象的 EventID 屬性，-eq 是一個比較運算符，表示等於，這裡等於的 1074 這個事件。| 依然是用於進一步處理 Where-Object 得到的數據，由 fl（也可以用完整寫法 Format-List 替代）格式化輸出對象的 * 所有屬性。
藍屏問題導致關機或重啟，還可以進一步下方的命令進行分析。
從電源管理相關的事件入手進行分析
不過很多意外關機的事件，比如藍屏導致的，無法被 User32 捕獲，因此從Microsoft-Windows-Kernel-Power 獲取電源狀態、電源事件以及與電源管理相關的錯誤和警告信息得到更多的信息。
Get-EventLog -LogName System -Source "Microsoft-Windows-Kernel-Power" | Where-Object { $_.EventID -eq 41 }
代碼中相似的內容不再贅述，在Microsoft-Windows-Kernel-Power和意外關機有關的 EventID 是 41，這個事件通常是在意外關機後重啟的階段中生成的。輸入上面的命令以後，Powershell 會輸出一段包含十進位 BugcheckCode 的內容，首先需要將它轉換為十六進位，以做進一步分析。
如 159 等同於 0x0000009f，209 等同於 0x000000d1 等等，轉換後的十六進位就可以得到最終的含義了。BugcheckCode 內容也和藍屏時輸出的錯誤碼是相同的內容，有的時候藍屏代碼一跳而過，所以這也是找到問題的好辦法。以下是常見的錯誤的代碼以及含義：
由於錯誤碼的種類繁多，因此這裡不太可能一一列舉。另外還需要注意的是，同一個錯誤可能會有不同的原因而導致，排查時可以從近期的軟體改動入手去尋找電腦意外關機的原因，排查完軟體以後才是排查硬體的真正時機。
關於 Powershell 7 使用中的一些細節
值得注意的是，Get-EventLog 只能使用 Windows 內的 Powershell 運行；Powershell 7 中因為相關 API 已被棄用，會提示無效指令，因此需要換用Get-WinEvent命令：
#命令 1
Get-WinEvent -ProviderName 'User32' | group EventID
# 命令 2
Get-WinEvent -ProviderName "Microsoft-Windows-Kernel-Power" | Where-Object { $_.EventID -eq 41}
# 命令 2 改進版
Get-WinEvent -FilterHashtable @{ProviderName = "Microsoft-Windows-Kernel-Power"; Id = 41}
Get-WinEvent 是 Powershell 7 中獲取 Windows 日誌的新命令，不同於此前的 Get-EventLog 能同時篩選具體的事件日誌 -LogName 和事件源 -Source；Get-WinEvent在使用時只能在篩選事件日誌 -Logname 和事件源 -ProviderName 中 二選一。Get-WinEvent 還 可以使用一個新的寫法 -FilterHashtable，降低命令長度的同時提高索引效率。
以上就是本文的全部內容了，希望可以在未來幫助到你。
原文連結：
https://sspai.com/post/78613?utm_source=wechat&utm_medium=social
作者：廣陵止息
責編：廣陵止息
/ 更多熱門文章 /