Explorer.exe 當機排查|檔案總管閃退重啟怎麼修

文章屬性:疑難排除
適用系統:Windows 11 24H2 / 25H2 / 26H1、Windows 10 22H2
難易度 / 耗時:★★☆(第三步含 ⭐⭐⭐ 高風險操作)/ 約 30–60 分鐘
核心結論:Explorer.exe 當機多數情況不是「Windows 壞掉」,而是某個載入到檔案總管處理程序裡的第三方模組出錯;先從事件記錄抓出 Faulting module,再對症處理
適用對象:桌面圖示會消失再重畫、工作列閃一下不見、按右鍵就沒回應、開特定資料夾必當的人

📌 快速答案

一句話答案:修 Explorer.exe 當機照四步走——先重啟檔案總管並裝完更新,再讀事件檢視器抓出 Faulting module 名稱,接著用 Autoruns 隔離第三方擴充,最後開啟獨立處理程序設定。

🧰 開始前的準備

適用系統:Windows 11 24H2(build 26100)、25H2(build 26200)、26H1(build 28000);Windows 10 22H2 大部分步驟同樣適用
權限需求:多數步驟需要系統管理員權限
需要工具:
事件檢視器(eventvwr.msc,系統內建)
可靠性監視器(perfmon /rel,系統內建)
Autoruns for Windows(Microsoft Sysinternals) — 檢視與停用殼層擴充
預計耗時:約 30–60 分鐘,含重新開機時間
先做的事:建立一個系統還原點,或至少確認重要資料已備份。本文第三步會停用第三方元件並修改其註冊狀態,有還原點才有回頭路。

🔍 症狀描述與錯誤訊息

Explorer.exe 當機的表現方式比多數人想的更多樣,而且很多人根本沒意識到自己遇到的是同一件事。最典型的是「畫面閃一下」:桌面圖示整批消失、工作列跟著不見,短暫消失後自動重繪回來——這其實就是殼層處理程序崩潰後被系統重新啟動的完整週期。其次是操作觸發型:對某個檔案按滑鼠右鍵、切到有縮圖的圖片資料夾、開啟預覽窗格、或是把滑鼠移到某類檔案上,檔案總管視窗立刻關閉。第三種比較嚴重,是登入之後停在黑畫面或只有桌布,工作列與「開始」功能表都叫不出來,連 Ctrl + Shift + Esc 開工作管理員都要試好幾次。

常見的可見錯誤訊息包括:

「檔案總管沒有回應」/「Windows 檔案總管已停止運作」(後者為舊版 Windows 常見的對話框字串,新版多為殼層靜默重啟、不跳視窗)
事件檢視器「應用程式」記錄中:來源 Application Error、事件識別碼 1000,內容含 Faulting application name: explorer.exe 與 Faulting module name: <某個 DLL>

要特別分清楚兩件事:閃退(crash)與沒有回應(hang)是不同故障。閃退會在事件記錄留下 Event ID 1000 的當機紀錄;而長時間轉圈但最後又活過來的「沒有回應」,通常是掛在某個等待中的 I/O 上,例如連不上的網路磁碟機或還在同步的雲端資料夾,事件記錄裡不一定有對應的當機事件(若想再往下追是哪個 I/O 卡住,可參考站上的 WinDbg 進階指令教學:用 !process、!irp、!thread 追出卡死的驅動程式與 I/O 請求)。本文的排查主線針對前者,但第四步的兩個設定對後者同樣有效。

🔎 問題根因

檔案總管之所以特別容易被外部程式弄垮,原因藏在它的設計裡:explorer.exe 不只是一個檔案瀏覽器,它同時是整個 Windows 桌面殼層的宿主。桌面圖示、工作列、「開始」功能表、通知區域、右鍵選單、縮圖與預覽,全部由這一個處理程序負責繪製與回應。而為了讓第三方軟體能把功能整合進來(壓縮軟體的右鍵選單、雲端硬碟的同步狀態圖示疊加、影片播放器的縮圖產生器),Windows 提供了殼層擴充(Shell Extension)機制。

