KERNEL_DATA_INPAGE_ERROR(0x7A)藍屏怎麼修?先讀第二參數分清碟壞或驅動

適用系統:Windows 10 / Windows 11(官方 0x7A / 0x77 頁未做版本層級適用性宣告,chkdsk 官方文件標示適用 Windows 10 / 11 與 Windows Server 2016–2025)
權限需求:系統管理員(chkdsk、記憶體診斷、事件檢視器皆需要)
需要工具:命令提示字元(系統管理員)、事件檢視器、Windows 記憶體診斷;進階分析需 WinDbg(選用)
預計耗時:約 30–120 分鐘

🔍 症狀描述與錯誤訊息

先講你會看到什麼。KERNEL_DATA_INPAGE_ERROR 的典型畫面,是使用中或開機途中突然轉藍,螢幕出現「你的裝置發生問題,需要重新啟動」,停止碼寫著:

KERNEL_DATA_INPAGE_ERROR
或在事件記錄、舊介面中呈現為 0x0000007A、STOP: 0x0000007A

這個停止碼有兩種很不一樣的發作樣貌,值得先分清楚。第一種是隨機跳,常伴隨硬碟燈狂閃、檔案總管卡住數秒才回應、開大型檔案時特別容易觸發——這種通常指向儲存裝置。第二種是開機期間就跳,系統還沒把該載入的東西讀完就倒,反覆進自動修復迴圈,連桌面都到不了。

還有一個容易誤判的點要先講:0x7A 不是「記憶體不夠」的意思。 它講的不是容量,而是「該讀進來的那一頁,讀不進來」。分頁檔(pagefile.sys)放在磁碟上,核心要用某頁資料時若它已被換出到分頁檔,就得從磁碟讀回;這條路上任何一段出事——磁碟壞軌、SATA/NVMe 連線不穩、儲存驅動回錯狀態、RAM 把讀回來的內容弄壞——都會讓核心拿不到那頁資料,然後丟出 0x7A。所以把分頁檔關掉或調大,通常不會解決 0x7A,反而可能掩蓋掉真正的硬體問題。

🔎 問題根因

直接結論:官方對 0x7A 的定義只有一句話——「requested page of kernel data from the paging file couldn’t be read into memory」(要求從分頁檔讀入記憶體的那頁核心資料讀不進來);而具體是哪裡出事,官方要你去看第二個參數的錯誤狀態碼。

Microsoft 官方 Bug Check 0x7A 文件的 Cause 段寫得很直接:「Frequently, you can determine the cause of the KERNEL_DATA_INPAGE_ERROR bug check from the error status (parameter 2).」(通常你可以從錯誤狀態〔第二參數〕判定本 bug check 的成因。)這句話是整篇文章的樞紐——它把「0x7A 到底是什麼壞了」這個問題,收斂成一個可查的數字。

官方接著列出成因清單,除了狀態碼之外還點名三項:「defective storage hardware」(儲存硬體瑕疵)、「failing RAM memory」(記憶體故障),以及「A virus infection can also cause this bug check.」(病毒感染也可能造成此 bug check)。注意這裡的排序意義:儲存與記憶體是主嫌,病毒是官方明列但相對邊緣的分支。

這也是為什麼中文圈最常見的兩個建議——「跳 0x7A 就換 SSD」和「跑個 SFC 就好」——都不夠好。前者在狀態碼指向 0xC000009A(資源不足)時是白花錢:那條路官方歸因於資源與驅動,不是碟壞;後者則根本沒碰到磁碟實體層,壞軌不會因為 SFC 而消失。先讀碼,再決定花錢的方向,這是本文和多數教學最大的差別。

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

直接結論:0x7A 的四個參數有三組不同解讀,而決定用哪一組的,是第一個參數的值與第三個參數是不是 0。

多數人看到藍屏參數就直接跳過,但 0x7A 的參數表其實是官方寫得最「有分支」的幾個之一。依 Microsoft 官方文件,四個參數有三種可能意義:

情況一:第一參數是 1、2 或 3,且第三參數為 0

