WMI Repository 修復完整教學|驗證、併修與重建順序

⚡ 站長快讀:核心重點

文章屬性:疑難排除
適用系統:Windows 11 / 10、Windows Server 2008 以上
難易度 / 耗時:⭐⭐⭐ / 約 30–60 分鐘(站長估算,官方未給時間基準)
核心結論:三段處置破壞性遞增,順序不可跳;重建是最後一步,不是第一步
適用對象:監控軟體離線、gpresult 失敗、WMI 類別被回報「找不到」的人

📌 快速答案

一句話答案:WMI Repository 修復請依破壞性由低到高走——先備份,再用 winmgmt /verifyrepository 驗證一致性,確認不一致才跑 /salvagerepository 併修,/resetrepository 重置留到最後。

微軟官方文件明文警告:任何情況下都不要把「刪掉 Repository 資料夾」當成第一個動作。三個關鍵差異先講明白,免得你選錯指令:

/verifyrepository:官方定義是「執行一致性檢查」,文件並未描述它會重建 Repository(這點與下面兩個參數不同)。不帶路徑就驗目前使用中的 Repository,帶路徑可以驗一份已存檔的副本。
/salvagerepository:驗證後若偵測到不一致才重建,而且會把舊 Repository 讀得出來的內容併進新的——這是它跟重置最大的差別。
/resetrepository:直接把 Repository 打回作業系統初次安裝時的狀態,只有含 #pragma autorecover 的 MOF 會被自動還原回去。

🧰 開始前的準備

適用系統:Windows 11 / Windows 10 / Windows Server 2008 以上
權限需求:系統管理員。微軟支援團隊的官方封存文章即以「提升權限的命令提示字元」為前提執行 winmgmt /verifyrepository
需要工具:命令提示字元(系統管理員)、Windows PowerShell、事件檢視器(eventvwr.msc);全部是系統內建,不需要下載任何第三方工具
工具位置:winmgmt.exe 與 mofcomp.exe 都在 %Windir%\System32\wbem
預計耗時(站長實務估算,非官方數據——官方文件未提供任何執行時間基準):驗證數分鐘可完成;/salvagerepository 視 Repository 大小而定;完整重置加上重新註冊 MOF 最久
一定要先做的兩件事:①建立系統還原點 ②跑一次 winmgmt /backup(下面方法零會講)

⚠️ 先確認你要修的真的是 WMI。微軟在 winmgmt 官方文件的備註裡特別提醒(該備註不限作業系統版本):WMI 回傳的錯誤訊息未必代表 WMI 服務或提供者本身出問題,故障可能源自作業系統其他部分,只是以 WMI 錯誤的形式浮現。動 Repository 之前,先把「這台機器有沒有其他更明顯的毛病」排掉。

🔍 症狀描述與錯誤訊息

WMI 壞掉很少用一個乾淨的錯誤訊息告訴你「我壞了」,它幾乎都是從別的地方漏出來的:監控代理程式突然回報離線、資產盤點少了幾十台機器、群組原則套不下去、備份排程無聲無息地不跑。追進去才發現最底層是 WMI 查詢回不了資料。

實務上最常見的幾種表徵:

在 PowerShell 跑 Get-CimInstance -ClassName Win32_OperatingSystem 回錯誤或空值
gpresult /r 或 gpresult /h 失敗、回報無法取得原則資訊
系統管理軟體(監控、資產盤點、修補派送)在單台機器上持續失敗,其他機器正常
事件檢視器裡 WMI 相關錯誤反覆出現
明明存在的 WMI 類別被回報成「找不到」

最後一項特別值得記住。微軟官方在 WMI 疑難排解文件裡直接寫明:Repository 損毀可能偽裝成類別或執行個體「找不到」。錯誤字面上是「這個東西不存在」,實際成因卻是資料庫壞了——這是最容易讓人往「是不是缺元件」的方向找、結果整層找錯的特性。

常見的錯誤代碼,官方文件給了對照:

