WMIリポジトリのトラブルシューティング・修復・再構築の完全ガイド【Windows 10/Server 2016/2019対応】

経験豊富なWindows管理者であれば、WMIサービス（Windows Management Instrumentation）やそのコンポーネントに関するトラブルに一度は遭遇したことがあるでしょう。WMIサブシステムの不具合はWindowsの正常な動作に重大な影響を及ぼすため、管理者はできるだけ早くWMIの機能を確認し、復旧させる必要があります。本記事では、Windows 10およびWindows Server 2016/2019におけるWMIの問題を比較的簡単な手順で診断・修復する方法を解説します。

WMIに問題が発生している場合、さまざまなエラーとして現れる可能性があります。主な症状は以下のとおりです。

• システムログやアプリケーションログにWMIクエリ処理のエラーが記録される（0x80041002 - WBEM_E_NOT_FOUND、WMI: Not Found、0x80041010 WBEM_E_INVALID_CLASS など）；
• グループポリシー（GPO）処理に関連するエラーが発生する（WMIフィルターの誤動作など）；
• WMIクエリの応答が極端に遅い；
• SCCM/SCOMエージェントのインストール時または稼働中にエラーが発生する；
• WMI名前空間を使用するスクリプト（VBSやPowerShellの Get-WmiObject など）でエラーが発生する。

WMI問題のトラブルシューティング

最初に行うべきは、Windows Management Instrumentation（Winmgmt）サービスがインストールされ、実行中であることの確認です。サービスの状態は services.msc コンソール、または以下のPowerShellコマンドで確認できます。

Get-Service Winmgmt | Select DisplayName,Status,ServiceName

Winmgmtサービスが稼働していれば、簡単なWMIコマンドを実行してWMIの健全性をテストできます。WMIクエリはコマンドプロンプトからでもPowerShellからでも実行可能です。たとえば、次のコマンドはWindowsにインストールされているプログラムの一覧を表示します。

wmic product get name,version

また、PowerShellでWindows 10のバージョンとビルド情報をWMI経由で取得する最もシンプルなコマンドは次のようになります。

get-wmiobject Win32_OperatingSystem

これらのコマンドに対してWMIサービスが正しく応答すれば、WMIは正常に動作しています。逆に、WMIクエリの実行時にエラーが返される場合は、WMIサービスが正しく動作していないか、WMIリポジトリが破損している、あるいはその他の問題が存在すると考えられます。

たとえば、コンピューターの管理スナップイン（compmgmt.msc）で「WMIコントロール」のプロパティを開こうとした際に、以下のようなメッセージが表示されることがあります。

Failed to initialize all required WMI classes
Win32_Processor. WMI: Invalid namespace
Win32_WMISetting. WMI: Invalid namespace
Win32_OperationSystem. WMI: Invalid namespace

以前は、Microsoft公式の診断ツール WMIDiag.vbs（Microsoft WMI Diagnosis）を使ってWMIの診断を行うのが一般的でした。WMIDiagはVBSスクリプトであり、WMIサブシステムの各種コンポーネントをチェックし、収集した情報をログファイルに出力します（デフォルトでは %TEMP% フォルダー、つまり C:\USERS\%USERNAME%\APPDATA\LOCAL\TEMP\ に保存されます）。生成されるレポートは WMIDIAG-V2.2 で始まる名前のファイル群で構成され、以下の種類があります。

• LOGファイル：WMIDiagツールの動作状況に関する詳細レポート；
• TXTファイル：検出されたエラーの中で注目すべき項目のサマリーレポート；
• CSVファイル：WMIパフォーマンスの長期的な分析に必要な情報。

ヒント： Windows x64版では、wmidiag.vbsは次のように実行する必要があります。
c:\windows\System32\cscript.exe wmidiag.vbs
そうしない場合、以下のエラーが発生します。

WMIDiag must be run from native 64-bit environment. It is not supported in Wow64.

WMIDiagの実行後、管理者はログファイルを確認し、検出されたエラーを分析して修復を試みます。

ただし残念ながら、WMIDiagの最新バージョン2.2はWindows 8.1／Windows Server 2012 R2までの環境でしか正しく動作しません。現時点でMicrosoftはダウンロードセンターからWMIDiagへのリンクも削除していますが、必要であればWeb上でスクリプトを見つけることは可能です。

WMIDiagはWMIのローカルなエラーを修正するための詳細な情報を提供しますが、その作業は多くの場合時間のかかるタスクであり、コストに見合うのはクリティカルなシステム（主に本番サーバー）での問題解決時だけです。ユーザーのワークステーションであれば、WMIリポジトリのリセットと再構築を実行する方がはるかに簡単です。