參數	官方定義
1	持有的鎖類型(1、2 或 3)
2	錯誤狀態(通常是 I/O 狀態碼)
3	鎖類型為 1 時=目前的處理程序;鎖類型為 2 或 3 時=0
4	無法被分頁進記憶體的虛擬位址

情況二:第一參數是 3 或 4,且第三參數不為 0

參數	官方定義
1	持有的鎖類型(3 或 4)
2	錯誤狀態(通常是 I/O 狀態碼)
3	InPageSupport 結構的位址
4	發生錯誤的位址

其他情況

參數	官方定義
1	分頁表項目(PTE)的位址
2	錯誤狀態(通常是 I/O 狀態碼)
3	PTE 的內容
4	發生錯誤的位址

三張表看下來,有一件事是共通的:不管落在哪一組,第二個參數永遠是錯誤狀態(通常是 I/O 狀態碼)。這就是為什麼官方說「通常可以從第二參數判定成因」——它是唯一不隨分支改變位置的情報欄位。第一參數在前兩組是鎖類型、在第三組變成 PTE 位址;第三、第四參數的意義也跟著跳。先看 P2,再回頭決定 P1 該怎麼讀,順序不要反。

這些狀態碼是 NTSTATUS 值,官方在 0x7A 頁面直接連到 NTSTATUS Values 對照表,並在頁面裡列出最常見的幾個具體成因。要拿到這四個參數,你需要 minidump 與 WinDbg——這部分的操作與 !analyze 輸出怎麼讀,站長另有一篇WinDbg 藍畫面 minidump 分析教學可以照著跑,這裡不重複。

KERNEL_DATA_INPAGE_ERROR 0x7A 第二參數分流表:0xC000009C 與 0xC000016A 官方指硬碟壞軌、0xC000009D 等三碼官方指連線與裝置層(線材、終端、IRQ、磁碟設定)、0xC000009A 官方 0x77 頁指儲存堆疊驅動錯誤

官方列出的常見狀態碼

以下六個是 Microsoft 官方在 0x7A 頁面明列、且有具體成因的狀態碼:

狀態碼	名稱	官方指向的成因
0xC000009A	STATUS_INSUFFICIENT_RESOURCES	non-paged pool 資源不足
0xC000009C	STATUS_DEVICE_DATA_ERROR	硬碟壞軌(bad blocks / sectors)
0xC000009D	STATUS_DEVICE_NOT_CONNECTED	線材瑕疵或鬆脫、終端電阻,或控制器看不到硬碟
0xC000016A	STATUS_DISK_OPERATION_FAILED	硬碟壞軌
0xC0000185	STATUS_IO_DEVICE_ERROR	SCSI 裝置終端不當或線材瑕疵,或兩個裝置搶同一 IRQ
0xC000000E	STATUS_NO_SUCH_DEVICE	硬體故障或磁碟設定錯誤

三點重點摘要:

0xC000009C 與 0xC000016A 是同一個方向——官方對兩者的描述都是壞軌,處置也一樣(見下方方法一)。
0xC000009D、0xC0000185、0xC000000E 指向的是「連線/裝置層」而非碟片本身:先別急著買新碟,官方對這三個碼講的是線材、終端、控制器與磁碟設定。官方也特別提醒,若使用較舊的 PATA(IDE)磁碟,0xC000000E 可能代表主/從碟設定錯誤。
0xC000009A 是最容易被誤殺的一個:它是 non-paged pool 資源不足,方向在驅動與資源,不在碟。官方在姊妹碼 0x77(KERNEL_STACK_INPAGE_ERROR)的頁面對同一個狀態碼講得更白:「This status code indicates a driver error in the storage stack.」(此狀態碼代表儲存堆疊中的驅動程式錯誤。)並補了理由:儲存堆疊本來就應該要能取回這份資料,不管軟體資源夠不夠。0x7A 頁面沒有這句、0x77 頁面有,兩頁交叉讀才看得到完整因果——碰到 0xC000009A 請往儲存驅動查,不是往購物車查。

官方頁面同時註明:清單以外的其他狀態碼,要查 Windows Driver Kit(WDK)裡的 Ntstatus.h。

0x7A、0x77、0x50 差在哪