問題就在這個機制的實作方式。依 Microsoft 官方 Win32 開發文件,殼層擴充處理常式是 in-process 的 COM 物件,並以 DLL 形式實作(Initializing Shell Extension Handlers:「All Shell extension handlers are in-process Component Object Model (COM) objects.」「They are implemented as DLLs…」);官方另一份實作指引也載明,in-process 擴充會被載入到任何觸發它的處理程序中(Guidance for Implementing In-Process Extensions:「In-process extensions are loaded into any processes that trigger them.」)。換句話說,那顆第三方 DLL 和檔案總管共用同一塊記憶體位址空間與同一組執行緒——它踩到無效指標,倒下的是整個殼層,而不是只有它自己。

由此可以把根因收斂成五類,實務上出現頻率大致由高到低:

第三方殼層擴充出錯:右鍵選單處理常式、縮圖處理常式、預覽處理常式、圖示疊加處理常式。多半來自壓縮軟體、雲端同步工具、防毒軟體、影音轉檔工具、舊版驅動附帶的工具程式。
系統檔或元件存放區損壞:更新中斷、磁碟壞軌、非正常關機之後,殼層依賴的系統 DLL 本身就已經不完整。
快取資料損壞:縮圖快取或圖示快取寫壞,一開到含該類檔案的資料夾就重現。
外部資源等待逾時:離線的網路磁碟機、拔掉的外接碟仍留在「快速存取」、雲端資料夾正在大量同步。
系統更新的已知問題:特定版本組合下的殼層元件缺陷,這一類要靠官方修補,自己怎麼修都是白工。

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

要理解為什麼「抄下 Faulting module name」是整套排查的核心,得先知道那行字是怎麼產生的。

當 explorer.exe 內部發生未處理的例外(常見的是存取違規,錯誤碼 0xc0000005;官方把它與 0xc0000022、0xc0000374 並列為常見例外),Windows 錯誤報告會接手這個處理程序的當機。它會取得當機當下的例外位址,反查該位址落在哪一個已載入模組的位址範圍內,然後把該模組的檔名、版本與模組內位移一起寫進「應用程式」事件記錄的 Event ID 1000。Microsoft 官方應用程式當機行為疑難排解文件即載明,Event ID 1000 會記下 Faulting module name、版本、Fault offset 與 Exception code 這幾個欄位(位址反查落在哪個模組的說明,為站長依上述欄位所做的機制解讀)。所以 Faulting module 指的不是「誰呼叫了它」,而是「當機那一刻,指令指標正好停在誰的程式碼裡」——對於 in-process 載入的殼層擴充來說,這兩者絕大多數時候就是同一個。

這也解釋了幾個常見的判讀陷阱:

看到 ntdll.dll、KERNELBASE.dll、combase.dll 不代表是系統壞掉。這幾顆是所有程式共用的底層執行時期程式庫,第三方模組傳了非法參數進去、真正爆開的位置在系統 DLL 裡,是很典型的情況。這種時候要往下看事件詳細資料裡的例外位移,或改用下一段的隔離法反推。
看到 SHELL32.dll、windows.storage.dll 也一樣。殼層自己的模組被外掛餵了壞資料而倒下,和殼層自己有 bug,在事件記錄上長得一模一樣。
看到明確的第三方檔名就是中獎。例如某壓縮軟體的 xxxShlExt.dll、某同步工具的 xxxOverlay.dll,這種直接對應到某套軟體,處理起來最快。

可靠性監視器(perfmon /rel)是同一批資料的另一種呈現方式,它把當機事件畫成時間軸,好處是能一眼看出「問題是從哪一天開始的」。把那一天對照回自己灌了什麼軟體或裝了哪一版更新,往往比逐條翻事件記錄還快。

Explorer.exe 當機四步排查順序流程圖:讀事件記錄、修系統檔或隔離第三方擴充、降低耦合

🛠️ 解決方案

