stornvme Event 129 SSD 卡死排查:先別急著換碟

⚡ 站長快讀:核心重點

• 屬性 / 系統:疑難排除(A5)/ Windows 10、11
• 難易度:⭐⭐⭐(含登錄檔)
• 核心結論:不是 stornvme.sys 壞了,是 storport 等不到回應而重設碟。
• 適用對象:電腦突然凍住、跳「Reset to device」的人

📌 快速答案

一句話答案:stornvme Event 129 SSD 卡死,是 storport 等不到 SSD 回應而強制重設 SSD,常見起點是韌體或電源管理(站長經驗歸納),不是 stornvme.sys 故障。

🧰 開始前的準備

• 適用系統:Windows 8.1 以上(stornvme.sys 為系統內建 NVMe miniport 驅動,自 Windows 8.1 / Windows Server 2012 R2 起提供);本文以 Windows 10 / 11 桌機與筆電為主
• 權限需求:讀「系統」事件記錄檔一般帳戶即可;方法二的 chkdsk / fsutil 與方法三改登錄檔必須系統管理員
• 需要工具:
  · 事件檢視器(Event Viewer,eventvwr.msc,Windows 內建)
  · PowerShell(內建,用來查事件與 NVMe 健康狀態)
  · SSD 原廠工具箱(依品牌:Samsung Magician、WD Dashboard、Crucial Storage Executive、Kingston SSD Manager 等,用來更新韌體)
• 預計耗時:分診約 20 分鐘;完整排查含韌體更新與觀察期 1–2 小時
• ⚠️ 動手前先做:把重要資料備份出去。Event 129 代表已經有 I/O 逾時被中止重試,這個狀態下的碟不該被當成穩定儲存空間看待。

🔍 症狀描述與錯誤訊息

Event 129 的典型災情長這樣:電腦用得好好的,畫面突然凍住——滑鼠還能動,但視窗全部無回應,工作管理員叫不出來;過了數秒到數十秒不等,系統又若無其事地恢復,像什麼都沒發生(實際凍結長度受該機的逾時設定影響)。嚴重一點的情況是複製大檔案、遊戲讀圖、開虛擬機或跑編譯時整台卡死,甚至直接藍屏。事後翻事件檢視器,就會在「Windows 記錄檔 → 系統」看到一整排警告,來源寫著 stornvme。

錯誤訊息原文如下:

來源(Source):stornvme 事件識別碼(Event ID):129 層級(Level):警告(Warning) 描述(Description):Reset to device, \Device\RaidPort0, was issued. (中文版顯示為「已對裝置 \Device\RaidPort0 發出重設。」)

微軟官方文件裡的範例格式與此一致,只是 RaidPort 編號與來源名稱會依機器而異(Microsoft Learn,Understanding Storage Timeouts and Event 129 Errors,官方事實):

Event ID: 129 Description: Reset to device, \Device\RaidPort1, was issued.

這裡有兩個細節先講清楚,因為九成的誤診都從這兩點開始:

1. \Device\RaidPort0 不代表你組了 RAID。這是 storport 對「儲存介面卡(adapter)」的內部命名,單顆 NVMe SSD 直插主機板一樣會叫 RaidPort0。看到 Raid 就跑去 BIOS 翻 RAID 設定,方向錯了。
2. 來源欄的 stornvme 不是在指控 stornvme.sys。下一節詳談。

🔎 問題根因

先給結論:Event 129 是「結果」,不是「原因」。 它告訴你的事實只有一件——Windows 對這顆 SSD 送出的某個 I/O 請求,在逾時時間內沒有回來,所以 storport 放棄等待,直接重設整顆裝置。至於 SSD 為什麼不回應,129 這行字完全沒說。

依微軟官方在 資料損毀與磁碟錯誤疑難排解指引(2026-02-12 更新)的定調,Event 129 表示「儲存子系統過載,導致請求逾時」,並列出兩類成因:LUN 沒有回應、以及故障的 SAN 路由器等硬體問題造成請求被丟棄。

⚠️ 先界定範圍:官方講的是伺服器,你家是桌機

這裡必須誠實說明一件事:微軟這份文件與 2011 年那篇 Event 129 解說,語境都是企業伺服器與 SAN 儲存網路——LUN、光纖、HBA、SAN fabric。你家桌機沒有 SAN、沒有光纖交換器,也沒有 SAN 路由器。