0x80041003 WBEM_E_ACCESS_DENIED — 被提供者拒絕存取。多半是權限不足、或以低權限身分呼叫方法、變更執行個體時發生。
0x80070005 E_ACCESS_DENIED — 被 DCOM 安全性拒絕。使用者沒有透過 DCOM 遠端存取該電腦的權限,常見於跨不同作業系統版本的遠端連線。
0x800706BA HRESULT_FROM_WIN32(RPC_S_SERVER_UNAVAILABLE) — 防火牆擋住連線,或目標電腦根本不存在(官方符號名即帶 HRESULT_FROM_WIN32() 包裝,裸的 RPC_S_SERVER_UNAVAILABLE 是 Win32 錯誤 1722)。
ERROR_INTERNAL_DB_CORRUPTION(錯誤碼 1358)— 這一個才是真正指向 Repository 的訊號。

另外,微軟支援團隊的封存文章給了一條很好用的事前線索:先翻 Windows「應用程式」記錄檔近一週、來源為 Microsoft-Windows-WMI 的事件,看有沒有事件 ID 28、65、5600、5601、5614——這幾個都可能代表 Repository 問題或核心基礎架構問題。查不到這些事件,才輪到內建的 Repository 檢查器上場。

最後那個 1358 值得單獨拉出來說。官方文件寫得很清楚:只要驗證作業判定 Repository 不在一致狀態,WMI 就會回傳 ERROR_INTERNAL_DB_CORRUPTION,而且任何會執行 Repository 驗證的指令都可能回它——/verifyrepository 會、/salvagerepository 也會。想看這個錯誤碼的中文說明,在命令提示字元敲:

net helpmsg 1358

🔎 問題根因

先給結論:WMI Repository 不是一個檔案,它是一整個資料夾裡好幾個檔案協同運作的資料庫;所以它的損毀模式,比較接近「資料庫索引壞掉」而不是「某個 dll 不見了」。

官方文件對它的定義是:WMI Repository 又稱 CIM Repository,不是單一檔案,而是 Repository 資料夾內一組共同運作、如同資料庫的檔案集合。這解釋了幾件實務上的困惑:為什麼不能「把壞檔換掉就好」、為什麼備份出來是一個壓縮檔、以及為什麼官方要求驗證用的存檔副本必須是整個 Repository 資料夾的複本。

Repository 存的是 WMI 的「類別定義與註冊資訊」:每個提供者(provider)安裝時把類別定義寫成 MOF 檔,由 mofcomp 編譯後寫進 Repository。所以它壞掉時,受害的不只是內建的 Win32_*,還包括所有把自己註冊進 WMI 的第三方軟體。

至於為什麼會壞?其中一項有官方明確背書:微軟支援團隊的封存文章在結尾特別提醒,若你的環境反覆發生 WMI 損毀,試著把 wbem 資料夾與其所有子資料夾排除在防毒掃描之外——防毒掃描已知會造成 WMI 損毀與其他問題。其餘常見誘因(非正常關機、儲存裝置寫入錯誤、磁碟空間耗盡導致寫入中斷、MOF 註冊做到一半失敗)則是實務歸納,微軟並未給出「損毀原因排行榜」,不是官方統計數字。

值得一提的是,微軟自己也承認診斷 WMI 問題變難了。官方文件明白寫著:WMI 診斷工具 WMIDiag.exe 自 Windows 8 與 Windows Server 2012 起就不再支援,而它原本的定位是「產生一份報告、通常能隔離問題來源並提供修正指示」。也就是說,現在的 Windows 上,你手裡能用的官方工具,就是 winmgmt 那幾個參數加上事件記錄——這正是為什麼「照順序做」比「找到神奇工具」重要得多。

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

先給結論:WMI 的錯誤訊號來自 Winmgmt 這個跑在 svchost 裡的服務,而它讀寫的對象就是 Repository;理解服務、Repository、MOF 三者的關係,才知道每個修復指令實際上動到了什麼。

Winmgmt 服務本身

官方文件對 Winmgmt 的定義是:它是 SVCHOST 行程內的 WMI 服務,以 LocalSystem 帳戶執行。它平常不會一直閒著佔資源——官方寫明,在所有情況下,只要第一個管理應用程式或指令碼要求連線到某個 WMI 命名空間,WMI 服務就會自動啟動。

所以發現 WMI 服務沒在跑,先別急著判定「服務掛了」——它本來就是被動啟動,真正該看的是「有東西來要資料時它起不起得來」。

MOF 與 `#pragma autorecover`:決定重建後救不救得回來

這是本文最關鍵的底層知識,直接決定你選 /salvagerepository 還是 /resetrepository 的後果。