⭐⭐⭐ 高風險操作警語(適用本節方法三)
方法三會停用第三方元件並改變其在系統中的註冊狀態,屬於可回復但會影響其他軟體功能的操作。動手前務必先建立系統還原點(設定 → 系統 → 系統保護 → 建立),並確認重要資料已另外備份;操作全程請保持電源供應穩定,不要中途強制關機。
停止條件清單(符合任一項,請不要繼續往下做,改找專業協助或原廠支援):
– 不確定自己的 Windows 版本或裝置型號
– 尚未完成資料備份、也沒有可用的系統還原點
– 已啟用 BitLocker 但手邊沒有復原金鑰
– 這是公司或學校管控的設備,且未取得 IT 部門授權
– 指令或工具的輸出畫面與本文描述明顯不符

方法一:先做完最低成本的三件事

在動任何刀之前,把成功率最高、風險最低的處置做完。這三步在多數案例會直接解決問題,即使沒解決,也能把後面的排查範圍縮小一大半。

① 重新啟動 Windows 檔案總管。按 Ctrl + Shift + Esc 開啟工作管理員,在「處理程序」中找到「Windows 檔案總管」,按右鍵選「重新啟動」。這一步不修任何東西,但它會強制殼層重新載入所有擴充,如果症狀在重啟後暫時消失、過一陣子又回來,基本上就能確定是某個會被延遲載入的擴充在作怪。

② 安裝所有可用的 Windows 更新並重新開機。Microsoft 官方的〈Fix File Explorer if it won’t open or start〉支援文件把「檢查更新」列為第一步,原因很實際:檔案總管的多數缺陷是靠累積更新修的,而且同一個症狀很可能官方早就修好了。以近期的更新為例,2026 年 7 月 28 日釋出的 KB5101681(OS build 28000.2608 預覽版,僅適用 Windows 11 26H1)就明確載明改善 explorer.exe 的可靠性,包含在虛擬桌面之間切換時的 explorer.exe 可靠性、搭配殼層擴充啟動應用程式的行為,以及 OneDrive 同步期間切換到「常用」的操作。撰稿當下的最新安全性更新是 2026 年 8 月 11 日的 KB5121003(24H2 / 25H2,builds 26100.9168 與 26200.9168)與 KB5121000(26H1,build 28000.2704)。

③ 拔掉不必要的外接裝置、清掉離線的網路磁碟機。已經連不上的對應磁碟機、拔掉但仍留在「快速存取」的隨身碟,都會讓檔案總管在列舉時卡在逾時等待。要注意的是,裝置拔掉之後,它的路徑仍可能殘留在「快速存取」的常用資料夾與最近使用的檔案清單裡,檔案總管在載入這些清單時可能會再去嘗試存取那個已經不存在的位置(官方文件未就此情境逐條敘明,此處為依 Explorer 行為所做的說明)——所以清完裝置,順手把這些殘留項目也清掉。「快速存取」的清理與還原方式,見 Windows 11 檔案總管推薦項目很煩?三招找回快速存取。這一步對「沒有回應」型症狀特別有效。

方法二:讀事件記錄,鎖定 Faulting module

這是整套排查真正的分水嶺——在知道是哪顆模組出事之前,所有動作都是亂槍打鳥。

按 Windows 鍵 + R,輸入 eventvwr.msc 後按 Enter。
依序展開「Windows 記錄」→「應用程式」。
點右側「篩選目前的記錄檔」,在「事件識別碼」欄位輸入 1000。
在篩選結果中找出「來源」為 Application Error、且一般資訊裡出現 explorer.exe 的項目,點開看「一般」分頁。
抄下兩個欄位:Faulting module name(出錯模組檔名)與 Exception code(例外碼)。

拿到模組名之後,依上一節的判讀原則分流:

模組名稱樣態	判讀	下一步
明確第三方檔名	該軟體的殼層擴充出錯	更新或移除該軟體,或直接跳方法三停用它
系統 DLL(ntdll / KERNELBASE 等)	無法直接歸責,需隔離	先修系統檔,再走方法三二分法
顯示卡相關模組	繪圖層問題	到顯示卡官網裝最新驅動,或改用官方 WHQL 版

如果模組名指向系統 DLL,先把系統檔修一輪。依序在系統管理員身分的終端機執行下列兩道指令(先跑 DISM 再跑 SFC,官方 KB929833 亦明列應先執行 DISM 再執行系統檔案檢查程式,因為 SFC 要靠元件存放區當修復來源,存放區本身壞了會修不動):

DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow

兩道跑完重新開機再觀察。這兩個指令只修復系統檔、不動使用者資料,是本文中風險最低的修復動作,但仍建議在有還原點的前提下執行。

方法三:隔離第三方殼層擴充(⭐⭐⭐)

如果模組名不明確,或修完系統檔仍會當,就要用隔離法反推。這一步請先確認上方的警語與停止條件都已滿足。

用 Autoruns 做二分法:

從 Microsoft Sysinternals 官方頁面下載 Autoruns for Windows,解壓縮後以系統管理員身分執行其中的 Autoruns 主程式(64 位元系統通常為 Autoruns64.exe,實際檔名依下載包版本而定)。
在「Options」選單中開啟隱藏微軟簽署項目的過濾選項(官方頁稱為 Hide Signed Microsoft Entries,實際選單字樣依 Autoruns 版本略有差異),按 F5 重新整理。這一步會把微軟自家的項目濾掉,留下來的就是第三方元件。
切到「Explorer」分頁,這裡列出的就是整合進檔案總管的第三方殼層擴充。
先把清單完整截圖或用「File → Save」匯出存檔——這是等一下要還原時的依據,不要跳過。
把這個分頁裡的項目全部取消勾選,關閉 Autoruns,再用方法一的方式重新啟動 Windows 檔案總管(必要時重新開機)。
觀察症狀是否消失。若消失,代表兇手確實在這份清單裡;接著每次勾回一半,重新啟動檔案總管後測試,用二分法把範圍縮到單一項目。若全部停用後症狀依舊,問題不在殼層擴充,把勾選全部復原,改走下一段。

用乾淨開機縮小範圍:Autoruns 的 Explorer 分頁只涵蓋殼層擴充,若問題來自背景服務或啟動項,要改用官方的乾淨開機流程。依 Microsoft 官方〈How to perform a clean boot in Windows〉:在搜尋列輸入 msconfig 開啟「系統設定」,在「服務」分頁勾選「隱藏所有 Microsoft 服務」後按「全部停用」,再到「啟動」分頁開啟工作管理員把已啟用的項目逐一停用,然後重新開機測試。排查完務必依同一份官方文件把設定改回「一般啟動」,否則系統會長期停在選擇性啟動狀態。

方法四:降低耦合與清掉壞快取

前面三步是找兇手,這一步是讓檔案總管本身變得比較耐撞,適合當作長期設定保留。

① 開啟「在個別的處理程序中開啟資料夾視窗」。開啟檔案總管 → 右上「⋯」→「選項」→「檢視」分頁,勾選「在個別的處理程序中開啟資料夾視窗」後套用並重新開機。這個選項會讓資料夾視窗跑在獨立的處理程序中,單一視窗當掉時不會把整個桌面殼層一起拖下水。代價是記憶體用量略增。(對應的登錄檔值為 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced 底下的 SeparateProcess,此為第二級來源整理,一般情況用上述圖形介面設定即可,不需要動登錄檔。)

② 清除縮圖快取。在搜尋列開啟「磁碟清理」,選擇系統磁碟,勾選「縮圖」後確定。若症狀只在含大量圖片或影片的資料夾重現,這一步通常立刻見效;縮圖快取與 Thumbs.db 的關係,可延伸看 Thumbs.db 與 desktop.ini 是什麼?為什麼刪掉後又會自己出現?。

③ 關閉預覽窗格與詳細資料窗格。在檔案總管的「檢視」選單中關掉這兩個窗格。預覽窗格會呼叫預覽處理常式去解析檔案內容,那也是一種 in-process 擴充,關掉等於少一條當機路徑。

