最後更新日期：2026年07月07日
⚡ 站長快讀:核心重點
- 文章屬性:疑難排除(A5 底層除錯)
- 適用系統:Windows 10 / Windows 11(含 24H2、25H2),WDDM 顯示驅動架構通用
- 難易度 / 耗時:⭐⭐(進階選項 ⭐⭐⭐)/ 約 30–60 分鐘
- 核心結論:VIDEO_TDR_FAILURE(0x116)是 Windows 重置顯示卡、想從逾時中恢復卻失敗,八成不是顯卡壞掉,而是驅動、散熱或供電;先揪出兇手驅動,再驗硬體
- 適用對象:畫面凍結、螢幕閃黑後跳 0x116 藍屏,或在可靠性紀錄看到 LiveKernelEvent 141 的人
📌 快速答案
一句話答案:VIDEO_TDR_FAILURE(0x116)代表 Windows 偵測到顯示卡逾時、嘗試重置卻恢復失敗而藍屏,絕大多數不是顯卡報廢,而是顯示卡驅動程式、散熱不足、供電不穩或超頻造成;正確做法是先乾淨重裝驅動,再逐項排除散熱與供電,而不是急著換卡。
🧰 開始前的準備
- 適用系統:Windows 10 與 Windows 11(含 24H2、25H2);只要是 WDDM 顯示驅動都適用
- 權限需求:多數步驟需要系統管理員;調整登錄檔屬高風險,一般使用者可略過
- 需要工具:官方顯示卡驅動(NVIDIA / AMD / Intel 官網)、HWiNFO 或 GPU-Z(監控溫度)、事件檢視器、可靠性監視程式;進階分析用 WinDbg
- 預計耗時:約 30–60 分鐘(乾淨重裝驅動+一輪壓力測試)
⚠️ 本文的「調高 TdrDelay」屬 ⭐⭐⭐ 高風險登錄檔操作,且微軟官方明文表示一般使用者不應更動這些機碼。動手前務必看完「🔙 萬一翻車」的回退步驟,並先備份登錄檔。
🔍 症狀描述與錯誤訊息
先給結論:VIDEO_TDR_FAILURE 有「完全藍屏」與「只閃一下就恢復」兩種面貌,兩者是同一套機制的不同結局,判讀方式也不同。
最典型的情況是:玩遊戲、跑繪圖或看影片到一半,畫面突然凍住幾秒,接著螢幕變黑或閃爍,然後不是跳出藍色當機畫面、就是桌面自己恢復並跳出一則通知。你會看到的訊息通常是以下幾種:
Display driver stopped responding and has recovered.(顯示器驅動程式已停止回應,並且已成功復原)
藍屏畫面:VIDEO_TDR_FAILURE,停止代碼括號內為 0x00000116,有時下方會標出
nvlddmkm.sys(NVIDIA)、atikmdag.sys/amdkmdag.sys(AMD)或igdkmd64.sys(Intel)。事件檢視器 / 可靠性監視程式:LiveKernelEvent,代碼 141,硬體錯誤,並在
C:\Windows\LiveKernelReports產生WATCHDOG開頭的 dump 檔。
這裡要特別澄清一個常見誤會:可靠性監視程式把 141 標成「硬體錯誤」,不代表你的顯卡真的壞了。141 只是「一次沒能完全恢復的顯示卡逾時」留下的即時核心 dump,系統其實沒有整台當掉;它跟 0x116 藍屏是同源事件,只是嚴重程度不同。真正要不要換卡,得看後面的排查結果,而不是被那四個字嚇到。
🔎 問題根因
直接說重點:0x116 的本質是「顯示卡在時限內沒回應,Windows 出手重置它、結果連重置都失敗」,所以系統只能藍屏保命。
Windows 從 Vista 的 WDDM 開始,內建一套叫 TDR(Timeout Detection and Recovery,逾時偵測與恢復) 的看門狗。正常情況下,如果顯示卡忙到一段時間沒回應繪圖排程器的要求,Windows 不會讓你整台鎖死,而是主動把顯示卡驅動「重開機」,讓你看到「顯示器驅動程式已停止回應,並且已成功復原」就沒事了。當這個自動恢復動作本身失敗,或短時間內連續發生太多次,才會升級成 VIDEO_TDR_FAILURE(0x116)藍屏。
根據微軟官方文件,會踩到這個逾時的原因大致分成三類:
- 顯示卡驅動程式:驅動需要更新才能正確支援 TDR 流程;或剛更新的驅動有 bug、安裝殘留衝突。這是實務上最常見的一類。
- 硬體與環境:超頻的元件(顯卡、主機板、記憶體)、記憶體設定與時序不正確、散熱不足、供電不足、零件本身有瑕疵。
- 系統負載:視覺效果或背景程式太多,拖慢顯示卡回應。
換句話說,0x116 是個「症狀」而不是「病名」。它跟 DPC_WATCHDOG_VIOLATION(0x133) 有點像:代碼指向的是「某個東西超時了」,真正的兇手還得往下挖。差別在於 0x133 通常是儲存 / 系統層驅動,0x116 幾乎鎖定在顯示卡這條路上。
🔬 底層機制:這個錯誤訊號從哪裡來?
這一段解釋訊號到底從系統哪一層冒出來,讀者不必懂每個函式,但知道原理後就不會亂槍打鳥。
TDR 的裁判是核心裡的圖形子系統 dxgkrnl(以及 dxgmms 排程模組)。整條流程是這樣:
- 繪圖排程器送出工作給顯示卡後,會等一段時間。TdrDelay(預設 2 秒)是允許顯示卡延遲回應「先讓出」要求的秒數,也就是逾時門檻。
- 系統接著呼叫顯示驅動的
DxgkDdiResetFromTimeout,要求它別再碰硬體、讓正在跑的執行緒收尾。TdrDdiDelay(預設 5 秒)就是「允許執行緒離開驅動」的秒數;超過還沒離開,系統就以 VIDEO_TDR_FAILURE(0x116)當機。 - 另外還有「短時間內太多次」的保險:預設一分鐘內超過 5 次 TDR(對應 TdrLimitCount=5、TdrLimitTime=60 秒),即使每次都恢復成功,也會直接升級藍屏。
看藍屏的四個參數(Bug Check Parameters)就能定位兇手,其中最有價值的是 Arg2:
| 參數 | 官方定義 | 白話 |
|---|---|---|
| Arg1 | 指向內部 TDR 恢復內容(TDR_RECOVERY_CONTEXT)的指標 | 恢復流程的現場資料 |
| Arg2 | 指向「該負責的裝置驅動模組」的指標(owner tag) | 兇手驅動在哪支 |
| Arg3 | 最後一個失敗操作的錯誤碼(NTSTATUS) | 失敗原因代碼 |
| Arg4 | 內部相依的情境資料 | 其他除錯線索 |
用 WinDbg 跑 !analyze -v,輸出的 MODULE_NAME / IMAGE_NAME 通常就會直接標出負責的驅動,例如 nvlddmkm(NVIDIA)。如果你想自己動手讀 dump,可以照 WinDbg 讀 minidump 的三行心法 操作;而 LiveKernelEvent 141 產生的是 C:\Windows\LiveKernelReports\WATCHDOG-*.dmp 這種即時 dump,一樣可以拿去 WinDbg 分析。
🧪 硬體測試基準(Testbed Baseline):⚠️ 待補——本文為官方文件與權威來源交叉整理的深度解析(非站長第一手實測);站長將於取得實機重現環境後,補上顯示卡型號、驅動版本、環溫與監控工具版本等實測基準。文中不含任何杜撰的溫度 / 秒數 / build 實測數字。
🛠️ 解決方案
先講策略:由軟到硬、由高成功率到低。九成的 0x116 在「方法一乾淨重裝驅動」就能收掉,別一開始就拆機或動登錄檔。
⚠️ 進行到方法六(調 TdrDelay)前,請先讀「🔙 萬一翻車」。方法一到五都不會改到系統關鍵設定,可安心嘗試。
方法一:乾淨重裝顯示卡驅動程式(成功率最高)
直接結論:先徹底移除舊驅動、再裝官方最新版,是對付 0x116 CP 值最高的一步。
- 到顯示卡官網(NVIDIA / AMD / Intel)下載對應型號的最新 WHQL 驅動,先放桌面。
- 進安全模式(設定 → 系統 → 復原 → 進階啟動),用社群常用的乾淨移除工具把舊驅動連殘留一起清掉,避免新舊衝突。
- 回正常模式,安裝剛下載的官方驅動,重開機。
💡 反向操作也要試:如果藍屏是某次驅動更新後才開始,那多半是新驅動的 bug,請改「回滾」到前一版穩定驅動(裝置管理員 → 顯示卡 → 內容 → 驅動程式 → 回復驅動程式),或到官網抓舊版。新不一定好。
方法二:壓下散熱與供電問題
結論:驅動換乾淨還是跳,就往「熱」跟「電」查。
- 散熱:清機殼與顯卡積灰、確認風扇正常轉、機殼風道順暢。用 HWiNFO / GPU-Z 觀察顯示卡在高負載時的溫度是否異常偏高、是否一到某溫度就崩。
- 供電:確認電源供應器瓦數足夠帶動這張卡;PCIe 電源線每一條獨立拉、避免一條分接兩個接頭(daisy-chain);把顯卡與電源線重新插緊。老化或瓦數不足的電源,常是「重負載才崩、待機正常」的隱形兇手。
方法三:把超頻與記憶體超頻退回預設
結論:任何超頻都可能讓顯示卡在邊界上逾時。
- 顯卡若用 MSI Afterburner 等工具超頻 / 調電壓,先全部重設回預設。
- 進 BIOS 把記憶體的 XMP / EXPO 關掉、載入預設值試跑。記憶體設定與時序不正確,是官方明列的 0x116 成因之一。
- 順手跑一次 Windows 記憶體診斷(控制台搜尋「記憶體」→ 診斷電腦的記憶體問題),結果在事件檢視器系統紀錄的
MemoryDiagnostics-Results查看。
方法四:排除背景軟體衝突
結論:某些監控 / 燈效軟體會跟顯示卡驅動打架。
有使用者回報,RGB 燈效與硬體監控類程式(例如各家主機板廠的燈效中心、OpenRGB、部分監控工具)偶爾會與顯示卡驅動衝突,誘發 141 / 0x116。做法是乾淨開機(msconfig → 服務隱藏微軟項目後全部停用、啟動項全關)後觀察是否還崩,再逐一開回去找出兇手。此為社群案例,非官方定論,但排查成本低、值得一試。
方法五:用 WinDbg 或 Driver Verifier 揪出真兇驅動
結論:反覆發作、又找不到頭緒,就讓工具直接點名。
- WinDbg:載入 minidump 或
LiveKernelReports\WATCHDOG-*.dmp,跑!analyze -v看MODULE_NAME,再用lmvm <驅動名>看那支驅動的版本 / 時間戳,確認是不是舊版或第三方驅動。 - Driver Verifier:懷疑是某支驅動但抓不到現行犯時,可用 Driver Verifier 完整教學 施壓,讓有問題的驅動在第一時間現形。注意 Driver Verifier 會刻意讓問題驅動觸發藍屏,務必先設好還原點與安全模式退路。
方法六(最後手段,⭐⭐⭐,官方不建議一般使用者):調高 TdrDelay
先把話講清楚:這不是「修好」,而是「把逾時門檻拉長、讓它比較不容易觸發」的權宜之計。微軟官方文件明白寫著:一般使用者與應用程式不應更動這些 TDR 機碼,它們是給驅動開發者測試用的。 如果你的顯卡本來就在邊界掙扎,拉長 TdrDelay 只是延後崩潰,治標不治本。看得懂上面這段、且願意自負風險再往下做。
登錄檔位置:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers,新增 REG_DWORD 值 TdrDelay(預設 2 秒)。以下 PowerShell 已內建管理員檢查與操作前備份,請以系統管理員身分執行:
# ============================================================
# 安全前綴:管理員權限檢查 + 操作前備份(⭐⭐⭐ 登錄檔變更)
# ============================================================
# 檢查是否以管理員身份執行
$IsAdmin = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
if (-not $IsAdmin) {
Write-Warning "Task aborted: Please re-run this script as Administrator."
Exit 1
}
# 建立備份目錄與時間戳記
$BackupDir = "C:\Users\Public\Documents\TedTechBackup"
if (-not (Test-Path $BackupDir)) { New-Item -ItemType Directory -Path $BackupDir | Out-Null }
$Timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
# 匯出登錄檔備份(reg.exe 用 HKLM\ 而非 HKLM:\)
$RegPath = "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers"
$BackupFile = Join-Path $BackupDir "GraphicsDrivers_Backup_$Timestamp.reg"
& reg.exe export "$RegPath" "$BackupFile" /y | Out-Null
if ($LASTEXITCODE -ne 0) { Write-Warning "Backup failed. Aborting."; Exit 1 }
Write-Output "Backup saved: $BackupFile"
Write-Output "To restore: reg import `"$BackupFile`""
# ============================================================
# 主要操作:把 TdrDelay 設為 8 秒(權宜,非修復)
# ============================================================
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" `
-Name "TdrDelay" -PropertyType DWord -Value 8 -Force | Out-Null
Write-Output "TdrDelay 已設為 8;請重新開機後生效。若之後想還原,刪除該值或匯入上面的備份檔。"設定後必須重新開機才生效。若問題消失,也請把它當成「爭取時間換驅動 / 修硬體」的臨時手段,而不是終點。
✅ 驗證修復結果
結論:別只看「暫時沒當」,要主動壓力測試+回頭看紀錄,才算真的解決。
- 可靠性監視程式(控制台搜尋「可靠性」):處理後觀察數日,確認沒有再新增 LiveKernelEvent 141 或 0x116 紀錄。
- 事件檢視器 → Windows 記錄 → 系統:過濾
Display來源的「顯示器驅動程式停止回應並已復原」事件是否停止出現。 - 壓力測試:用你原本會觸發當機的情境(某款遊戲、繪圖軟體)實際跑一段時間;跑 GPU 壓力測試時全程用 HWiNFO 盯著溫度,一異常就停,別為了測試把卡烤壞。
三項都過,才把它列為「已解決」。
🔙 萬一翻車:回退步驟
(方法六調登錄檔屬 ⭐⭐⭐,以下務必先讀)
情境一:改了 TdrDelay 後更不穩或想還原
- 系統可正常進入:用系統管理員開 PowerShell,執行
reg import "C:\Users\Public\Documents\TedTechBackup\GraphicsDrivers_Backup_<你的時間戳>.reg"匯回備份;或直接刪除剛剛新增的TdrDelay值(還原成預設 2 秒行為),重開機。
情境二:乾淨重裝驅動後黑畫面 / 無訊號
- 重開進安全模式(開機時中斷兩三次觸發 WinRE → 疑難排解 → 進階選項 → 啟動設定 → 重新啟動 → 選 4/5/6)。安全模式只載入最基本驅動,可在此重裝或回滾顯示卡驅動。
情境三:系統完全無法開機(最壞情況)
- 用另一台電腦製作 Windows 安裝 / 修復 USB,開機進 WinRE,以「系統還原」回到操作前的還原點,或用「啟動修復」。這也是為什麼方法五、六前一定要先設好還原點。
💡 總結:預防再次發生
站長我看 0x116 這類逾時藍屏,最想提醒的一句是:它十之八九在罵驅動或環境,不是在宣判顯卡死刑。 太多人一看到「硬體錯誤 LiveKernelEvent 141」就下單買新卡,結果乾淨重裝一次驅動、把 daisy-chain 的 PCIe 電源線分開拉,問題就沒了——白花的錢很冤枉。
從產業經驗看,顯示卡逾時最愛在三個時間點冒出來:剛升級驅動後(新驅動 bug)、機器用了兩三年灰塵塞滿散熱後(熱)、以及換了大電量新卡卻沒同步升級電源後(電)。預防的三個核心動作也對應這三點:驅動只裝官方 WHQL 並保留一版可回滾、每半年清一次散熱、換卡時一併確認電源瓦數與獨立供電線。
至於 TdrDelay,站長的立場跟微軟一致:那是開發者的測試旋鈕,不是使用者的修復鍵。把門檻拉長只會讓一張快不行的卡「撐久一點」,反而掩蓋了該處理的散熱或供電問題。真要動,務必當成臨時手段,並留好回退路。
🧪 實測基準:⚠️ 待補——本文結論以微軟官方文件與權威來源交叉查證為主(深度 E3,非第一手實測);後續若站長取得可穩定重現 0x116 的實機,將補上完整硬體測試基準與量測數據。
❓ 常見問題
Q:VIDEO_TDR_FAILURE 一定是顯卡壞了要換嗎?
不是。它是「顯示卡逾時、系統重置失敗」的訊號,官方列出的主因是驅動、散熱、供電與超頻,顯卡本身故障只是其中一種可能。請先做完方法一到四,真的都排除了、又抓到硬體層錯誤,再考慮送修或換卡。
Q:LiveKernelEvent 141 和 0x116 藍屏有什麼不同?
兩者同源。141 是「顯示卡逾時但系統靠 TDR 救回來了」,只留下即時 dump、沒整台當掉;0x116 是「連救援都失敗」升級成藍屏。看到 141 就代表你的卡已經在逾時邊緣,建議照本文排查,別等它變成藍屏。
Q:調高 TdrDelay 到底能不能用?
能讓它「比較不容易觸發」,但微軟官方明講一般使用者不該動這些機碼。它治標不治本,只適合當成換驅動 / 修硬體前的臨時緩衝,且務必先備份登錄檔、留好回退步驟。
Q:更新到最新驅動反而更常藍屏怎麼辦?
那多半是新版驅動的 bug。請回滾到前一版穩定驅動(裝置管理員 → 回復驅動程式),或到官網抓舊版 WHQL。遇到這種情形,「不更新」反而是對的。
🔗 延伸閱讀
- IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇
- BSOD 藍屏是什麼？教你如何一步步解決與預防 (2025 最新指南)
- 0x139 KERNEL_SECURITY_CHECK_FAILURE BSOD 修復|WinDbg 抓真兇 driver
- DPC_WATCHDOG_VIOLATION 完整除錯 2026 | WinDbg 三步揪出真兇
- Windows 開不了機/狂當機？進入「安全模式」(Safe Mode) 診斷問題教學 (Win10/11 適用 2025)
📎 參考資料來源
📖 第一級|廠商官方:
- Bug Check 0x116 VIDEO_TDR_FAILURE — Microsoft Learn — 2026-07-03 查證(頁面 2024-08-24 更新)
- Testing and debugging TDR / TDR registry keys — Microsoft Learn — 2026-07-03 查證(頁面 2025-11-07 更新)
- Timeout Detection and Recovery (TDR) — Microsoft Learn — 2026-07-03 查證
📖 第二級|權威技術媒體 / 社群案例(標為案例,非官方定論):
- Hardware error – LiveKernelEvent – Code 141 — Tom’s Hardware Forum — 社群案例,2026-07-03 查證
- LiveKernelEvent 141 — NVIDIA GeForce Forums — 社群案例,2026-07-03 查證
⚠️ 本文核心事實(0x116 定義、四個參數、TDR 機制與登錄檔預設值)以第一級微軟官方為準;LiveKernelEvent 141 的成因與軟體衝突屬第三方 / 社群回報,已於文中標示。
📅 本文查證戳記:2026-07-03 依微軟官方 TDR 文件與權威來源交叉整理撰寫(深度 E3,非第一手實測)。
若你在後續版本或特定顯卡上遇到步驟失效,歡迎在留言區回報,站長會更新文章。