mofcomp 是 MOF 編譯器,官方定義是「解析含 MOF 陳述式的檔案,並把其中定義的類別與類別執行個體加入 WMI Repository」。MOF 檔通常在軟體安裝時就自動編譯完成,但你也可以手動編譯。

重點來了。MOF 檔可以帶一個前置處理器指示詞 #pragma autorecover,官方對它的作用寫得非常直接——/salvagerepository 與 /resetrepository 兩個參數的說明裡都有同一句話:含有 #pragma autorecover 前置處理器陳述式的 MOF 檔,會被還原回 Repository。

反過來說呢?官方在 mofcomp 的文件裡給了那個沒帶 autorecover 時會跳的警告全文,意思是:如果日後 WMI Repository 被重建,這個 MOF 檔的內容不會被納入新的 Repository。

兩句話合起來就是一條很硬的推論:重建之後能自動回來的,只有當初帶了 #pragma autorecover 的 MOF;沒帶的就是不見了。 這就是為什麼裝了監控代理、備份軟體、伺服器管理套件的機器,重置後那些軟體常常「不會自己好」——不是它們壞了,是類別定義沒被帶回來。

順帶一提,autorecover 的清單存在哪?官方寫明 mofcomp -autorecover 會把該 MOF 加進「Repository 復原時要重新編譯的檔案清單」,而這份清單存在登錄機碼 HKLM\SOFTWARE\Microsoft\WBEM\CIMOM。要事前盤點「重建後哪些東西會自動回來」,這裡就是答案。

錯誤訊號怎麼被記下來

舊經驗要更新一下:WMI 的 log 檔已經不存在了。官方文件寫明,自 Windows Vista 起 WMI 改用 Event Tracing for Windows(ETW),事件透過事件檢視器或 wevtutil 命令列工具取得;官方把 %windir%\system32\wbem\logs 歸在「Windows Vista 之前的 WMI log 檔」一節,不過該路徑在 Vista 之後並沒有消失——它改放 WPP 追蹤產出的 WMITracing.log(官方追蹤文件的 tracefmt 步驟就指向這裡)。要更新的是觀念:舊式文字 log 機制已由 ETW 取代,不是那個資料夾不見了。

而且 WMI 事件預設是不追蹤的。官方給的開啟步驟是:開啟事件檢視器,在「檢視」選單點「顯示分析與偵錯記錄檔」,然後到 應用程式及服務記錄檔 → Microsoft → Windows → WMI Activity 底下找到 Trace 通道,右鍵開記錄檔內容、勾選啟用記錄。

不想點介面的話,官方也給了命令列版本:

Wevtutil.exe sl Microsoft-Windows-WMI-Activity/Trace /e:true

追蹤打開後,事件的編號有固定語意,官方文件列得很清楚:

事件 ID	意義	關鍵欄位
1	某個操作的事件序列開始,每個序列一次	Operation、User、Namespace
2	組成該操作的事件,序列中一次或多次	ProviderName、Path
3	事件序列結束,每個序列一次	只顯示 GroupOperationID

這張表的實戰價值在於:當你看到事件 2 裡的 ProviderName,你就知道是哪一個提供者在出事——這比「WMI 壞了」精確太多,也常常能讓你避開重建 Repository 這條路。

WMI Repository 處置順序流程圖:備份與驗證在前,不一致才併修,重置留到最後

🛠️ 解決方案

⚠️ 執行前警語(⭐⭐⭐ 高風險操作)
本節的 /salvagerepository 與 /resetrepository 都會重建 WMI Repository。重建後,只有含 #pragma autorecover 的 MOF 會被自動還原;其餘第三方軟體註冊的 WMI 類別可能需要重新註冊或重裝該軟體。
執行前務必:①電源接好、不要用剩餘電量在跑 ②建立系統還原點 ③先跑 winmgmt /backup 備份 Repository ④確認你知道這台機器上裝了哪些依賴 WMI 的管理軟體。
微軟官方的原話值得原封抄一次:任何情況下,都不要把刪除 WMI Repository 當成第一個動作,因為刪除 Repository 可能造成系統或已安裝應用程式的損壞。

