起因概述

昨天筆者的一位友人聯(lián)系我，說此前筆者替他組裝的一臺12代i7的臺式機近日頻發(fā)藍屏（BSOD）問題，希望筆者能協(xié)助他找到問題的原因并解決。

聽聞此事后，筆者先讓他到設(shè)置→系統(tǒng)→關(guān)于→高級系統(tǒng)設(shè)置→高級→啟動和故障恢復設(shè)置下，將寫入調(diào)試信息修改為小內(nèi)存轉(zhuǎn)儲（256K）后，待到下次藍屏時將藍屏dump文件發(fā)與筆者進行分析。

說明：dump文件類型中相對比較常用的是小內(nèi)存轉(zhuǎn)儲、核心內(nèi)存轉(zhuǎn)儲和完全內(nèi)存轉(zhuǎn)儲這三種，自動內(nèi)存轉(zhuǎn)儲和活動內(nèi)存轉(zhuǎn)儲相對使用遇到，故在此不做特別說明。以下是前三種內(nèi)存轉(zhuǎn)儲文件的區(qū)別：

小內(nèi)存轉(zhuǎn)儲：保存內(nèi)存前64K基本內(nèi)存空間的數(shù)據(jù)
核心內(nèi)存轉(zhuǎn)儲：保存操作系統(tǒng)和相關(guān)系統(tǒng)級別服務(wù)的數(shù)據(jù)
完全內(nèi)存轉(zhuǎn)儲：保存內(nèi)存中包括系統(tǒng)數(shù)據(jù)和用戶數(shù)據(jù)的全部數(shù)據(jù)

由于藍屏問題的發(fā)生通常具有突發(fā)性和不可預(yù)知性，同時為保證能在藍屏后快速獲取并保存內(nèi)存轉(zhuǎn)儲文件進行分析，故在大多數(shù)情況下我一般都會設(shè)置為小內(nèi)存轉(zhuǎn)儲以保證能得到文件。（完全/核心內(nèi)存轉(zhuǎn)儲文件體積較大，需要相對較長的時間進行轉(zhuǎn)儲保存，無法保證能在藍屏后成功生成文件的可能性較大，尤其是萬一遭遇諸如斷電等二次災(zāi)害的情況）

分析過程

在得到了友人發(fā)來的兩個dump文件后，筆者將其載入到WinDbg中進行查看。發(fā)現(xiàn)兩者都是同樣的IRQL_NOT_LESS_OR_EQUAL（中斷請求級別不小于或相等）錯誤，意思是試圖在錯誤的中斷級上進行特定操作。

打開第一個文件后，先輸入analyze -v命令查看一下大致情況

可以發(fā)現(xiàn)錯誤進程是ntkrnlmp.exe，這是一個和操作系統(tǒng)注冊表關(guān)聯(lián)的重要系統(tǒng)進程，看來多半是內(nèi)存本身或者驅(qū)動問題了。為了獲取進一步信息，我們使用kv和r命令查看狀態(tài)。

通過查看調(diào)用棧，我們能發(fā)現(xiàn)操作系統(tǒng)執(zhí)行過程中遇到了一個缺頁異常，于是系統(tǒng)調(diào)用了KiTrapoE異常處理函數(shù)來試圖處理問題。但執(zhí)行過程中卻發(fā)現(xiàn)無法因為找到對應(yīng)的物理頁，所以部署了KiBugCheckEx函數(shù)讓系統(tǒng)藍屏。

Windows在調(diào)用異常處理函數(shù)解決異常時，通常會以生成一個陷阱幀（Trap Frame）的形式保存異常出現(xiàn)時候的現(xiàn)場環(huán)境。如果異常被成功解決了，就可以通過定位這個陷阱幀回到異常發(fā)生前的線程，恢復正常執(zhí)行。我們發(fā)現(xiàn)這個陷阱幀的地址是ffffb88c到a024f740，因此使用.trap命令切換到陷阱幀：

通過對比查看，我們可以發(fā)現(xiàn)，出問題前的最后兩個函數(shù)是KiRetireDpcList和KiIdleLoop。前者是系統(tǒng)用來掃描DPC請求隊列來執(zhí)行處理機線程切換的函數(shù)，后者是用以循環(huán)執(zhí)行DPC檢查和堆棧切換的函數(shù)。DPC是Windows驅(qū)動程序在IRQL DISPATCH_LEVEL上請求回調(diào)到任意線程上下文的方法，其需要生成一個DPC對象用以交付內(nèi)核進行中斷級控制。DPC對象的數(shù)據(jù)結(jié)構(gòu)由LIST_ENTRY、回調(diào)指針、回調(diào)上下文和控制數(shù)據(jù)構(gòu)成。

KiRetireDpcList函數(shù)原形

KiIdleLoop函數(shù)原形

于是我猜測是否是由于DPC隊列越界發(fā)生死循環(huán)導致的藍屏？所以接下來我是用db命令查看地址空間。

發(fā)現(xiàn)地址空間全是問號，在WinDbg里這說明這些都是無效內(nèi)容。表示系統(tǒng)無法訪問這一部分的內(nèi)存，因而產(chǎn)生頁面異常。使用irql命令查看一下中斷級別：

由于Windows系統(tǒng)的頁處理只能發(fā)生在2以下的中斷級別上，因此就會報一個IRQL_NOT_LESS_OR_EQUAL錯誤。但僅憑這份文件我仍然無法斷定問題出在哪。是由哪個進程/驅(qū)動程序造成了DPC隊列越界，于是我對第二份dump文件進行了同樣的分析流程。

和第一份文件一樣報的是IRQL_NOT_LESS_OR_EQUAL錯誤，但是不同之處在于PROCESS_NAME字段中出現(xiàn)了360Tray.exe的字樣。

于是我開始懷疑是不是由360造成的問題，接著我再次使用kv;r命令進行檢查

發(fā)現(xiàn)這次的藍屏觸發(fā)更為復雜，一開始是進程死鎖導致陷阱幀生成了一次，然后系統(tǒng)調(diào)函數(shù)來解除死鎖，遇上了缺頁問題，再次生成陷阱幀處理無果，發(fā)送bugcheck藍屏。

結(jié)論

綜合兩次dmp文件分析，筆者認為比較可能的原因是由于360的某些保護機制導致dpc對象訪存進程被拒絕而藍屏。故我已通知友人先將360相關(guān)軟件徹底卸載來檢查是否可以正常使用。

當然也不能排除是不是由于內(nèi)存損壞或者內(nèi)存頻率參數(shù)等對IMC壓力太大導致的訪存失敗，可惜此類問題不藉由TM5等內(nèi)存測試軟件進行較長時間的烤機無法判斷是否穩(wěn)定。暫時只能先讓友人檢查XMP參數(shù)檔位是否為更為穩(wěn)定的XMP I而非XMP II，再經(jīng)由之后的使用情況來決定是否需要動內(nèi)存內(nèi)存參數(shù)或者烤機檢查內(nèi)存穩(wěn)定性。

P.S.第一次寫操作系統(tǒng)內(nèi)核分析的相關(guān)專欄，也是首次在B站投稿。筆者操作系統(tǒng)知識和應(yīng)用水平堪憂，行文中各類遣詞造句恐有不少謬誤，還希望大家海涵并提出批評意見。望共同進步，謝謝。

End.