微軟官方目前並沒有一份文件,專門說明消費級 NVMe SSD 出現 stornvme Event 129 該怎麼辦。

所以底下的成因對應,是把官方的機制說明,套回消費級硬體實際成立的對應項——機制部分有官方依據,「哪個零件最可能」則屬於站長的經驗歸納。本文逐項標示證據等級,不把推論寫成官方結論。

在消費級 NVMe 上,實務上會讓 SSD 在逾時窗內沒回應的,主要是這幾類。請特別注意右欄:下表的成因清單是站長的經驗歸納,微軟官方並未發布消費級 NVMe 的 Event 129 成因排名,本文也未逐項附上原廠韌體說明或第三方實測連結——所以整張表請當作「排查順序建議」,不是「官方認證的成因機率表」。

排序刻意這樣排:先查免費、可逆、風險最低的(韌體、電源設定),最後才懷疑硬體壞掉。 網路上「跳 129 就是碟要死了,快換」的說法,把成本最高、最不可逆的結論放第一位,依站長經驗,韌體與電源管理是更值得優先排除的起點(經驗歸納,非官方成因排名)。

📌 延伸一層:如果你的 SSD 已經用到接近全滿,控制器的 GC 與 SLC 快取空間會被壓縮,長時間大量寫入更容易觸發延遲暴增——這也是 Event 129 常在「複製大檔」時集中出現的原因之一。詳細原理見〈為什麼 SSD 不能填滿?硬碟留白與 Over-Provisioning 原理完整解析〉。

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

先給結論:記錄這行錯誤的是 storport.sys,但事件來源欄印的是 miniport 驅動的名字,也就是 stornvme。誤會全部從這裡開始。

要看懂這句話,得先知道 Windows 的儲存 I/O 堆疊怎麼分層。依微軟官方說明,Windows I/O 採分層架構,由上而下依序是:檔案系統 → 磁碟區管理員 → 磁碟驅動(disk.sys)→ 連接埠驅動(port driver)+ 迷你埠驅動(miniport driver)。

流程是這樣走的:

1. 檔案系統把檔案的區塊號換算成磁碟區位移,磁碟區管理員再換算成磁碟區塊號,交給磁碟驅動。
2. 磁碟驅動建立 CDB(Command Descriptor Block),包進 SCSI_REQUEST_BLOCK(SRB),以 IRP 形式送給 port driver。
3. port driver 就是 storport.sys,它負責大部分請求處理——包含「提供請求的計時服務」、「控制佇列深度」、「建立 scatter gather 陣列」。
4. storport 呼叫 miniport 的 HwStorStartIo(),把請求交給 miniport;miniport 是負責跟特定介面卡對話的驅動。對 NVMe SSD 來說,這支 miniport 就是微軟系統內建的 stornvme.sys——官方定義為「系統提供的儲存 miniport 驅動,用以存取高速 NVMe 裝置」,自 Windows 8.1 與 Windows Server 2012 R2 起提供(Microsoft Learn,NVMe features supported by StorNVMe,官方事實)。
5. 請求送進 miniport 後,storport 把它放進 pending queue 並開始計時。

計時機制官方講得很清楚:每個邏輯單元一個計時器,初始值 -1;第一個請求送出時,計時器設為 SRB 裡的逾時值,每秒遞減 1;每當有請求完成,計時器就用佇列開頭那個請求的逾時值重新整理。所以只要請求持續完成,計時器永遠不會歸零。

一旦計時器歸零,代表裝置已經停止回應——這時 storport 就記下 Event ID 129,然後採取矯正動作:重設該單元。裝置被重設時,所有未完成的請求都會以錯誤結束,並被重試。

關鍵的一句在這裡(官方原文重點):事件裡之所以印 HBA 驅動的名字,是因為那支 miniport 是與 storport 關聯的那一支。

換句話說:

stornvme 在 Event 129 裡的角色是「報案人」,不是「嫌犯」。 storport 只是用「我等不到回應的那顆裝置,是誰家的 miniport 在管」來標示這筆事件。看到 stornvme 就跑去 Google「stornvme 驅動更新」是白費工——stornvme.sys 是 Windows 內建元件,不存在獨立下載更新的管道,你唯一能動它的方式是更新 Windows 本身。