🛑 停止條件清單(符合任一項,請不要繼續往下做)
– 不確定這台機器的 Windows 版本或版次
– 尚未建立系統還原點,也還沒跑過 winmgmt /backup
– 已啟用 BitLocker 但手邊沒有修復金鑰
– 這是公司或學校的受管控裝置,而你沒有 IT 部門授權
– 這台是生產環境伺服器,且上面跑著依賴 WMI 的監控或叢集服務,你無法承擔重新註冊的風險
– 指令輸出與本文描述不符(例如驗證明明回報一致,卻還是想直接重置)

📚 這個順序的依據:winmgmt 的官方參考文件本身沒有規定修復步驟的先後,它只明文警告不要把刪除 Repository 當第一個動作。本文採用的順序,依據是微軟支援團隊的官方封存文章(2014 年發表、現存於 Microsoft Learn 封存區)所載的處置流程:先以提升權限的命令提示字元跑 winmgmt /verifyrepository,回報不一致才跑 /salvagerepository、跑完再驗一次,仍不一致才用 /resetrepository。文中最前面那一步「備份」不是微軟規定的第一步,是站長依「每一步都要有退路」的實務原則加上去的——該文另外也建議設一個定期備份的排程工作跑 winmgmt /backup。

方法零:先備份,這步不能跳

在動任何修復指令之前,先把現況存下來。以系統管理員身分開啟命令提示字元:

winmgmt /backup C:\WMIBackup\repo_20260816.bin

幾個官方細節要知道:

檔名要給完整路徑。官方寫明,如果你沒指定路徑,備份檔會被放進 %Windir%\System32 目錄——那不是你想找檔案的地方。
備份過程會鎖住 Repository。官方說明:這個程序需要 Repository 的寫入鎖,因此在備份完成前,對 Repository 的寫入作業會被暫停。所以不要在系統忙碌時做。
備份出來是單一壓縮檔。官方特別註明,Repository 本身是一整個資料夾的檔案集合,但用 /backup 備份出來的結果是單一壓縮檔。

建議搭配建立系統還原點一起做,雙保險。如果你不熟悉還原點的建立與還原,可以先看站長寫過的 Win10/Win11 系統還原點完整教學把退路鋪好再回來。

方法一:先驗證,不要先修

這是最重要、也最常被跳過的一步。在確認 Repository 真的不一致之前,不要執行任何重建動作。

winmgmt /verifyrepository

官方對它的定義是:對 WMI Repository 執行一致性檢查。不加路徑參數時,驗證的是 WMI 目前正在使用的即時 Repository。

判讀結果很單純:

回報一致 → Repository 沒問題,你的故障來源在別的地方,請往上回頭看「先確認你要修的真的是 WMI」那段
回報不一致 → 依微軟支援團隊封存文章的描述,Repository 有問題時會回應「repository is not consistent」
回報 ERROR_INTERNAL_DB_CORRUPTION / 錯誤 1358 → 確認不一致,可以往方法二走

想驗證一份存檔的副本(例如你想確認手邊的備份是不是乾淨的),官方支援帶路徑:

winmgmt /verifyrepository C:\SavedRepo\Repository

這裡有個很多人踩過的坑:官方寫明,那份存檔的 Repository 應為整個 Repository 資料夾的複本(原文用的是 should be)。挑幾個檔案複製出來,實務上驗不出你要的結果。

方法二:`/salvagerepository` 併修(優先於重置)

驗證確認不一致後,這才是你該用的第一個修復指令:

winmgmt /salvagerepository

官方定義寫得很精準,值得逐句拆:

它會先做一致性檢查,偵測到不一致才重建 Repository。 換句話說,Repository 沒問題時它不會亂動。
不一致的 Repository 內容,只要讀得出來,就會被併入重建後的 Repository。 這是它跟重置最本質的差別——它試著救,不是砍掉重練。
這個作業一律針對 WMI 服務目前正在使用的 Repository。 它不會去動你的備份副本,也不能指定路徑。
含 #pragma autorecover 的 MOF 會被還原回 Repository。

跑完之後,務必再驗一次:

winmgmt /verifyrepository

回報一致就往「驗證修復結果」那節走。如果還是 1358,才考慮方法三。

方法三:`/resetrepository` 重置(終極手段)

這是最後手段,不是「修不好就跑一下試試」的指令。

winmgmt /resetrepository

官方定義只有一句,但這一句的份量很重:Repository 會被重置為作業系統初次安裝時的初始狀態;含 #pragma autorecover 的 MOF 會被還原回去。