WMIリポジトリの修復とMOFファイルの再コンパイル

Windows 10／Windows Server 2016では、次のコマンドでWMIリポジトリの整合性を確認できます。

winmgmt /verifyrepository

このコマンドがWMIデータベースの不整合（INCONSISTENT または WMI repository verification failed）を返した場合は、まずソフト修復によるWMIリポジトリのエラー修復を試みてください。

Winmgmt /salvagerepository

WMI repository has been salvaged.

このコマンドはWMIリポジトリの整合性をチェックし、不整合が検出された場合にWMIデータベースを再構築します。

続いて、WMIサービスを再起動します。

net stop Winmgmt
net start Winmgmt

標準的な修復手順で改善しない場合は、次のスクリプトを試してください。このスクリプトは、DLLライブラリとWMI関連コンポーネントの再登録、およびMOFファイルの再コンパイルを行う「ソフト」な復旧オプションです。この手順は安全であり、OSに新たな問題を引き起こすことは基本的にありません。

sc config winmgmt start= disabled
net stop winmgmt
cd %windir%\system32\wbem
for /f %s in ('dir /b *.dll') do regsvr32 /s %s
wmiprvse /regserver
sc config winmgmt start= auto
net start winmgmt
for /f %s in ('dir /b *.mof') do mofcomp %s
for /f %s in ('dir /b *.mfl') do mofcomp %s

64ビット版のWindowsでは、SysWOW64ディレクトリに対しても同じ手順を実行する必要があります。3行目を次のように置き換えてください。

cd %windir%\SysWOW64\wbem

これらのコマンドはコマンドプロンプトに直接貼り付けて実行することもできますし、BATファイル（例：wmi_soft_repair.bat）として保存し、管理者権限で実行することもできます。スクリプト完了後はWindowsを再起動し、WMIが正常に動作しているかどうかを確認してください。

WMIリポジトリの再構築

上記の方法でも問題が解決しない場合は、より「ハード」な復旧手段、すなわちWMIリポジトリの再作成を実行します。

WMIリポジトリは %windir%\System32\Wbem\Repository に格納されており、WMIクラスのメタデータや定義情報を含むデータベースです。場合によっては静的なクラス情報も含まれます。リポジトリが破損すると、WMIサービス（Winmgmt）の動作にエラーが発生します。

WMIリポジトリの破損が疑われる場合、他のあらゆる復旧手段が効果を発揮しなかった場合にのみ再作成を行うべきである点に注意してください。

次のコマンドは、WMIデータベースをクリーンインストール直後の初期状態にリセットします。/salvagerepository パラメーターで問題が解決しなかった場合に、WMIリポジトリを強制的にリセットするために使用します。

Winmgmt /resetrepository

ヒント： 実運用では、WMIリポジトリの再構築によってサードパーティ製ソフトウェアに問題が生じるケースがあります。理由は、WMIデータベース内のすべてのレコードがクリーンな状態まで消去されるためです。該当するソフトウェアは、復旧モードでの再インストールが必要になる場合があります。

Winmgmt /salvagerepository と Winmgmt /resetrepository の両方のコマンドでもWMIデータベースの整合性が回復しない場合は、次のスクリプトによる強制リセットを試みてください。

sc config winmgmt start= disabled
net stop winmgmt
cd %windir%\system32\wbem
winmgmt /resetrepository
winmgmt /resyncperf
if exist Repos_bakup rd Repos_bakup /s /q
rename Repository Repos_bakup
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
for /f %s in ('dir /b *.dll') do regsvr32 /s %s
for /f %s in ('dir /b *.mof') do mofcomp %s
for /f %s in ('dir /b *.mfl') do mofcomp %s
sc config winmgmt start= auto
net start winmgmt
wmiprvse /regserver

64ビット版Windowsの場合は、%windir%\sysWOW64\wbem ディレクトリ内のDLL/EXEの再登録とMOFファイルの再コンパイルも併せて実行する必要があります。

このスクリプトはWMIリポジトリフォルダーを完全に削除して再作成します（古いリポジトリは Repos_backup ディレクトリに退避されます）。スクリプト完了後はWindowsを再起動し、簡単なクエリでWMIサービスを確認してください。

最後に、WMIリポジトリの状態をチェックします。エラーが解消されていれば、winmgmt /verifyrepository コマンドは次のように返すはずです。

WMI repository is consistent

本記事では、WMIサービスおよびリポジトリを診断し、トラブルシューティングするための基本的な手法を紹介しました。軽微な不整合には /salvagerepository、深刻な破損には /resetrepository やMOFファイルの再コンパイルといった段階的なアプローチを採用することで、多くのWMI関連問題を安全に解決できます。