129 / 153 / 157 三兄弟:用組合判斷嚴重度

這三個事件是同一套儲存堆疊的不同層級在說話,合起來看才有意義。下表的「誰記的」與「意義」兩欄依據微軟官方 疑難排解指引 與 Interpreting Event 153 Errors(官方事實);「對應症狀」欄官方文件並未提供,屬站長經驗歸納(推論):

官方對 153 與 129 的差異講得很直接:153 是 miniport 逾時、129 是 storport 逾時。miniport 之所以自己計時,是因為它更了解請求的執行環境,可以只中止單一請求並回傳錯誤,而不必讓 storport 重設整顆碟——重設對 I/O 子系統是有破壞性的,只為了一個請求逾時而重設並不必要。

這張表就是你的分診依據:

• 只有 153,零星出現:官方說法是偶發逾時「可能是系統正常運作的一部分」,但頻繁重試代表儲存有效能問題,應該修正。先觀察、先備份,不必立刻拆機。
• 129 反覆出現:已經到「整顆裝置被重設」的程度,未完成的寫入全部中止重試——這是資料損毀的實質風險窗,請往下走完整排查。
• 129 之後跟著 157:碟直接掉了。官方對 157 的定調是「系統與磁碟之間的通訊被中斷」,成因包含磁碟故障、匯流排問題、或連線被拔掉。這是最嚴重的組合,優先做的事是備份,不是修理。
• 129 伴隨 Event 55 / 98(檔案系統要求 chkdsk):表示逾時已經造成檔案系統結構受損,參考下方方法二。

💡 如果你的機器同時還在跳 UNEXPECTED_STORE_EXCEPTION(0x154)或 DPC_WATCHDOG_VIOLATION(0x133),那多半是同一條儲存路徑上的問題在不同層級爆出來——這兩個停止碼的完整拆解見〈電腦隨機跳 UNEXPECTED_STORE_EXCEPTION(0x154)?先別急著換 SSD 或重灌〉與〈電腦一直跳 DPC_WATCHDOG_VIOLATION?先別重灌,八成是這支驅動程式〉。

🛠️ 解決方案

先給結論:解法依「風險由低到高」排序——先更新韌體、再試 PCIe 電源管理、接著硬體側檢查,最後才考慮動登錄檔。 請照順序做,不要跳到最後一步。

⚠️ 高風險警語(⭐⭐⭐):本節方法三涉及登錄檔修改,方法一涉及SSD 韌體更新——韌體更新過程中斷電有讓 SSD 直接變磚的風險。動手前: – 先完整備份重要資料。已經跳 129 的碟隨時可能惡化。 – 筆電請接上電源並確認電量 > 50%;桌機建議避開雷雨或供電不穩時段。 – 停止條件清單(符合任一,請勿繼續,改為備份後送修):不確定 SSD 型號或韌體版本、未完成備份、已啟用 BitLocker 但沒有 Recovery Key、公司或學校管控設備且無 IT 授權、SMART 已回報媒體錯誤或壽命耗盡、事件記錄檔已出現 Event 157(掉盤)。

方法一:更新 SSD 韌體(成功率最高、風險可控,先做這個)

消費級 NVMe 的 Event 129,韌體是最值得先排除的一項——因為它免費、原廠有正式管道,而且歷年來確實有多起「特定韌體版本在特定 I/O 模式下控制器停止回應」的案例。

步驟 1:確認你的 SSD 型號與目前韌體版本

開啟 PowerShell(不需管理員),查詢:

Get-PhysicalDisk |
  Select FriendlyName, FirmwareVersion, MediaType, HealthStatus

步驟 2:確認事件確實來自這顆碟

撈出最近的 129 事件,確認來源與數量(一般帳戶即可):

$f = @{LogName='System'; ProviderName='stornvme'; ID=129}
Get-WinEvent -FilterHashtable $f -MaxEvents 50 |
  Format-List TimeCreated, Message

順便把 153 與 157 一起看,做上一節的三兄弟分診:

$g = @{LogName='System'; ID=129,153,157}
Get-WinEvent -FilterHashtable $g -MaxEvents 100 |
  Format-Table TimeCreated, Id, ProviderName -AutoSize

步驟 3:到原廠工具箱更新韌體