這三個停止碼常被混為一談,但問的是不同問題:

0x7A(KERNEL_DATA_INPAGE_ERROR):核心資料頁從分頁檔讀不回來。
0x77(KERNEL_STACK_INPAGE_ERROR):官方定義同樣是「requested page of kernel data from the paging file could not be read into memory」,但參數表完全不同——它的第一參數 0/1/2 分別代表該頁取自 page cache、取自磁碟、以及取自磁碟且儲存堆疊回報成功但 Status.Information 不等於 PAGE_SIZE。官方對第一參數為 0 或 1 的解讀是核心堆疊的簽章找不到,「probably caused by defective hardware, such as a RAM error」(很可能肇因於硬體瑕疵,例如記憶體錯誤)。同樣是 inpage,0x77 更偏核心堆疊與 RAM,0x7A 更偏資料頁與儲存路徑。
0x50(PAGE_FAULT_IN_NONPAGED_AREA):官方定義是「invalid system memory has been referenced」(參考到了無效的系統記憶體),並說明通常是記憶體位址錯誤、或該位址指向已被釋放的記憶體。這和 0x7A 的「讀不回來」是兩件事,排錯路線也不同(那篇往驅動與 Driver Verifier 走,詳見0x50 藍屏拆四個 Parameter)。

順帶一提,0x7A 與 0x77 兩頁在官方是互相 See also 的姊妹頁——你手上那台如果兩個碼都跳過,硬體嫌疑(尤其 RAM 與儲存)就更值得優先查。

🛠️ 解決方案

⚠️ 高風險操作警語:以下步驟涉及磁碟檢查與修復。chkdsk /f、/r 會變更檔案系統結構,在磁碟已經開始壞掉的情況下,掃描過程本身可能加速硬碟惡化,甚至讓原本還讀得到的資料變成讀不到。
動手前的停止條件(符合任一,請先停):
– 碟裡有你不能失去的資料,而你還沒備份 → 先備份,再修。0x7A 本來就常代表碟在壞,修碟不是救資料的手段。
– 已啟用 BitLocker 但手上沒有 Recovery Key。
– 這是公司/學校管控設備,而你沒有 IT 授權。
– 指令輸出與本文預期不符,你不確定下一步。
資料價值高於系統可用性時,正確順序是:先把碟接到另一台機器或用 WinPE 把檔案複製出來,再回頭做修復。若碟已經有異音或 SMART 已報警,任何額外的全碟讀取都是風險——這種情況請直接送資料救援,不要自己跑 /r。

方法一:先讀狀態碼,再決定走哪條路

直接結論:這一步不是選用的,它決定你後面三十分鐘要花在哪裡。

從藍屏畫面或 minidump 取得第二參數(P2),對照上一節的官方表:

拿到 0xC000009C 或 0xC000016A → 壞軌方向,走方法二。
拿到 0xC000009D、0xC0000185 或 0xC000000E → 連線/裝置方向。官方對這三碼的成因描述分別是:線材瑕疵或鬆脫、終端、控制器看不到硬碟(0xC000009D);SCSI 裝置終端不當或線材瑕疵,或兩裝置搶同一 IRQ(0xC0000185);硬體故障或磁碟設定錯誤(0xC000000E)。注意官方在 Resolution 段對線材/終端的具體指示,明確限定在「分頁檔位於較舊的 SCSI 磁碟」的情境。現代 SATA/NVMe 機器上的對應動作(關機斷電、重插資料線與電源線或 M.2、換線換埠測試)是站長依這三碼的成因描述所做的合理延伸,不是官方逐字步驟。
拿到 0xC000009A → non-paged pool 資源不足,官方(0x77 頁)歸因儲存堆疊驅動錯誤:優先更新或回退儲存控制器驅動(廠商 AHCI/RAID/NVMe 驅動)、檢查是否剛裝過會掛 filter driver 的軟體(防毒、備份、虛擬光碟、加密工具)。
清單以外的碼 → 查 NTSTATUS 對照表確認語意,再決定方向。

若你連藍屏參數都取不到(例如機器一跳就重開、來不及看),先確認傾印檔有正常產生;取不到參數不代表問題不存在,只代表你少了最有效的那條線索。