請把這句話翻譯成實務後果:這台機器安裝作業系統之後,所有第三方軟體寫進 WMI 的類別定義,只要當初的 MOF 沒帶 #pragma autorecover,就回不來了。 監控代理程式、資產盤點工具、備份軟體、伺服器廠商的管理套件,全都在這個風險範圍內。

執行前,建議先把「哪些東西會自動回來」盤點一次。前面提過,autorecover 清單存在 HKLM\SOFTWARE\Microsoft\WBEM\CIMOM。用 PowerShell 唯讀查詢即可,不需要改任何東西:

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\WBEM\CIMOM').'Autorecover MOFs'

要讀的是那個名為 Autorecover MOFs 的字串值裡面的資料,不是機碼底下的值名稱——封存文章的做法就是用 regedit 打開這個值、把資料貼到記事本裡看。

如果執行時跳出 0x8007041B,官方訊息的描述是「已對一個仍有其他執行中服務相依於它的服務送出停止控制」——白話說就是有別的服務掛在 WMI 上,所以停不掉。封存文章給的處置是先連相依服務一起停掉再重跑:

net stop winmgmt /y

停完之後再執行一次 winmgmt /resetrepository。這一步會連帶停掉依賴 WMI 的服務,做完記得確認它們有回來。

⚠️ 另外一個封存文章特別強調的紅線:幾乎在任何情況下,都不要用那種「把 wbem 資料夾裡所有 MOF 全部 mofcomp 一遍」的重建腳本。 原因有二:資料夾裡有一堆 *_uninstall.mof,腳本會把類別裝進去又立刻卸載掉;而且 MOF 的重放常常有順序相依性,依賴的類別不在就插不進去。用了不但修不好,還會把可用來查根因的資訊一起洗掉。

重置完成後,對於那些沒有被自動還原的第三方類別,官方提供的補救工具是 mofcomp。標準做法是重裝該軟體,讓它的安裝程式自己重新註冊;真的要手動編譯特定 MOF 時,語法是:

mofcomp -autorecover "C:\Path\To\Provider.mof"

加上 -autorecover 的意義前面說過:把這個 MOF 加進「Repository 復原時要重新編譯」的清單,下次再重建就不會又不見。想在編譯前先確認 MOF 語法有沒有問題,官方提供只檢查不寫入的參數:

mofcomp -check "C:\Path\To\Provider.mof"

官方特別註明,-check 不會連線 WMI、不會修改 Repository,而且不能跟其他參數並用。

mofcomp 的回傳值官方也列明了,排錯時很好用:

回傳值	意義
0	編譯成功
1	無法連上 WMI 伺服器(語意錯誤或服務未啟動)
2	命令列參數無效
3	MOF 語法錯誤

最後一個必須誠實告知的風險:官方寫明,當更新 Repository 的過程中發生錯誤,編譯器不會嘗試把 Repository 還原到編譯開始前的狀態。所以手動編譯 MOF 之前,那份 /backup 備份就是你唯一的退路。

附帶一提:效能計數器類別怪怪的

如果你的症狀只集中在效能監視相關的 WMI 類別,那可能不是 Repository 的問題。官方為此準備了另一個參數:

winmgmt /resyncperf <WMI 服務的處理序 ID>

官方語法帶一個引數 <winmgmt service process id>,也就是 WMI 服務的處理序 ID。官方說明:把電腦的效能程式庫重新註冊到 WMI,只有在效能監視類別回傳的結果不可靠時才需要。不要把它當成一般性修復指令亂跑。

✅ 驗證修復結果

修完之後別急著關視窗。要確認問題是真的解決而不是暫時消失,建議跑完下面四項:

① 再驗一次一致性

winmgmt /verifyrepository

這是最直接的判準。回報一致才算過關。

② 確認基本查詢會動

Get-CimInstance -ClassName Win32_OperatingSystem

Get-CimInstance 的預設命名空間是 root/CIMV2,這條查詢等於在測「最常用的那個命名空間活不活」。順帶一提,它在 PowerShell 裡有別名 gcim,而且官方註明這個指令只在 Windows 平台可用。

③ 確認命名空間清單完整

Get-CimInstance -Namespace root -ClassName __Namespace