依品牌安裝對應工具(Samsung Magician / WD Dashboard / Crucial Storage Executive / Kingston SSD Manager / 各家原廠工具),比對是否有新韌體。只從原廠網站或原廠工具更新,不要用來路不明的第三方韌體包。

步驟 4:順便更新主機板晶片組驅動

NVMe SSD 掛在 PCIe 通道上,晶片組驅動與 BIOS 會影響 PCIe 連結行為。到主機板或筆電原廠網站更新晶片組驅動與 BIOS(BIOS 更新同樣屬於 ⭐⭐⭐,請確認供電穩定)。

更新後觀察 3–7 天,回頭用步驟 2 的指令看 129 是否停止增加。

方法二:關閉 PCIe 連結電源管理(ASPM),並檢查檔案系統

如果韌體已是最新仍在跳 129,下一個嫌疑是 PCIe 電源管理。

機制(業界通用技術背景,非官方對本事件的說明):ASPM(Active State Power Management)是 PCIe 連結層的省電機制——請注意它與 NVMe 規範定義的 APST(裝置端自主電源狀態轉換)分屬不同層級,關閉本節的 ASPM 不會一併關掉 APST。ASPM讓 PCIe 連結在閒置時進入低功耗狀態以省電,而離開低功耗狀態需要一段恢復時間來重新同步收發端。這段恢復時間若因韌體或平台實作問題異常拉長甚至失敗,I/O 就會卡住——正好落進 storport 的逾時窗。這可以解釋為什麼不少人的 129 集中在「閒置一陣子後回來操作」或「睡眠喚醒後」。

⚠️ 來源誠實揭露(請務必讀完再動手):上段機制屬 PCIe 的通用技術背景,站長並未找到微軟官方文件以此機制說明 stornvme Event 129,因此不列入本文第一級來源。更重要的是——微軟官方的 Link state power management 設定頁只定義了這個設定的存在(並標明其為 Hidden setting)與三個值(None / Moderate Power Savings 使用 L0 / Maximum Power Savings 使用 L1),並且明白寫著一句警告:「系統管理員不應變更電源計畫的 personality 設定。」 也就是說,本節的操作方向與微軟該頁的警告是相反的。

站長仍把它放進來,理由只有一個:它完全可逆、零成本,是排除法裡的有效實驗——改了觀察一週,沒改善就改回去,你不會失去任何東西。但你必須知道你在做的是「實驗」,不是「執行官方修復指引」。這是推論,不是官方結論。

操作(可逆、低風險):

1. 開啟「控制台 → 硬體和音效 → 電源選項」
2. 在目前使用的電源計畫按「變更計畫設定 → 變更進階電源設定」
3. 展開「PCI Express → 連結狀態電源管理」
   · 💡 看不到這個項目? 微軟官方該頁標明此設定 Hidden setting: Yes(預設隱藏),部分機器的電源選項不會列出此項;看不到就跳過本方法,不必強改登錄檔去挖它出來。
4. 將「一般電源」(筆電另含「電池」)設為「關閉」
5. 套用後重新開機,觀察 3–7 天。若 129 未減少,請改回原設定(筆電關閉 ASPM 會增加待機耗電)。

檢查檔案系統:如果事件記錄檔同時有 Event 55 或 98,依官方指引先做非破壞性掃描:

chkdsk /scan

確認是否為 dirty 狀態:

fsutil dirty query C:

若確認 dirty,先安排維護時段(修復期間該碟無法存取),再執行:

chkdsk /f /r

⚠️ 官方明講:若 chkdsk 修不好磁碟錯誤,請往檢查清單其餘項目找,但你必須從備份還原資料。這也是為什麼備份要放在最前面。

方法三:調整磁碟逾時值(⭐⭐⭐ 止痛藥,非解藥;官方不建議自行變更)

先講清楚這一段的定位:改逾時值不會修好任何東西,它只是讓 storport 更晚放棄等待,把「凍一下就重設」換成「凍更久但不重設」。 它的正當用途只有一個——在你備份資料的期間,減少裝置被重設而中斷寫入的機率。

微軟官方立場(必讀):

• 2011 年官方文章談到磁碟逾時值 HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue 時明講:部分廠商會調整此值以配合自家硬體,「我們不建議在沒有儲存廠商指引的情況下變更此值」。
• 2026 年最新的官方疑難排解指引,對 Event 129 的處置同樣寫著:「除非你有廠商指引,否則不要變更登錄檔中的磁碟逾時值。」

