UNEXPECTED_STORE_EXCEPTION 0x154 藍屏|先別換 SSD

⚡ 站長快讀:核心重點

文章屬性:疑難排除(A5 底層除錯)
適用系統:Windows 10 / 11(含 24H2、25H2)
難易度 / 耗時:⭐⭐ 中等 / 依硬體檢測約 30–90 分鐘
核心結論:UNEXPECTED_STORE_EXCEPTION(0x154)是核心記憶體壓縮 store 元件抓到未處理例外,嫌疑集中在老化 SSD/硬碟、不穩 RAM 與儲存堆疊驅動,先驗硬體再談重灌。
適用對象:隨機或開機時跳 0x154 藍屏、被網路文章叫去「直接重灌或換 SSD」的人

📌 快速答案

一句話答案:UNEXPECTED_STORE_EXCEPTION(0x154)代表核心記憶體壓縮 store 元件抓到未預期例外,主因多為 SSD/硬碟老化、RAM 不穩或儲存驅動衝突;正確做法是先用 S.M.A.R.T. 與記憶體診斷驗硬體,別急著重灌或換碟。

🧰 開始前的準備

適用系統:Windows 10 全版本、Windows 11(含 24H2 / 25H2)
權限需求:系統管理員(跑 chkdsk、SFC、DISM 需要)
需要工具:事件檢視器(內建)、Windows 記憶體診斷(內建)、CrystalDiskInfo(免費)、WinDbg(選用,讀 minidump)
預計耗時:基本檢測 30 分鐘;完整記憶體/磁碟掃描含重開機 60–90 分鐘
最重要的前提:先確認資料有備份。0x154 有相當比例是儲存裝置在垂死邊緣,任何磁碟修復動作都可能是壓垮它的最後一根稻草。

⚠️ 動手前先看這行:如果你已經三不五時跳 0x154、開檔越來越慢、或聽到硬碟異音,請先把重要資料複製出來再開始除錯。下面的 chkdsk /f /r 對一顆快掛的碟,有機會讓它從「偶爾藍屏」變成「完全認不到」。

🔍 症狀描述與錯誤訊息

第一句先講結論:看到這個藍屏,先當它是「硬體健康警告」,不要先當成 Windows 壞掉。