這是官方文件裡直接給的範例用法,作用是列出 root 底下的命名空間清單。重置過 Repository 的機器特別要看這一項——如果某個第三方軟體的命名空間不見了,就代表它的類別沒被帶回來,該去重裝或重新註冊了。

④ 回到原本失敗的那件事

最後,把當初讓你發現問題的那個動作再做一次:重跑 gpresult /r、讓監控代理程式重新回報、重跑那支查詢 WMI 的腳本。WMI 修好了但業務層還是失敗,代表底下還有第二個問題。

如果修完之後某個提供者還是在報錯,下一步就是回到事件檢視器:一邊照前面「底層機制」那節把 WMI Activity 的 Trace 通道打開、看事件 2 裡的 ProviderName 是誰在出事,一邊翻「應用程式」記錄檔確認同一時段有沒有其他非 WMI 的系統錯誤——很多時候真兇是後者。事件檢視器怎麼開、怎麼判讀時間軸,站長另外寫過用事件檢視器讀懂當機紀錄可以先補起來。

🔙 萬一翻車:回退步驟

修 WMI 最怕的不是修不好,是修完之後一堆軟體集體罷工。照下面順序退:

第一步:用 /restore 還原你的備份

winmgmt /restore C:\WMIBackup\repo_20260816.bin 1

最後那個數字是模式旗標,官方定義得很明確:1 代表強制中斷使用者連線後還原,0 代表沒有使用者連線時才還原(預設)。桌機環境通常用 1;伺服器上請先確認沒有正在跑的重要作業。

還有一個讓人安心的官方設計:執行還原時,WMI 會先保存現有的 Repository,以便還原失敗時能寫回去。也就是說,還原這個動作本身有內建的保險。

第二步:還原系統還原點

/restore 沒救回來(例如備份本身就是壞的),就回頭用方法零建立的系統還原點,把系統狀態整個退回動手之前。

第三步:重新註冊受影響的軟體

Repository 回來了但某些軟體還是抓不到資料,通常是它的 WMI 類別沒被帶回。優先做法是重裝或修復安裝該軟體——安裝程式知道自己要註冊哪些檔案、註冊到哪個命名空間,比手動 mofcomp 可靠得多(封存文章對「物件抓不回來」給的第一個建議,同樣是重裝該產品)。

第四步:最後才考慮就地升級

如果整台機器的系統元件狀態都很可疑(不只 WMI),與其一項一項修,不如做就地升級把系統檔整批換掉、同時保留程式與資料:Windows 不重灌也能修復?就地升級完整教學。

💡 總結:預防再次發生

站長我處理這類「底層元件壞掉」的案子,原則從來沒變過:破壞性越強的指令越要往後放,而且每往後一步都要有一份能退回去的東西。 WMI 特別容易出事,就是因為網路上到處是「跑 /resetrepository 就好」這種一步到位的答案——它常常有效,代價卻是把第三方類別定義一起清掉,使用者往往幾天後發現監控沒資料才反應過來。

微軟自己把話講得比誰都重:任何情況下都不要把刪除 Repository 當成第一個動作,後果是「可能造成系統或已安裝應用程式的損壞」。既然原廠這樣寫,把「先驗證、再併修、最後重置」當成鐵律並不過分。

日常預防抓三件事:①定期跑 winmgmt /backup,對裝了一堆管理軟體的機器,它該跟系統還原點一樣進例行維護;②把 wbem 資料夾排除在防毒掃描之外——這條是微軟支援團隊封存文章自己提的,反覆損毀的環境優先試;③先看事件、再動指令,只要能從事件 2 的 ProviderName 定位到單一提供者,多半根本不必重建整個 Repository。

最後補一句:懷疑的若是更廣泛的系統檔損毀而不只是 WMI,SFC 與 DISM 才是該先跑的工具,順序別顛倒——用法與常見誤區看 SFC 與 DISM 指令修復教學。

❓ 常見問題

Q:/salvagerepository 跟 /resetrepository 到底差在哪?我可以直接跑重置嗎?

差別在「救不救舊資料」。官方定義寫明,/salvagerepository 會把不一致 Repository 中讀得出來的內容併入重建後的 Repository;/resetrepository 則是重置為作業系統初次安裝時的初始狀態。技術上你可以直接跑重置,但會失去所有沒帶 #pragma autorecover 的第三方類別定義——能不跑就不要跑。