④ 企業與虛擬桌面環境的特例。如果這台是公司管控的電腦或 VDI 虛擬桌面,而症狀是「登入後黑畫面、開始功能表打不開、工作列不出現」,要先看 Microsoft 的 KB5072911。官方說明指出:以 2025 年 7 月(含)之後釋出的 24H2 / 25H2 累積更新完成佈建的電腦,可能因為 XAML 相依套件未能及時註冊,導致 Explorer、開始功能表、SystemSettings、工作列與 Windows 搜尋等元件無法啟動;官方同時載明這個問題主要出現在少數企業或受管理環境,在個人裝置上極不可能發生。官方的解法是安裝 2026 年 6 月 23 日(含)之後釋出的更新(KB5095093),暫時性的手動註冊指令與非持續性環境的登入指令碼範例,請直接依 KB5072911 原文操作,不建議在個人電腦上照抄。

✅ 驗證修復結果

症狀「暫時沒出現」和「真的修好了」是兩件事。用下面三個條件確認:

重現原本必當的操作。原本按右鍵就當、開某個資料夾就當,就回去做同一件事至少三次。做不出來才算數。
回頭看事件記錄。重新開啟事件檢視器,確認自修復時間點之後沒有新的 Event ID 1000 且應用程式名稱為 explorer.exe 的紀錄。這一條比肉眼觀察可靠,因為有些崩潰重啟快到使用者不會察覺。
看可靠性監視器的曲線。執行 perfmon /rel,確認最近幾天的當機標記停止累積。連續兩到三天沒有新的殼層當機紀錄,才算穩定。

如果是用方法三的二分法找到單一元凶,別忘了最後一步:把其他被停用的項目全部勾回去,只留下真正有問題的那一個保持停用,然後到該軟體官網看有沒有新版可以更新。長期停用會讓那套軟體的功能不完整。

🔙 萬一翻車:回退步驟

情境一:停用殼層擴充後,某些軟體功能不見了

打開 Autoruns,切到「Explorer」分頁,依照方法三第 4 步存下的截圖或匯出檔把項目勾回去,重新啟動檔案總管即可。Autoruns 的取消勾選是可逆操作,不會刪除檔案。

情境二:乾淨開機之後系統行為異常或某些服務起不來

再次執行 msconfig,在「一般」分頁選「一般啟動」;到「服務」分頁取消勾選「隱藏所有 Microsoft 服務」後按「全部啟用」,套用並重新開機。這是官方文件明列的還原程序。

情境三:改完設定後情況更糟,或桌面完全叫不出來

按 Ctrl + Shift + Esc 開啟工作管理員 →「執行新工作」→ 輸入 rstrui 並勾選以系統管理員權限執行,回到操作前建立的系統還原點。這就是文章開頭要求先建立還原點的原因。若連工作管理員都開不了,重開機時從復原環境進入「疑難排解 → 進階選項 → 系統還原」。

情境四:所有方法都無效

在確認資料已備份的前提下,考慮建立一個新的本機使用者帳戶測試。若新帳戶完全正常,問題出在原帳戶的使用者設定檔而非系統本身;若新帳戶一樣會當,依 Microsoft 官方支援文件的建議,最後手段是重設此電腦。

💡 總結:預防再次發生

處理這類案子,站長我的順序永遠是「先讀記錄再動手」,而不是先跑 SFC。原因不是 SFC 沒用,而是檔案總管當機的第一嫌疑犯通常不是 Windows 自己——它是被別人載進自己家裡的客人弄垮的。跳過事件記錄直接修系統檔,運氣好會遇到剛好是系統檔損壞的那一類,運氣不好就是花四十分鐘換來一句「Windows 資源保護未發現任何完整性違規」,然後回到原點。這條路我看過太多人走,也看過太多人在論壇上被建議走。

從這個角度回頭看,預防的重點其實只有三件事:

第一,對「會裝右鍵選單的軟體」保持警覺。壓縮工具、雲端同步、下載器、影音轉檔、系統最佳化工具——這幾類軟體幾乎必定會裝殼層擴充。裝之前想一下自己是不是真的需要它常駐,而不是只是偶爾用一次。真的只偶爾用,選免安裝版本就少一條當機路徑。

第二,把「在個別的處理程序中開啟資料夾視窗」當成預設設定。它換來的隔離性,遠比多出來的那點記憶體用量值錢。