UNEXPECTED_STORE_EXCEPTION 的典型畫面,是 Windows 跳出經典的 :( 藍色畫面,底下寫著:

你的裝置發生問題,需要重新啟動。
停止代碼(Stop code):UNEXPECTED_STORE_EXCEPTION

對應的十六進位 Bug Check 代碼是 0x00000154(常被簡寫成 0x154)。它的發作模式通常有幾種:開機到登入畫面就跳、掛機或跑大型程式時隨機跳、或是複製大量檔案 / 系統更新到一半跳。有些人會伴隨另一顆停止代碼(例如 MEMORY_MANAGEMENT),這其實是同一個線索——都指向記憶體與儲存這條路徑。

一個很容易誤導人的點:名稱裡的 STORE 不是指「Microsoft Store 市集 App」,也不完全等於「你的硬碟儲存」。它指的是 Windows 核心裡負責記憶體壓縮的 store(儲存區)元件。搞錯這個字,就會被網路上一堆「重裝市集」「清 Store 快取」的文章帶去繞遠路。

🔎 問題根因

先給直接結論:0x154 幾乎都是硬體或驅動層級的問題,不是隨便清一清、重灌一次就會好。

根據微軟官方 Bug Check 文件,0x154 代表「核心記憶體 store 元件抓到一個未預期的例外」。翻成白話,就是 Windows 在處理記憶體壓縮(memory compression)這條路徑時,拿到一頁它預期應該正常、結果卻壞掉的資料,而這個例外沒有人接手處理,系統只好直接藍屏保護自己。

會讓那一頁資料「壞掉」的來源,現實中收斂成三大類:

儲存裝置老化或故障:SSD/硬碟的分頁檔(pagefile)區塊、韌體、或壞軌讓讀回來的資料出錯。這是最常見的一類,尤其 SSD 進入壽命末期時。
記憶體(RAM)不穩:壓縮 store 本身活在記憶體裡,RAM 有一個位元不穩,解壓縮出來就是垃圾。這也是為什麼 0x154 常跟 MEMORY_MANAGEMENT 一起出現。
儲存堆疊驅動衝突:掛在 I/O 路徑上的第三方防毒、備份、加密軟體的檔案系統過濾驅動,插手時把資料弄壞。權威技術媒體 The Windows Club 就點名過某些第三方防毒(如 McAfee)是常見兇手之一。

換句話說,這是一個「硬體健檢題」,不是「Windows 設定題」。這也是本文跟多數「跑個 SFC 就叫你重灌」教學最大的差異:先分流是哪一類,再決定要不要花錢。

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

這一段是給想知其所以然的人。看不懂可以跳過,不影響照著解。

Windows 8 起導入了記憶體壓縮機制,由核心的 Store Manager 負責。它的用意很實際:與其把不常用的記憶體頁直接寫到硬碟分頁檔(慢),不如先在記憶體裡用壓縮演算法(Xpress)壓起來,需要時再解壓縮回去。這樣能少寫一點分頁檔、也少一點磁碟往返的延遲。

問題就出在「解壓縮」這一步。根據除錯社群(如 Sysnative、BSOD 除錯部落格)的分析,當 store 要把某一頁解壓縮回來時,如果:

這頁資料是從分頁檔讀回來,而底層磁碟發生 in-page I/O 錯誤(碟讀不回正確資料);或
這頁還在記憶體裡,但 RAM 有位元翻轉,資料已經不是原本壓縮好的樣子;

那麼 Xpress 解壓縮就會踩到一個無效的記憶體位址,丟出例外。這個例外在 store 元件裡沒有對應的處理,一路往上沒人接,最後核心觸發 Bug Check 0x154 把系統停下來。

💡 為什麼這個理解很重要? 因為它同時解釋了「為什麼 0x154 的兇手可能是硬碟、也可能是 RAM」——兩者都在這條「壓縮頁 → 解壓縮」的鏈上。你要做的不是猜,而是分別驗證這條鏈的兩端硬體。

微軟官方對 0x154 只列出四個參數,其中真正有用的是前兩個:參數 1 是指向 store context / data manager 的指標,參數 2 是例外資訊。這兩個要靠 WinDbg 跑 !analyze -v 才看得到細節,一般人不必硬讀,交給下面的流程即可。

🛠️ 解決方案

⚠️ 高風險提醒:方法二含 chkdsk /f /r。若 S.M.A.R.T. 已經示警(下方會教怎麼看),請務必先完成資料備份再執行;對垂死的碟強制掃描修復,有機會直接讓它下線。

順序刻意這樣排:先讀證據 → 驗兩端硬體 → 再修軟體。不要跳著做。

方法一:先讀證據,別急著動手

成功率最高的第一步不是修,而是看。先讓系統告訴你它自己認為哪裡出事。

按 Win + R → 輸入 eventvwr.msc → Enter,開啟事件檢視器。
到 Windows 記錄 → 系統,找藍屏當下同一時間點的紅色「錯誤」或「重大」事件。特別留意來源是 disk、Ntfs、stornvme、volmgr、Kernel-Power 的項目——這些直接把矛頭指向儲存。
若你會用 WinDbg,把 C:\Windows\Minidump\ 下最新的 .dmp 拉進去跑 !analyze -v,看 MODULE_NAME 與 IMAGE_NAME 是誰。這一步能把「猜」變成「看到」。完整讀法可參考站上的 WinDbg 藍畫面 minidump 分析教學。

事件檢視器裡若同時看到大量 disk 事件 ID 或 stornvme 警告,基本上不用往下猜了,直接跳到方法二的儲存檢測。

方法二:驗儲存(S.M.A.R.T. + chkdsk)

先給結論:S.M.A.R.T. 是免費、非破壞性的第一關;chkdsk 才是有風險的第二關。順序不能反。

下載並開啟 CrystalDiskInfo,看你系統碟的健康狀態。若「健康度」顯示黃色(注意)或紅色(不良),或「重新配置磁區數 / 待決磁區數 / 無法校正磁區數」不是 0,代表這顆碟正在壞——這時第一件事是備份,不是修。看不懂 S.M.A.R.T. 欄位可參考用 CrystalDiskInfo 檢查硬碟/SSD 健康度。
確認資料已備份、且 S.M.A.R.T. 沒有紅字後,再用系統管理員身分開命令提示字元,執行磁碟檢查:

chkdsk C: /f /r

系統會提示重開機時執行,輸入 Y 後重新開機。/r 會逐磁區掃描,大碟可能要跑數小時,請預留時間、接好電源。

也順手更新 SSD 韌體(到 SSD 原廠工具)與主機板晶片組 / 儲存控制器驅動(到主機板原廠),舊韌體與舊 NVMe 驅動是已知的 0x154 誘因。

方法三:驗記憶體(RAM)

如果儲存那端查起來很健康,把嫌疑轉到 RAM。

按 Win + R → 輸入 mdsched.exe → Enter,選「立即重新啟動並檢查」,跑 Windows 記憶體診斷。想測得更徹底,開機進入測試畫面後按 F1,把 Test Mix 調成 Extended,再按 F10 套用。
要更嚴謹就用 MemTest86 開機碟跑幾輪(過夜)。只要出現任何一個紅色錯誤,就是 RAM/主機板/XMP 的問題。
若有超頻或開 XMP/EXPO,先回預設值再測一輪,排除是記憶體超頻不穩造成的假故障。

方法四:修系統檔與排除軟體

硬體兩端都驗過沒問題,才輪到軟體層。

系統管理員開命令提示字元,依序修復系統映像與系統檔:

DISM /Online /Cleanup-Image /RestoreHealth

SFC /scannow

先 DISM 後 SFC 的原因與逐步解讀,可看 SFC 與 DISM 系統檔修復教學。

關閉快速啟動:控制台 → 電源選項 → 選擇按下電源按鈕時的行為 → 變更目前無法使用的設定 → 取消勾選「開啟快速啟動」。快速啟動在少數機器上會讓驅動載入不完整而誘發 0x154。
暫時移除第三方防毒 / 備份 / 加密軟體:這類軟體的檔案系統過濾驅動是常見兇手。先解除安裝(不是只關掉),用內建的 Windows 安全性頂著,觀察是否還會跳。
到裝置管理員看有沒有帶驚嘆號(!)的裝置,更新對應驅動;顯示卡驅動可先進安全模式乾淨重裝一次。

✅ 驗證修復結果

改完不要馬上宣布沒事,0x154 是間歇性的,得用「有沒有再犯」來驗,而不是「開得起來」。

看藍屏有沒有再來:正常使用(含你平常會觸發它的情境,例如複製大檔、玩遊戲)觀察 3–7 天。
回頭看事件檢視器:確認系統記錄裡不再出現新的 disk / Ntfs / bugcheck 錯誤。
確認 S.M.A.R.T. 沒惡化:過幾天再開一次 CrystalDiskInfo,重新配置磁區數若持續增加,代表碟還在退化,別心存僥倖。
想留證據追蹤下次藍屏,建議確認系統有保留 minidump(預設就會存在 C:\Windows\Minidump\)。

🔙 萬一翻車:回退與救援

情境一:chkdsk 跑完後碟認不到 / 開不了機

代表這顆碟本來就在垂死邊緣。別再對它做任何寫入或修復。用另一台電腦接上(或用 USB 外接盒),優先把資料救出來;硬體層面就是準備換碟。這也是為什麼前面一直強調先備份。

情境二:改完驅動 / 關快速啟動後反而更不穩

進安全模式(開機時 Shift + 重新啟動 → 疑難排解 → 進階選項 → 啟動設定 → 安全模式),把剛剛的變更還原;或用系統還原回到動手前的還原點。

情境三:一直卡在藍屏迴圈、進不了桌面

連續藍屏三次後 Windows 會自動進 WinRE(修復環境)。從那裡可以進安全模式、系統還原,或用命令提示字元手動跑 chkdsk / SFC。若連 WinRE 都進不去,就要用另一台電腦做 Windows 安裝隨身碟開機救援。

💡 總結:預防再次發生

站長我除錯這麼多年,對 0x154 最想講的一句話是:它是少數「藍屏代碼本身就在告訴你去驗硬體」的類型,偏偏最多人第一步就跑去重灌。 重灌會讓症狀暫時消失(因為重建了分頁檔與壓縮 store),於是你以為修好了,結果過幾週又跳——因為那顆退化的 SSD 或那條不穩的 RAM 根本沒動過。

我的處理原則很固定:先讀證據(事件檢視器 + minidump),再分別驗儲存與記憶體兩端,最後才碰軟體。 這個順序能幫你在「該備份的時候備份、該換碟的時候換碟」,而不是把時間花在一輪又一輪的重灌上。

三個能真正降低復發率的動作:第一,SSD 別長期塞到全滿,留一點空間給主控做平均抹寫與 over-provisioning,壽命末期的隨機出錯會少很多;第二,BIOS、SSD 韌體、晶片組/NVMe 驅動保持在原廠較新版本,很多 0x154 是舊韌體對上新系統的相容性地雷;第三,對來路不明的第三方防毒與「系統優化」工具保持距離,它們插在 I/O 路徑上的驅動是這類藍屏的隱形常客。

📌 誠實說明:本文屬深度整理型,核心事實以微軟官方 Bug Check 文件為準,底層機制參考公開的除錯社群分析,並非站長第一手實機重現;文中不含任何實測數字或特定硬體宣稱。你若手上有 minidump 願意提供,歡迎在留言區貼 !analyze -v 的輸出,我可以幫你一起判。

❓ 常見問題

Q:UNEXPECTED_STORE_EXCEPTION 一定是 SSD 要壞了嗎?

不一定,但它是機率最高的一類,所以要第一個排除。實務上三大嫌疑是儲存裝置、RAM、儲存堆疊驅動(防毒/備份)。先用 S.M.A.R.T. 與記憶體診斷分流,別只憑一顆代碼就下定論換碟。

Q:我跑了 SFC 顯示修好了,但過幾天又跳,怎麼辦?

SFC 只修系統檔,修不了硬碟壞軌或壞 RAM。會復發代表根因在硬體那端。回到方法二、方法三,認真驗 S.M.A.R.T. 與記憶體;必要時用 MemTest86 過夜測。

Q:這個藍屏跟「Microsoft Store 市集」有關嗎?需要清 Store 快取嗎?

沒有關係。名稱裡的 STORE 指的是核心記憶體壓縮的 store 元件,不是市集 App。清市集快取對 0x154 沒有幫助,別被誤導。

Q:可以直接關掉記憶體壓縮來避免它嗎?

不建議把關閉壓縮當「解法」。就算關了,底層那顆壞碟或壞 RAM 還在,只是換一種藍屏給你看。把力氣花在找出並更換故障硬體才是正解。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0x154 UNEXPECTED_STORE_EXCEPTION — Microsoft Learn — 2026-07-05 查證
Use the System File Checker tool — Microsoft Support — 2026-07-05 查證

📖 第二級|權威技術媒體:

UNEXPECTED STORE EXCEPTION BSOD on Windows 11/10 — The Windows Club — 2026-07-05 查證

⚠️ 本文核心事實以第一級為準,第二級與除錯社群分析為補充;底層機制屬公開技術分析,非站長第一手實測。

📅 本文查證戳記:2026-07-05 依據微軟官方 Bug Check 0x154 文件與公開技術資料整理撰寫。
若你在後續版本遇到步驟失效,或手上有 minidump 想一起判,歡迎在留言區回報。