方法二:對存放分頁檔的磁碟跑 chkdsk

直接結論:官方對 0x7A 的壞軌路線,給的解法就是 chkdsk——官方 0x7A 頁的原文指示是在系統磁碟區跑 Chkdsk /f /r。

官方 0x7A 文件的 Resolution 段寫:I/O 狀態碼 0xC000009C 或 0xC000016A 通常代表因壞軌而讀不到資料;若錯誤後還能重開機,Autochk 會自動執行並嘗試把壞軌對應掉,避免它再被使用。若 Autochk 沒有掃,你可以手動掃——官方原文:「Run Chkdsk /f /r on the system partition.」而如果因為這個錯誤而無法開機,官方要你進 Recovery Console 執行 Chkdsk /r。

依 Microsoft 官方 chkdsk 指令文件,兩個參數的定義是:

/f:修復磁碟上的錯誤,磁碟必須先被鎖定;若 chkdsk 鎖不住該磁碟機,會問你要不要在下次重新啟動時檢查。
/r:定位壞軌並救回可讀取的資訊,磁碟必須被鎖定;官方明寫「/r includes the functionality of /f」(/r 已包含 /f 的功能),差別在額外做實體磁碟錯誤分析。(所以 0x7A 頁的 /f /r 寫法裡,/r 才是那個關鍵參數;兩個都帶是官方原文的寫法,照著下即可。)

以系統磁碟區為例,開「命令提示字元(系統管理員)」執行:

chkdsk C: /f /r

因為系統磁碟區無法在執行中被鎖定,它會提示排程到下次重開機。官方對此的說明是:選擇下次重開機檢查後,chkdsk 會在重新啟動時自動檢查並修正錯誤;若該磁碟分割是開機分割,chkdsk 檢查完會自動再重開機一次。

時間預期(官方說明,非站長實測):官方在 chkdsk 文件裡專門開了一節談不同媒體的差異——HDD 是機械式磁頭移動,/r 要讀過每一個磁區,「High-hour runtimes aren’t uncommon for large drives.」(大容量磁碟跑上好幾個小時並不罕見。)所以請挑一個你不需要用電腦的時段做。

反過來,如果大容量 HDD 的 chkdsk 跑得異常快,官方列了四個可能原因,值得警覺:磁碟區被 OS 或其他處理程序標為 dirty 或鎖定;chkdsk 實際上沒有掃過每個磁區;硬碟可能有讀取頭故障或其他硬體問題,導致 chkdsk 行為不可預期;或該次只做了檔案系統結構的線上掃描,沒有在進 OS 前跑離線掃描。「一下就跑完了,應該沒事」是誤讀。

看結果,不要只看它跑完。官方定義了 chkdsk 的結束代碼:0=未發現錯誤;1=發現錯誤且已修復;2=執行了磁碟清理(如垃圾回收),或因未指定 /f 而未執行清理;3=無法檢查磁碟、錯誤無法修復,或因未指定 /f 而未修復。要事後回看報告,官方給的方法是開事件檢視器 → 展開「Windows 記錄」→ 在「應用程式」上按右鍵 →「篩選目前的記錄檔」→ 在「事件來源」下拉選 Chkdsk 與 Wininit。

最後一個官方提醒:chkdsk 只能用於本機磁碟,不能用在透過網路重新導向的磁碟機代號。

方法三:記憶體、事件記錄與其餘官方指定動作

直接結論:碟查完是乾淨的,下一個嫌疑犯是 RAM——這是官方在同一份文件裡明列的方向。

官方 0x7A 的 Resolution 段落對 RAM 的指示是:「Run the hardware diagnostics that the system manufacturer supplies, especially the memory scanner.」(執行系統製造商提供的硬體診斷,特別是記憶體掃描工具。)Windows 內建的記憶體診斷(mdsched.exe)是最沒有門檻的起點,操作細節見站內Windows 記憶體診斷工具教學;廠牌機另外常附自家診斷工具,官方要你優先用它們。

官方在同一段列出的其餘動作,一併整理:

查事件檢視器的系統記錄:官方要你找「bug check 發生前那一刻」的錯誤訊息,它們往往直接點名出事的裝置。這是最便宜的一步,先做。
裝好最新的 Windows 更新:官方原文「Make sure that the latest Windows updates are installed.」
跑 PC 可用的診斷測試軟體:官方提醒主機板上的裂痕、刮傷的線路或故障元件都可能造成本 bug check。
檢查介面卡是否插好:有卡槽的 PC,官方要你確認所有介面卡確實插到位,並清潔接點。
病毒掃描:官方指出應使用能檢查硬碟主開機記錄(MBR)的最新商用防毒軟體,並提醒 Windows 檔案系統可能被病毒感染。

補一個官方沒寫、但實務上該做的事:看 SMART。0x7A 的壞軌路線與磁碟健康度高度相關,而 SMART 的重新配置磁區計數、待處理磁區計數這類欄位,能在你花好幾小時跑 /r 之前就先告訴你這顆碟的狀態——怎麼看見站內用 CrystalDiskInfo 檢查硬碟健康度。這是站長基於官方成因清單(儲存硬體瑕疵)所做的合理延伸,不是官方步驟。

✅ 驗證修復結果

直接結論:「這幾天沒跳了」不算修好——0x7A 的成因多半是硬體漸進劣化,沉默期不代表痊癒。

依序確認這幾項:

chkdsk 的結束代碼與事件記錄:回事件檢視器篩 Chkdsk / Wininit 來源,確認這次是 0(未發現錯誤)或 1(已修復),而不是 3(無法檢查/未修復)。
重跑一次 chkdsk 是否還在報同樣的壞軌:官方不建議中斷 chkdsk,但也說明取消或中斷「應不會」讓磁碟區比執行前更損毀,再跑一次會檢查並修復剩餘的損毀。反過來說,若同樣位置反覆被報,代表壞軌在擴散,該換碟了。
SMART 的待處理/重新配置磁區數有沒有繼續長:數字持續增加=碟在惡化,修再多次都是拖時間。(SMART 不在官方 0x7A 的步驟清單內,這是站長依官方「儲存硬體瑕疵」成因所做的延伸判準。)
同一個狀態碼有沒有再出現:再跳一次時務必再讀一次 P2。若從 0xC000009C(壞軌)變成 0xC000009A(資源不足),那是完全不同的問題,不要沿用舊結論。

🔙 萬一翻車:回退步驟

情境一:chkdsk 跑到一半當機或斷電

官方明講不建議中斷 chkdsk,但也說明取消或中斷「應不會」(shouldn’t)讓磁碟區比執行前更損毀,再執行一次即可檢查並修復剩餘問題。所以正確動作是:恢復供電後再跑一次同樣的 chkdsk,而不是慌張地重灌。注意官方用的是「應不會」而非保證。若第二次連 chkdsk 都跑不起來,代表磁碟狀況已經惡化到需要離線處理——改用另一台機器接碟,優先複製資料出來。

情境二:chkdsk 之後檔案不見或系統起不來

/r 會嘗試救回可讀取的資訊,但壞軌上原本的資料本來就可能已經讀不出來。若修完後系統無法開機,先用 Windows RE 的「啟動修復」;仍不行則從備份或系統映像還原。這也是為什麼警語要你先備份——這一步沒有無痛回退鍵,備份就是你的回退鍵。

情境三:換了線/換了埠反而更糟

回到原本的接法,一次只改一個變因。同時改線又改埠,結果變好或變壞你都不知道是誰造成的。

💡 總結:預防再次發生

站長我看過太多 0x7A 的處理是這樣的:跳藍屏 → 上網查 → 看到「記憶體」三個字 → 買一條 RAM 插上去 → 過兩週照跳 → 重灌 → 再過兩週又跳,最後才發現碟早就在報壞軌。這條冤枉路的起點,是把「讀不回來」誤讀成「記憶體不夠」。 官方那句話值得再讀一次:requested page of kernel data from the paging file couldn’t be read into memory——重點在 *couldn’t be read*(讀不到),不在 memory 的容量。