第三,更新照裝,但保留觀察期。從 KB5072911 到 KB5101681 可以看出來,殼層元件的缺陷確實會由官方更新引入,也確實由官方更新修好;個人裝置放著自動更新是對的,但如果是拿來工作的主力機,遇到大版本更新後出現的新症狀,先去 Windows release health 頁面看有沒有已知問題再自己動手,常常可以省下一整個下午。

最後提醒一句:本文所有事實與指令均取自官方文件與撰稿當下的查證結果,不含站長第一手實測數據;不同機器的軟體組合差異很大,請以自己機器上事件記錄的實際內容為準。

❓ 常見問題

Q:檔案總管當機會不會弄壞我的檔案?

單純的殼層當機不會直接損壞已經存在的檔案,因為它崩潰的是負責顯示的處理程序,不是檔案系統(此段為依作業系統行為所做的說明,官方文件未就此情境逐條敘明)。但如果當機發生在複製、搬移或重新命名的當下,那筆正在進行的操作可能只完成一半,產生殘留的暫存檔或不完整的複本。所以遇到反覆當機時,先暫停大量的檔案搬移作業再排查。

Q:Faulting module 顯示的是 ntdll.dll,是不是系統壞了要重灌?

多數情況不是。ntdll.dll 是所有 Windows 程式共用的底層執行時期程式庫,第三方模組傳入非法參數、實際爆開的位置落在它裡面,是非常常見的樣態。正確做法是先跑 DISM 與 SFC 排除系統檔損壞,再用方法三的隔離法反推真正的來源,不需要一看到系統 DLL 就重灌。

Q:我是公司電腦,可以照這篇做嗎?

方法一與方法二(讀事件記錄)沒有問題。方法三會停用第三方元件、乾淨開機會改變啟動設定,在受管控的設備上請先取得 IT 部門授權——這也列在本文的停止條件清單裡。另外,如果症狀是登入後黑畫面,請直接把 KB5072911 這份文件轉給 IT 部門,那是給系統管理員看的。

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

先確認復發的時間點:如果是在裝了新軟體或跑完某次 Windows 更新之後,大機率是新引入的元件或已知問題,回頭比對事件記錄裡新出現的 Faulting module。如果復發時模組名和上次一樣,代表上次只是暫時壓下去(例如軟體更新後又把擴充裝回來),這時要考慮直接移除該軟體或改用替代品。如果模組名每次都不同,反而要往硬體方向想——記憶體或磁碟不穩定會讓當機位置隨機分布。

📎 參考資料來源

📖 第一級|廠商官方:

Fix File Explorer if it won’t open or start — Microsoft Support — 2026-08-17 查證
Guidance for Implementing In-Process Extensions — Microsoft Learn — 2026-08-17 查證
Initializing Shell Extension Handlers — Microsoft Learn — 2026-08-17 查證
Troubleshoot application or service crashing behavior — Microsoft Learn — 2026-08-17 查證
KB929833:使用系統檔案檢查程式修復遺失或損毀的系統檔案 — Microsoft Support — 2026-08-17 查證(DISM 應先於 SFC 執行)
KB5072911:Explorer、開始功能表與其他 XAML 相依應用程式可能無法啟動 — Microsoft Support — 2026-08-17 查證
July 28, 2026—KB5101681(OS Build 28000.2608)Preview — Microsoft Support — 2026-08-17 查證
August 11, 2026—KB5121003(OS Builds 26200.9168 and 26100.9168)— Microsoft Support — 2026-08-17 查證
How to perform a clean boot in Windows — Microsoft Support — 2026-08-17 查證
Autoruns for Windows — Microsoft Sysinternals — 2026-08-17 查證

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

Explorer.exe Crash Troubleshooting Tips — Winhelponline — 2026-08-17 查證(第三方殼層擴充為反覆當機常見成因、二分法隔離實務)
Enable or Disable Launch Folder Windows in a Separate Process — Eleven Forum — 2026-08-17 查證(SeparateProcess 登錄檔值位置)

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

📅 本文查證戳記:2026-08-17 依 Windows 11 24H2 / 25H2 / 26H1 官方文件撰寫,不含第一手實測數據。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。