Q:重建 Repository 之後,哪些東西會自己回來?

只有含 #pragma autorecover 前置處理器陳述式的 MOF 檔會被還原回 Repository,這是官方對 /salvagerepository 與 /resetrepository 兩者共同的明文說明。沒帶這個指示詞的 MOF,官方在 mofcomp 的警告訊息裡也講得很白:Repository 日後若被重建,該 MOF 的內容不會被納入新的 Repository。要事前盤點,查登錄機碼 HKLM\SOFTWARE\Microsoft\WBEM\CIMOM 裡的 autorecover 清單。

Q:我可以直接把 System32\wbem\Repository 資料夾刪掉或改名嗎?網路上很多人這樣教。

「刪掉」這件事微軟官方文件講得非常明確:任何情況下,都不要把刪除 WMI Repository 當成第一個動作,因為刪除 Repository 可能造成系統或已安裝應用程式的損壞。 同樣的警告也出現在 WMI 疑難排解文件裡。官方既然提供了 /verifyrepository、/salvagerepository、/resetrepository 三個受控的指令,一般情境就沒有理由去動檔案系統。

「改名」則要把範圍講清楚:官方那句警語針對的是「把刪除當第一個動作」,並沒有說改名在任何情況下都不行——微軟支援團隊的封存文章自己就在一個很特定的情境(Windows Server 2012 叢集機、且叢集提供者的 uninstall MOF 帶了 autorecover)下,把「將 Repository 資料夾改名為 Repository.old」列為手動重建流程的其中一步。所以正確理解是:改名只在已經跑過驗證與併修、且確認自己落在那類特定情境時,才依封存文章的流程使用,不是一般排錯的起手式。

Q:winmgmt /verifyrepository 回報一致,但我的問題還在,怎麼辦?

那代表 Repository 不是兇手,繼續修它只是浪費時間。官方在 winmgmt 文件的備註裡提醒過:WMI 回傳的錯誤未必表示 WMI 服務或提供者有問題,故障可能源自作業系統其他部分,只是以 WMI 錯誤的形式浮現。這時候該做的是打開 WMI Activity 的 Trace 通道,從事件 2 的 ProviderName 往上追是哪個提供者出事,或者回頭檢查權限、DCOM 與防火牆設定(對應 0x80070005 與 0x800706BA 兩類錯誤)。

Q:有沒有官方的 WMI 診斷工具可以一鍵找出問題?

以前有,現在沒有了。官方文件寫明,WMI 診斷工具 WMIDiag.exe 自 Windows 8 與 Windows Server 2012 起不再支援;它原本會產生一份能隔離問題來源、並提供修正指示的報告,現在已不再提供。目前 Windows 上可用的官方手段,就是 winmgmt 的各項參數加上 ETW 事件記錄。

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

反覆損毀通常代表底下有更根本的成因。微軟支援團隊封存文章對這種情況直接給了一條建議:把 wbem 資料夾與所有子資料夾排除在防毒掃描之外。其餘優先檢查磁碟健康度與檔案系統錯誤、是否反覆非正常關機。同時把 winmgmt /backup 排進例行維護,讓每次復發的復原成本降到最低。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

winmgmt — Microsoft Learn — 2026-08-16 查證
WMI Troubleshooting — Microsoft Learn — 2026-08-16 查證
mofcomp — Microsoft Learn — 2026-08-16 查證
Tracing WMI Activity — Microsoft Learn — 2026-08-16 查證
Logging WMI Activity — Microsoft Learn — 2026-08-16 查證
Get-CimInstance — Microsoft Learn — 2026-08-16 查證
WMI: Repository Corruption, or Not?(微軟支援團隊部落格,2014-08-08 發表,現存於 Microsoft Learn 封存區) — 2026-08-16 查證

⚠️ 本文所有指令定義、參數語意、錯誤碼與風險警告皆取自上列第一級官方文件。處置順序、事件 ID 清單、防毒排除建議與重建腳本紅線,取自最後一筆微軟支援團隊封存文章——該文 2014 年發表、標示為封存內容,引用時已於內文註明其性質;文中關於損毀誘因與耗時的估計屬經驗性整理而非官方統計,亦已逐處標示。本文未引用第二級來源。

📅 本文查證戳記:2026-08-16 依 Microsoft Learn 官方文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。