⚠️ 來源差異說明(誠實揭露):關於「逾時值到底放在哪個機碼」,微軟不同文件的說法並不完全一致,本文如實並陳:

兩者名稱不同(TimeOutValue vs IoTimeoutValue)。站長不會替微軟決定哪個才對——這正是官方要你「先問廠商」的原因。若你真的要動,請以你機器上實際存在的值為準,不要憑文章新建機碼。

操作前必做:先備份該機碼。以管理員身分開啟命令提示字元,匯出備份:

cd /d "%USERPROFILE%\Desktop"
reg export "HKLM\SYSTEM\CurrentControlSet\Services\Disk" disk_backup.reg

查詢目前實際存在的值(兩個都查,看哪個有):

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Disk" /v TimeOutValue

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Disk" /v IoTimeoutValue

只有在原廠明確指示的情況下,才依原廠給的數值修改。本文不提供建議數值——因為給數值就等於替你的 SSD 廠商做決定,而官方明文要你問廠商。

方法四:硬體側排查(前三項無效時)

1. 重插 M.2:關機拔電,取下 M.2 SSD,檢查金手指是否氧化,重新插回鎖緊。接觸不良是被低估的成因。
2. 散熱:確認 M.2 散熱片有裝、導熱貼有貼合;Gen4/Gen5 碟高負載時尤其吃散熱。
3. 換插槽:主機板有第二個 M.2 時,換槽測試,可分辨是碟的問題還是插槽/通道的問題。
4. 查 SMART:用原廠工具看媒體錯誤、剩餘壽命、已用寫入量。若已有媒體錯誤或壽命告罄,停止排查,直接備份換碟。

✅ 驗證修復結果

不要憑「好像不卡了」判斷。用事件數量對照,才算數:

步驟 1:記錄基準線。修復前先數目前的 129 總數:

$f = @{LogName='System'; ProviderName='stornvme'; ID=129}
(Get-WinEvent -FilterHashtable $f -EA SilentlyContinue).Count

步驟 2:記下目前最後一筆的時間(當作觀察起點,不必清空記錄檔):

Get-WinEvent -FilterHashtable $f -MaxEvents 1 | Select TimeCreated

💡 這裡刻意不建議 Clear-EventLog:它會抹掉整份 System 記錄檔(所有來源的事件,不只 129),與本文最後「把事件檢視器當儀表板」的建議互相矛盾;而且該 Cmdlet 已從 PowerShell 7 移除,只在 Windows PowerShell 5.1 可用。記時間點就夠了。

步驟 3:觀察 3–7 天正常使用,期間刻意重現原本會觸發的情境(複製大檔、遊戲讀圖、睡眠喚醒)。

步驟 4:重新統計。用步驟 1 的指令再數一次,並看最近的事件分布:

$g = @{LogName='System'; ID=129,153,157}
Get-WinEvent -FilterHashtable $g -MaxEvents 20 -EA SilentlyContinue |
  Format-Table TimeCreated, Id, ProviderName -AutoSize

判定標準:

• 129 歸零、153 零星或無 → 修復成功。
• 129 減少但仍有 → 部分改善,成因可能不只一項,回頭做方法四。
• 129 沒變或增加,或出現 157 → 停止調整,備份資料並準備換碟或送修。官方對 153 的說法可以借用:偶發逾時或許正常,但頻繁重試代表儲存確實有效能問題、應該修正。

🔙 萬一翻車:回退步驟

• 改了 ASPM 之後更不穩或耗電暴增:電源選項 → 進階設定 → PCI Express → 連結狀態電源管理,改回原本的「中等節省電源」或「最大節省電源」,重新開機。
• 改了登錄檔逾時值之後開不了機或行為異常:
• 進入安全模式(開機時連續中斷開機三次會進入自動修復 → 疑難排解 → 進階選項 → 啟動設定 → 安全模式)。
• 以管理員身分開啟命令提示字元,匯入先前備份: “`console reg import “%USERPROFILE%\Desktop\disk_backup.reg” “`
• 重新開機。
• 韌體更新中斷導致 SSD 無法辨識:不要反覆重試更新。直接聯絡原廠客服走保固——多數 SSD 有 3–5 年保固,韌體更新失敗屬於原廠處理範圍。
• chkdsk /f /r 後檔案遺失:立刻停止對該碟寫入,從備份還原。官方也明講 chkdsk 修不好時必須從備份還原。