從官方文件的成因結構往回推,預防 0x7A 其實只有三件事真正有用:

把 SMART 當儀表板,不是出事才看(同前:官方步驟裡沒有 SMART,這是站長依官方「儲存硬體瑕疵」成因所做的延伸)。0x7A 的兩個壞軌狀態碼所對應的物理現象,SMART 通常會先反映。一顆已經開始長待處理磁區的碟,不會自己好起來。
儲存驅動不要亂裝也不要不裝。0xC000009A 那條路官方直指儲存堆疊的驅動錯誤;防毒、備份、加密這類會掛 filter driver 的軟體,每多裝一個就多一層在你和碟之間。
資料備份與系統可用性分開想。0x7A 常常是碟在告訴你它快不行了,那個當下你最該保住的是資料,不是「今天能不能開機」。

最後一個誠實的提醒:本文所有技術事實均來自 Microsoft 官方文件的交叉查證,不是站長的第一手實測。四個參數的三組解讀、六個狀態碼的成因、chkdsk 的參數語意與結束代碼,都可以在文末的官方連結逐條對回去。你手上那台的實際狀況,還是要用你自己的 P2 來判。

❓ 常見問題

Q:跳 KERNEL_DATA_INPAGE_ERROR 是不是一定要換硬碟?

不一定。官方把成因分成好幾條路:狀態碼 0xC000009C、0xC000016A 才是壞軌方向;0xC000009D、0xC0000185、0xC000000E 講的是線材、終端、控制器或磁碟設定;0xC000009A 則是 non-paged pool 資源不足,官方(0x77 頁)歸因於儲存堆疊的驅動錯誤。先讀第二參數,再決定要不要花錢。

Q:把分頁檔關掉或搬到別顆碟,是不是就不會跳了?

這是治標而且可能誤導自己。0x7A 是「讀不回來」的訊號,關掉分頁檔可能只是讓症狀換個形式出現(例如改跳別的停止碼),而底下那顆正在壞的碟、或那個回錯狀態的驅動還在。官方的解法清單裡也沒有「關閉分頁檔」這一項。

Q:chkdsk 要跑 /f 還是 /r?

官方 chkdsk 文件明寫 /r 已包含 /f 的功能,並額外做實體磁碟錯誤分析。官方 0x7A 頁面給的指示是在系統磁碟區跑 Chkdsk /f /r,無法開機時用 Recovery Console 跑 Chkdsk /r。單就 0x7A 的壞軌路線而言,/r 是那個關鍵參數。

Q:我的 chkdsk 幾分鐘就跑完了,是不是代表碟很健康?

不一定。官方在 chkdsk 文件中專門提醒:大容量 HDD 的 /r 若異常快速完成,可能是磁碟區被標記為 dirty 或被鎖定、實際沒掃過每個磁區、硬碟有讀取頭故障等硬體問題導致行為不可預期,或只做了線上的檔案系統掃描而沒有跑離線掃描。看結束代碼與事件記錄比看時間可靠。

Q:修完之後又復發怎麼辦?

再讀一次第二參數,不要沿用上次的結論——狀態碼變了代表問題換人了。若是同一個壞軌碼反覆出現、SMART 的待處理或重新配置磁區數持續增加,那不是「沒修好」,而是這顆碟已經進入劣化末期,該做的是備份與更換,不是再跑一次 chkdsk。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug check 0x7A: KERNEL_DATA_INPAGE_ERROR — Microsoft Learn — 2026-07-17 查證
Bug Check 0x77: KERNEL_STACK_INPAGE_ERROR — Microsoft Learn — 2026-07-17 查證
chkdsk — Microsoft Learn(Windows Commands) — 2026-07-17 查證
NTSTATUS Values — Microsoft Learn(MS-ERREF) — 2026-07-17 查證
Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA — Microsoft Learn — 2026-07-17 查證

⚠️ 本文核心事實以第一級為準。本文為官方文件交叉查證之深度整理,非第一手實測,文內未宣稱任何站長實測數據。

📅 本文查證戳記:2026-07-17 依據 Microsoft 官方 Windows 驅動程式文件與 Windows Commands 文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。