如果哪天你打開 VS2019還沒來得及敲一行代碼先被登錄窗口的轉(zhuǎn)圈動(dòng)畫卡住然后整個(gè)窗口直接消失——第一反應(yīng)多半是網(wǎng)絡(luò)抽風(fēng)或者 IDE 的緩存壞了。我這次遇到的正是這個(gè)情況但最后定位到的問題已經(jīng)深到了 BIOS 微碼這一層。更讓我意外的是閃退的根子不在 VS2019 自身而是一臺(tái) 14900KF 平臺(tái)在特定負(fù)載場(chǎng)景下的處理器微碼狀態(tài)。整個(gè)排錯(cuò)過程從應(yīng)用日志一路挖到 CPU 固件用了三天時(shí)間中間踩了不少“看似相關(guān)實(shí)際無關(guān)”的坑。這篇復(fù)盤不打算只給結(jié)論排錯(cuò)時(shí)的思路和判斷依據(jù)對(duì)我來說更值錢寫出來希望對(duì)遇到類似頑固崩潰的人有所幫助。1. 現(xiàn)象復(fù)現(xiàn)一場(chǎng)“轉(zhuǎn)幾圈就消失”的詭異崩潰1.1 觸發(fā)條件與現(xiàn)場(chǎng)記錄先說清楚復(fù)現(xiàn)條件方便你對(duì)照自己的環(huán)境。我的這臺(tái)機(jī)器配置不算偏門14900KF CPU搭配中高端主板32GB 內(nèi)存系統(tǒng)是當(dāng)前能裝到的最新穩(wěn)定版補(bǔ)丁VS2019 沒有裝任何第三方擴(kuò)展機(jī)器上也沒有跑什么古怪的駐留軟件。按理說這種環(huán)境跑開發(fā)工具應(yīng)該是最穩(wěn)的結(jié)果偏偏在登錄這一步翻了車。復(fù)現(xiàn)路徑非常固定啟動(dòng) VS2019進(jìn)入賬號(hào)登錄環(huán)節(jié)輸入賬號(hào)后點(diǎn)擊登錄登錄窗右上角開始轉(zhuǎn)圈。轉(zhuǎn)圈時(shí)間大約 5 到 8 秒然后整個(gè) IDE 進(jìn)程悄無聲息地消失連錯(cuò)誤彈窗都沒有。第一次出現(xiàn)時(shí)我以為是 Windows 后臺(tái)更新?lián)屨剂速Y源重啟一次再試結(jié)果照舊。反復(fù)注銷、重啟、換網(wǎng)絡(luò)依舊沒有規(guī)律只能說“大概率閃退”而且閃退時(shí)任務(wù)管理器里 CPU 占用并不高內(nèi)存也很正常完全不像是資源耗盡的樣子。這種“無異常崩潰”的特征決定了后面排查不能只盯著 VS 自己的崩潰日志。因?yàn)闆]有彈窗、沒有崩潰對(duì)話框、沒有明顯的資源峰值說明進(jìn)程是在某個(gè)深層調(diào)用里被強(qiáng)制帶走了而不是普通的托管異常。如果這時(shí)候急著找 VS 的故障模塊很容易繞進(jìn)死胡同。1.2 常規(guī)三板斧為什么全失效對(duì)這種問題大多數(shù)人的第一反應(yīng)是先清緩存、再重置。我也老老實(shí)實(shí)把常規(guī)操作全部做了一遍這里直接列個(gè)表省得大家重復(fù)踩坑操作具體內(nèi)容結(jié)果清理 VS 本地緩存刪除 LocalAppData 下 VS 對(duì)應(yīng)版本的 ComponentModelCache、ApplicationPrivateSettings 等目錄無效重置用戶數(shù)據(jù)使用 /ResetUserData 參數(shù)啟動(dòng) VS無效修復(fù)安裝運(yùn)行安裝程序選擇修復(fù)當(dāng)前版本無效關(guān)閉安全軟件臨時(shí)退出系統(tǒng)自帶的安全防護(hù)關(guān)閉實(shí)時(shí)監(jiān)控?zé)o效更換網(wǎng)絡(luò)環(huán)境切換 DNS、更換代理、直連和熱點(diǎn)分別測(cè)試無效現(xiàn)在回頭看這些操作全部作用在應(yīng)用層而問題根源壓根不在 VS 的應(yīng)用數(shù)據(jù)里。VS 之所以閃退只是因?yàn)樗『檬悄莻€(gè)需要頻繁做加密通信、并且調(diào)度大量線程的高負(fù)載進(jìn)程最先碰觸到了硬件層的錯(cuò)誤邊界。很多頑固性崩潰都有這個(gè)特點(diǎn)癥狀集中在某一個(gè)軟件但你越修這個(gè)軟件離真相越遠(yuǎn)。2. 換思路把登錄流程拆開來看卡點(diǎn)到底在哪2.1 VS 自帶的“黑匣子”日志常規(guī)手段失效后我開始認(rèn)真考慮一件事VS2019 登錄閃退到底是登錄請(qǐng)求發(fā)出去了沒收到響應(yīng)還是請(qǐng)求壓根沒發(fā)出去又或者響應(yīng)收到了但本地處理環(huán)節(jié)出了岔子要回答這個(gè)問題必須看 VS 自己的運(yùn)行日志。VS 有一個(gè)常被忽略的調(diào)試參數(shù)/Log。在快捷方式或者命令行后面加上這個(gè)參數(shù)啟動(dòng)VS 會(huì)把完整的啟動(dòng)、加載、登錄過程寫入到日志文件。我加上這個(gè)參數(shù)重新復(fù)現(xiàn)了一次崩潰然后打開日志文件重點(diǎn)看最后幾十行。日志里出現(xiàn)了幾個(gè)典型特征大量等待登錄 Token 服務(wù)響應(yīng)的異步寫入網(wǎng)絡(luò)握手相關(guān)的調(diào)用一個(gè)接一個(gè)超時(shí)在閃退前最后幾百毫秒多個(gè)線程同時(shí)進(jìn)入等待鎖的狀態(tài)然后就斷開了。這里最關(guān)鍵的疑點(diǎn)不是“連接超時(shí)”本身而是“超時(shí)找不到任何外部原因”。按經(jīng)驗(yàn)判斷正常的超時(shí)總能對(duì)上網(wǎng)絡(luò)延遲或者服務(wù)端異常但這臺(tái)機(jī)器上所有網(wǎng)絡(luò)探測(cè)都是通的ping 正常抓包也能看到連接建立卻總是在本地加密處理階段沒有下文。到這一步我才確認(rèn)問題大概率不在常規(guī)網(wǎng)絡(luò)路徑上而在這個(gè)加密組件運(yùn)行的底層環(huán)境。2.2 崩潰轉(zhuǎn)儲(chǔ)閃退前線程們停在哪為了讓結(jié)論更硬我在閃退發(fā)生前的幾秒鐘用系統(tǒng)自帶的任務(wù)管理器對(duì) VS 進(jìn)程創(chuàng)建了完整轉(zhuǎn)儲(chǔ)然后用調(diào)試工具打開分析。分析結(jié)果讓我很意外進(jìn)程里沒有 CLR 未處理異常也沒有明顯的訪問違規(guī)崩潰更像是一種本地鎖等待導(dǎo)致的進(jìn)程自我保護(hù)關(guān)閉。多個(gè)線程都在等一個(gè)和加密上下文相關(guān)的返回而這個(gè)返回始終沒有到來。這種“卡住然后被靜默關(guān)閉”的模式和常見的 .NET 程序崩潰完全不同。普通崩潰至少會(huì)留下異常堆棧而這次更像是底層某個(gè)系統(tǒng)調(diào)用長(zhǎng)時(shí)間不返回被進(jìn)程內(nèi)部的健康檢查邏輯判定為無響應(yīng)直接觸發(fā)了退出流程。光靠應(yīng)用日志已經(jīng)解釋不了這種現(xiàn)象我決定把視角從 VS 轉(zhuǎn)向操作系統(tǒng)本身。3. 系統(tǒng)底層“露餡”事件查看器里的硬件錯(cuò)誤記錄3.1 WHEA最容易忽略的系統(tǒng)級(jí)線索打開系統(tǒng)自帶的事件查看器在 Windows 日志下的 System 分類里我找到了破局的關(guān)鍵。每次 VS2019 閃退的時(shí)間戳附近都躺著一條來自 WHEA 的事件事件 ID 是 18描述里明確帶著 Machine Check Exception 字段。WHEA 是 Windows 處理硬件錯(cuò)誤的中轉(zhuǎn)站CPU、內(nèi)存、PCIe 設(shè)備如果報(bào)告了硬件級(jí)問題都會(huì)在這里留下記錄。多數(shù)人平時(shí)根本不看這里因?yàn)樗炔划a(chǎn)生彈窗也不影響日常操作除非你專門去翻。這里要給不太了解 WHEA 的朋友解釋一下Machine Check Exception 是 CPU 自己報(bào)告的一種異常機(jī)制代表處理器在執(zhí)行指令時(shí)發(fā)現(xiàn)了內(nèi)部錯(cuò)誤。普通應(yīng)用程序崩潰對(duì)應(yīng)的是進(jìn)程級(jí)日志W(wǎng)HEA 記錄則說明崩潰現(xiàn)場(chǎng)下方還有一層硬件信號(hào)。當(dāng)軟件層面的異常行為和硬件錯(cuò)誤記錄出現(xiàn)時(shí)間重合時(shí)你幾乎可以斷定問題不只是“某個(gè)程序?qū)懙貌缓谩蹦敲春?jiǎn)單了。3.2 時(shí)間戳對(duì)齊把“軟件崩潰”和“硬件錯(cuò)誤”綁定如果只是偶然出現(xiàn)一條 WHEA 記錄我可能會(huì)當(dāng)成無關(guān)緊要的誤報(bào)。于是我做了一個(gè)最笨也最有效的驗(yàn)證連續(xù)復(fù)現(xiàn) 10 次 VS 登錄流程其中 7 次觸發(fā)閃退每一次閃退事件的幾秒之內(nèi)都能在事件查看器里找到對(duì)應(yīng)的 WHEA 記錄。時(shí)間戳一一對(duì)上之后“軟件崩潰”和“硬件錯(cuò)誤”就不再是兩條平行線了。同時(shí)還要排除一個(gè)常見干擾某些軟件在 CPU 高負(fù)載時(shí)也會(huì)引起瞬時(shí)電壓波動(dòng)進(jìn)而產(chǎn)生 WHEA 記錄。為了區(qū)分我在同一時(shí)間段跑了通用的 CPU 基準(zhǔn)測(cè)試和內(nèi)存壓力測(cè)試發(fā)現(xiàn)這些高負(fù)載場(chǎng)景反而不崩潰唯獨(dú) VS 登錄這個(gè)特定場(chǎng)景一崩一個(gè)準(zhǔn)。這說明觸發(fā)條件不是“高負(fù)載”這么寬泛而是某一種特定的指令模式踩到了硬件錯(cuò)誤邊界。這個(gè)結(jié)論把排查范圍從“通用系統(tǒng)問題”縮小到了“處理器固件和指令調(diào)度層”。3.3 為什么我敢把懷疑目標(biāo)指向 BIOS 微碼接下來是本篇最關(guān)鍵的判斷。這臺(tái)上機(jī)正好是一臺(tái) 14900KF這塊 CPU 在社區(qū)里有著大量的穩(wěn)定性反饋尤其是默認(rèn)電壓偏高、高負(fù)載任務(wù)下隨機(jī)崩潰的案例層出不窮。雖然不同主板、不同 BIOS 設(shè)置的表現(xiàn)不一樣但共性很明顯問題更多出在處理器微碼層而不是某一家主板廠商單獨(dú)造成。當(dāng) WHEA 記錄出現(xiàn)后我的第一反應(yīng)不是換電源也不是降內(nèi)存頻率而是先檢查 BIOS 里的微碼版本和功耗設(shè)置。這個(gè)思路后來被證明是對(duì)的。如果當(dāng)時(shí)我直接去換電源或者降內(nèi)存大概率折騰一兩天也解決不了問題因?yàn)榉较蛲耆?。排錯(cuò)這種事最怕的不是問題難而是你特別努力地在一個(gè)錯(cuò)誤的方向上反復(fù)優(yōu)化?？吹?WHEA 記錄的那一刻我已經(jīng)有七成把握這是一次處理器微碼層面的固件問題而不是 VS 的問題。4. 14900KF 的微碼排查從補(bǔ)知識(shí)到定位根因4.1 先給新手補(bǔ)一段CPU 微碼是什么微碼可以理解為 CPU 內(nèi)部固件的一部分。CPU 從設(shè)計(jì)到量產(chǎn)總會(huì)有一些很難通過純硬件手段修正的缺陷廠商會(huì)通過微碼補(bǔ)丁來修改某些指令的執(zhí)行行為。微碼由 BIOS 在啟動(dòng)階段加載進(jìn) CPU 內(nèi)部的存儲(chǔ)區(qū)域所以更新 BIOS 不只是獲得主板新功能更是在更新 CPU 內(nèi)部的“運(yùn)行邏輯說明書”。用一個(gè)生活化類比CPU 像一支球隊(duì)指令集是戰(zhàn)術(shù)手冊(cè)微碼則是裁判手里的臨場(chǎng)判例庫。比賽過程中發(fā)現(xiàn)規(guī)則漏洞你沒法臨時(shí)換裁判只能通過更新判例說明來糾偏。14900KF 在特定指令組合和電壓條件下觸發(fā)的穩(wěn)定性問題本質(zhì)上就是“判例庫”缺了一條關(guān)鍵修正。這也能解釋為什么問題看起來那么抽象不是某個(gè)軟件寫錯(cuò)了而是硬件執(zhí)行到某類指令時(shí)容易出岔子。4.2 查看當(dāng)前微碼版本三個(gè)方法在動(dòng)手刷新 BIOS 之前我先把當(dāng)前微碼版本確認(rèn)了一遍方法有三種開機(jī)進(jìn) BIOS 設(shè)置界面一般在 CPU 或者固件信息頁面能看到 Microcode Revision 一欄。使用硬件檢測(cè)工具比如 CPU-Z、HWiNFO64 這類軟件在 CPU 信息里可以直接讀到 microcode revision。如果主板有配套的系統(tǒng)監(jiān)控軟件部分版本也能顯示微碼信息但最可靠還是前兩種。我這臺(tái)機(jī)器上顯示的微碼版本是 0x12以本機(jī)實(shí)際顯示為例而主板廠商在 BIOS 頁面里放出的新版本說明中修訂版本已經(jīng)更新到了更靠后的序列。舊微碼對(duì)應(yīng)的發(fā)布說明里正好提到了一條“CPU 在高負(fù)載場(chǎng)景下可能隨機(jī)上報(bào)錯(cuò)誤”的修復(fù)項(xiàng)看到這一條時(shí)我心里基本有底了。不過光有版本差異還不夠必須通過控制變量實(shí)驗(yàn)把其它可能性排除掉才能放心刷 BIOS。4.3 控制變量實(shí)驗(yàn)先排除內(nèi)存和電壓的干擾在決定刷新 BIOS 之前我做了兩組對(duì)照實(shí)驗(yàn)?zāi)康氖潜苊獍压谟涘e(cuò)地方同時(shí)也要確認(rèn)是不是內(nèi)存或者供電在搞鬼。實(shí)驗(yàn)一恢復(fù) BIOS 出廠默認(rèn)關(guān)閉 BIOS 里的內(nèi)存一鍵超頻選項(xiàng)保持內(nèi)存跑在標(biāo)準(zhǔn)頻率然后重新走一遍 VS 登錄復(fù)現(xiàn)腳本。結(jié)果問題依舊這就排除了內(nèi)存條本身超頻不穩(wěn)定導(dǎo)致 WHEA 的可能。實(shí)驗(yàn)二手動(dòng)把 CPU 的全核倍頻鎖定在比默認(rèn)略低的位置關(guān)掉自動(dòng)加速再復(fù)現(xiàn)登錄場(chǎng)景。結(jié)果閃退從“七成概率”降到了“兩成概率”雖然觸發(fā)變難了但問題依然存在。這兩組實(shí)驗(yàn)很說明問題降低 CPU 頻率和電壓后觸發(fā)條件變苛刻但根因沒有消失。搭配上 WHEA 記錄的事件來源排查范圍基本縮到了“處理器微碼 供電調(diào)度策略”這個(gè)組合。此時(shí)升級(jí) BIOS 微碼已經(jīng)是性價(jià)比最高、命中率最高的選擇了。4.4 更新 BIOS 微碼的正確打開方式刷新 BIOS 本身不難但有幾個(gè)細(xì)節(jié)決定成敗。第一步先把當(dāng)前 BIOS 設(shè)置全部截圖保存尤其是電壓、倍頻、內(nèi)存時(shí)序這些參數(shù)別偷懶出了狀況你就知道這些截圖多值錢。第二步準(zhǔn)備一個(gè)穩(wěn)定的供電環(huán)境我額外接了一個(gè)在線式 UPS避免刷新中途斷電這是所有 BIOS 刷寫里唯一不能賭的環(huán)節(jié)。第三步使用主板自帶的刷寫功能盡量進(jìn) BIOS 內(nèi)置的刷新工具去操作而不是在系統(tǒng)里跑廠商的 Windows 刷寫程序這樣可以降低后臺(tái)服務(wù)干擾刷寫過程的概率。刷新完成后重新進(jìn) BIOS把之前用到的關(guān)鍵設(shè)置恢復(fù)內(nèi)存開回一鍵超頻選項(xiàng)如果你之前在用、風(fēng)扇曲線按需調(diào)整。但注意先別急著開任何超頻設(shè)置保持默認(rèn)跑一兩天確認(rèn)基礎(chǔ)穩(wěn)定性之后再逐步恢復(fù)。我這臺(tái)機(jī)器更新完微碼版本從 0x12 變化到 0x23以本機(jī)實(shí)際顯示為例主板固件也跨了兩個(gè)大版本。到這一步修復(fù)動(dòng)作正式落地。5. 修復(fù)驗(yàn)收更新后的完整回歸測(cè)試5.1 最小驗(yàn)證VS2019 登錄流程連續(xù)復(fù)測(cè)更新完 BIOS 后的第一件事不是跑分而是把最初的問題路徑重新走一遍。我連續(xù)執(zhí)行了 15 次 VS2019 登錄流程啟動(dòng)、登錄、關(guān)閉、再啟動(dòng)。15 次全部成功沒有一次轉(zhuǎn)圈超時(shí)沒有一次閃退。為了更貼近真實(shí)使用狀態(tài)我又掛上/Log參數(shù)看了一眼日志之前頻繁出現(xiàn)的 Token 服務(wù)等待超時(shí)記錄徹底消失了。到這里最初的問題已經(jīng)算是解決了。但排錯(cuò)最忌諱修好一個(gè)點(diǎn)就收工因?yàn)閱吸c(diǎn)驗(yàn)證只能證明“這個(gè)問題路徑?jīng)]再觸發(fā)”不能證明整個(gè)硬件環(huán)境已經(jīng)穩(wěn)定。我接著按三個(gè)維度做了完整回歸測(cè)試確保這次修復(fù)不是一次幸運(yùn)的偶然。5.2 壓力回歸編譯負(fù)載、多線程任務(wù)和長(zhǎng)時(shí)穩(wěn)定性回歸測(cè)試我分成三組分別模擬不同場(chǎng)景下的真實(shí)使用壓力。第一組是編譯類負(fù)載。打開一個(gè)大型解決方案連續(xù)執(zhí)行三遍全量編譯觀察有沒有編譯進(jìn)程崩潰、系統(tǒng)有沒有新增 WHEA 記錄。這個(gè)場(chǎng)景對(duì) CPU 的多核調(diào)度和長(zhǎng)時(shí)間滿載要求很高舊微碼下很容易在高線程調(diào)度時(shí)出現(xiàn)問題。第二組是綜合壓力測(cè)試。跑 CPU 全核心負(fù)載測(cè)試和內(nèi)存壓力測(cè)試各 30 分鐘同時(shí)開著 VS、瀏覽器、文檔編輯器模擬日常工作流。重點(diǎn)看兩個(gè)指標(biāo)進(jìn)程是否存活、事件查看器里有沒有新增硬件錯(cuò)誤。第三組是長(zhǎng)時(shí)待機(jī)觀察。舊微碼下即使不主動(dòng)操作機(jī)器偶發(fā)崩潰也可能溜進(jìn)來所以我特意讓機(jī)器待機(jī)過夜第二天早上查事件查看器確認(rèn)整晚沒有新增 WHEA 記錄。三組測(cè)試全部通過。尤其是編譯負(fù)載組更新前一旦跑到高線程調(diào)度階段就會(huì)感覺風(fēng)扇狂轉(zhuǎn)之后偶發(fā)報(bào)錯(cuò)更新之后整個(gè)編譯過程平穩(wěn)得多風(fēng)扇轉(zhuǎn)速也更符合負(fù)載曲線不再出現(xiàn)那種“莫名的瞬時(shí)報(bào)錯(cuò)感”。5.3 如果更新微碼后問題仍然存在怎么辦寫到這里也許有人的情況和我不同更新 BIOS 后 WHEA 記錄依然存在。如果遇到這種情況建議按下面的順序繼續(xù)排查排查層驗(yàn)證方法判斷依據(jù)內(nèi)存與供電關(guān)閉內(nèi)存一鍵超頻單獨(dú)測(cè)試內(nèi)存穩(wěn)定性WHEA 消失則問題在內(nèi)存或主板供電預(yù)設(shè)電源輸出交叉測(cè)試電源觀察高負(fù)載下電壓波動(dòng)負(fù)載瞬間壓降會(huì)偽造 CPU 硬件錯(cuò)誤BIOS 版本回退到上一個(gè)穩(wěn)定 BIOS 版本新微碼若引入新問題需要回退對(duì)比硬件故障兜底將 CPU 和主板分開送測(cè)持續(xù)出現(xiàn) WHEA 且排除前三項(xiàng)后必須走保修這個(gè)決策鏈不一定適用于所有配置但方向是對(duì)的先軟件、再固件、最后硬件每一步只動(dòng)一個(gè)變量。我這次能快速收斂很大程度上就是因?yàn)樵谒?BIOS 之前已經(jīng)通過兩組實(shí)驗(yàn)把內(nèi)存和簡(jiǎn)單電源因素排除掉了變量越少判斷越準(zhǔn)。6. 復(fù)盤后記三個(gè)我以后會(huì)堅(jiān)持的排錯(cuò)習(xí)慣6.1 第一件事看系統(tǒng)事件而不是軟件日志這次排錯(cuò)最大的收獲是徹底改變了我的排查順序。以前遇到應(yīng)用閃退我基本一頭扎進(jìn)應(yīng)用日志和緩存目錄?，F(xiàn)在我會(huì)先花十分鐘打開事件查看器看一眼 System 分類里有沒有硬件類警告或錯(cuò)誤。很多軟件問題只是癥狀硬件錯(cuò)誤才是病灶應(yīng)用日志能告訴你怎么壞系統(tǒng)事件能告訴你為什么壞。如果你之前沒怎么用過事件查看器我強(qiáng)烈建議現(xiàn)在就打開看一眼尤其是“系統(tǒng)”這個(gè)分類。里面可能已經(jīng)躺著很多你沒注意到的 WHEA 記錄。它們不一定馬上引發(fā)可見的問題但往往意味著你的硬件環(huán)境已經(jīng)存在某種不穩(wěn)定的底層信號(hào)早晚會(huì)以某個(gè)應(yīng)用崩潰的形式浮出水面。6.2 每次只動(dòng)一個(gè)變量并記錄操作日志微碼更新前后我原本還想順手調(diào)整風(fēng)扇策略和內(nèi)存時(shí)序幸好忍住了。排錯(cuò)里最大的敵人不是錯(cuò)誤本身而是你不知道自己的改動(dòng)到底產(chǎn)生了什么效果。動(dòng)一個(gè)變量、觀察、記錄再動(dòng)下一個(gè)這個(gè)看起來最笨的程序?qū)嶋H上最快。我后來把每天的操作整理成了一份簡(jiǎn)單的日志幾點(diǎn)幾分做了什么改動(dòng)、復(fù)現(xiàn)了幾次、結(jié)果怎么樣。三天下來這份日志的價(jià)值甚至超過了各種分析工具因?yàn)楹芏嗑€索是跨天才能對(duì)上的。如果你也在面對(duì)一個(gè)頑固問題建議從第一天就開始做這種記錄別靠腦子記。6.3 值得長(zhǎng)期保存的五類排錯(cuò)材料這次能用三天而不是三周定位問題很大程度上靠的是平時(shí)積累的材料。建議養(yǎng)成習(xí)慣遇到頑固問題先把以下五類信息保存下來——復(fù)現(xiàn)步驟的截圖和時(shí)間戳對(duì)應(yīng)軟件的日志文件事件查看器里 System 分類的完整導(dǎo)出包括 WHEA 記錄BIOS 設(shè)置截圖和內(nèi)存、電壓參數(shù)系統(tǒng)更新和驅(qū)動(dòng)版本記錄。最后再分享一個(gè)小技巧導(dǎo)出事件日志時(shí)不要只導(dǎo)出當(dāng)天最好往前導(dǎo)一周。WHEA 這類硬件錯(cuò)誤往往不是偶發(fā)而是已經(jīng)潛伏了很長(zhǎng)時(shí)間只是你沒注意到。我這次最早的一條相關(guān)記錄其實(shí)比 VS2019 第一次閃退早了整整四天。如果能早幾天發(fā)現(xiàn)那條記錄也許能省下一整個(gè)下午用來折騰 VS 緩存的時(shí)間。排錯(cuò)就是這樣線索往往早就存在問題只在于你有沒有往正確的方向多看一眼。