💡 總結:預防再次發生

站長我把這篇寫成 cornerstone,是因為 Event 129 是我看過最容易被誤讀的儲存事件,而誤讀的代價通常是「花錢換了一顆沒壞的 SSD,問題照舊」。

最想留給你的判斷原則是這個:事件記錄檔的「來源」欄位,問的是「誰在管這個裝置」,不是「誰把事情搞砸了」。 stornvme 只是 Windows 內建的 NVMe miniport,storport 找不到人負責時就把它的名字寫上去。這個誤讀模式在 Windows 除錯裡到處都是——BSOD 藍屏怪到最後一支載入的驅動、DPC 逾時怪到剛好被抓在現場的模組,都是同一種歸因錯誤。先問「這個訊號從哪一層發出來」,再問「這一層看得到什麼、看不到什麼」,結論會準很多。

KB5063878 事件:官方結論 vs 社群回報

第二件事,是 2025 年 8 月那場 KB5063878 的騷動很值得記著。當時大量使用者(最初集中在日本)回報,在安裝 Windows 11 24H2 該月安全性更新後,對已用量超過 60% 的碟做大量寫入時會出現 SSD 失聯,回報涉及 Corsair Force MP600、Maxio SSD、SanDisk Extreme Pro、Kioxia 等碟款,以及採用 InnoGrit 與 Phison 控制器的多款碟。社群幾乎一面倒認定是更新害的。但微軟在 2025 年 8 月底的官方結論是:「經徹底調查,微軟未發現 2025 年 8 月 Windows 安全性更新,與社群媒體上回報的硬碟故障類型之間有任何關聯」,並表示內部測試與遙測都沒有看到磁碟故障或檔案損毀增加。控制器廠 Phison 當時對外的說法則是「正與微軟合作解決此問題」,並表示可能受影響的控制器仍在檢視中——換句話說,在該報導的時間點,Phison 並未宣告查無關聯(BleepingComputer,2025-08-29,第二級來源;原始出處為微軟服務警示 WI1138854)。

站長我不站隊——官方查無關聯,不等於受災使用者的碟沒事;社群回報很多,也不等於根因就是那支更新。

這件事對日常維運的意義只有一個,而且相當實際:當你的碟已經很滿、又要做大量寫入時,風險本來就比較高。 這與 Event 129 常在大檔複製時集中出現,是同一個物理現實。

三個預防動作

所以預防動作就三個,按重要性排:

1. 留白。別把 SSD 用到 90% 以上。留白同時照顧 GC、SLC 快取與 Over-Provisioning,是成本最低的穩定性投資。
2. 韌體與備份是一組的。更新韌體前先備份;而備份的價值不只在韌體翻車時——Event 129 本身就代表已經有寫入被中止重試過。
3. 把事件檢視器當儀表板,不是急診室。每個月花兩分鐘查一次 129 / 153 / 157,你會在「偶爾卡一下」的階段就發現苗頭,而不是等到碟掉了才回頭找紀錄。

🔬 證據等級聲明:本文為深度 E3——所有機制與官方立場均來自微軟官方文件逐筆標註,站長並未對本主題進行第一手實測,文中不含任何「站長實測」的數字、型號或 build 宣稱。成因表右欄已逐項標示為推論/通用技術背景,該表未附一級來源,不得當作官方成因認定。

❓ 常見問題

Q:stornvme Event 129 SSD 卡死,是不是代表我的 SSD 快壞了?

不一定,而且這是最常見的誤判。Event 129 只證明「storport 在逾時窗內等不到這顆碟回應,於是重設了它」。韌體缺陷、PCIe 電源管理喚醒異常、過熱、接觸不良都會產生一模一樣的事件。判斷碟是否真的在壞,要看 SMART 的媒體錯誤與剩餘壽命,以及是否伴隨 Event 157(surprise removed),而不是看 129 的存在與否。 依本文順序排查:韌體 → ASPM → 硬體側,最後才是換碟。

Q:我可以直接更新或移除 stornvme.sys 這支驅動嗎?

不行,而且沒必要。stornvme.sys 是微軟系統內建(system-supplied)的儲存 miniport 驅動,自 Windows 8.1 起隨系統提供,沒有獨立的下載更新管道,唯一的更新途徑是更新 Windows 本身。裝置管理員裡若看到 SSD 掛在「標準 NVM Express 控制器」下,那就是 stornvme 在管。部分廠商(如 Intel/Samsung)有提供自家 NVMe 驅動可替換,但在 Event 129 尚未確認根因前,換驅動只是換一個報案人,不會讓嫌犯消失。

Q:Event 129 和 Event 153、157 有什麼不同?哪個比較嚴重?

129 是 storport 逾時後重設整顆裝置;153 是 miniport 自己逾時後只中止並重試單一請求,不重設裝置;157 是碟直接從系統消失(surprise removed)。嚴重度由輕到重:153 < 129 < 157。官方明講 miniport 之所以自行計時,正是因為重設整顆碟對 I/O 子系統具破壞性、只為單一請求逾時而重設並不必要。看到 157 請立刻備份,不要繼續排查。

Q:改 TimeOutValue 之後 129 不見了,是不是就修好了?

沒有。這是本文最想強調的觀念之一:加大逾時值只是讓 storport 更晚放棄等待,底層那顆 SSD 該卡還是卡——你只是把「凍一下就重設」換成「凍更久但不留紀錄」,甚至可能讓真正的問題更難被發現。微軟官方在 2011 年與 2026 年的文件裡都明確表示:沒有儲存廠商的指引,不要變更登錄檔中的磁碟逾時值。

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

先確認復發的是不是同一顆碟、同一個事件 ID——用本文「驗證修復結果」的 PowerShell 指令查 129/153/157 的來源與時間分布。若同一顆碟在韌體已更新、ASPM 已關閉的情況下仍反覆跳 129,成因大機率落在硬體側(供電、插槽、散熱、或碟本身衰退):依方法四換插槽測試,並用原廠工具查 SMART。若 SMART 已有媒體錯誤,或開始出現 Event 157,請停止排查,備份後走保固。反覆嘗試軟體側設定,只會拖長資料暴露在風險中的時間。

📎 參考資料來源

📖 第一級|廠商官方:

• Understanding Storage Timeouts and Event 129 Errors — Microsoft Learn(NT Debugging 封存) — 2026-07-14 查證
• Guidance for Troubleshooting Data Corruption and Disk Errors — Microsoft Learn(2026-02-12 更新) — 2026-07-14 查證
• Interpreting Event 153 Errors — Microsoft Learn(NT Debugging 封存) — 2026-07-14 查證
• NVMe features supported by StorNVMe — Microsoft Learn — 2026-07-14 查證
• Registry Entries for StorPort Miniport Drivers — Microsoft Learn — 2026-07-14 查證
• Link state power management(PCI Express 設定)— Microsoft Learn — 2026-07-14 查證(僅用於佐證該設定的存在、三個值與官方警告;該頁未說明 ASPM 與 Event 129 的關係)

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

• Microsoft says recent Windows update didn’t kill your SSD — BleepingComputer(2025-08-29) — 2026-07-14 查證(原始出處:微軟服務警示 WI1138854)

📖 未附一級來源之技術背景(誠實標示):

• 方法二「ASPM 低功耗連結狀態與恢復時間」屬 PCIe 通用技術背景,本文未取得可直接引用之官方頁面說明其與 Event 129 的關聯,故不列為第一級來源,內文已標示為推論。

⚠️ 本文核心事實以第一級為準,第二級為補充。

📅 本文查證戳記:2026-07-14 依據 Microsoft Learn 官方文件撰寫,適用 Windows 10 / Windows 11(含 24H2、25H2)。本文為深度 E3(官方文件交叉查證),非第一手實測。 若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。

📚 延伸閱讀

• SSD 速度詐欺與真實壽命:為何你的 Gen5 神碟複製檔案會卡頓?
• [[避雷選購] 2026 SSD 生存指南:PCIe Gen 5 的發熱地獄與 QLC 的逆襲](https://adersaytech.com/tech-event/2026-ssd-buying-guide-gen5-heat-qlc-reliability.html)
• 藍白當機 (BSOD) 考古學:從 Windows 98 災難現場到 2026 年 WinDbg 核心除錯全攻略