WMI (Windows Management Instrumentation) の問題への対処は、時に本当に頭の痛い問題になることがあります。WMI クエリが遅い、 のようなログにエラーがある0x80041002 - WBEM_E_NOT_FOUND、スクリプトが正しく実行されないなどの問題は、多くの場合、WMI リポジトリの破損が原因です。奇妙に思えますが、これらの問題の修復は必ずしも簡単ではありません。サービスを再起動するだけでは不十分な場合があります。そこで、このガイドでは、問題が発生した場合に WMI リポジトリを検証、修復、再構築するための手順をいくつか紹介します。目標は、システムを正常な状態に戻すこと、または少なくとも WMI が混乱を引き起こさない状態に戻すことです。PowerShell やコマンド プロンプトなどのコマンド ラインを数回実行し、Windows が処理するまでしばらく待つ必要があります。必ずしも迅速で完璧ではありませんが、やみくもに操作するよりはましです。
WindowsでWMIの問題を解決する方法
WMIサービスが実行中であり応答しているかどうかを確認する
これが最初のチェックポイントです。車のエンジンを修理する前にガソリンが入っているか確認するようなものです。Winmgmt（Windows Management Instrumentationサービス）がインストールされ、実行されていることを確認してください。 「ファイル名を指定して実行」（と入力し、 と入力）でservices.mscを開き、 Windows Management Instrumentationを探します。「自動」に設定され、ステータスが「実行中」になっていることを確認してください。Win + Rservices.msc
あるいは、PowerShell から次のコマンドで確認することもできます。
Get-Service Winmgmt | Select DisplayName, Status, ServiceNameサービスが実行されていない場合は、右クリックして起動してください。既に実行されているにもかかわらず問題が解決しない場合は、WMIの正常性確認に進んでください。設定によっては、この手順でシステムを更新し、軽微な問題を修正できる場合があります。
シンプルなクエリでWMIをテストする
サービスが稼働している場合は、次に基本的なクエリを実行して、WMIが正しく応答するかどうかを確認します。管理者としてPowerShellを開き、以下を試してください。
wmic product get name, versionインストール済みのプログラムがクラッシュすることなく一覧表示されるはずです。Windowsのバージョンも確認できます。
Get-WmiObject Win32_OperatingSystemこれらのコマンドが正常に実行された場合、WMI はおそらく正常です。ただし、エラーが発生したりハングしたりする場合は、リポジトリに破損や問題が発生している可能性があります。
さらに調査するためにWMI呼び出しのログ記録を有効にする
WMIログは、何が問題なのかを詳しく調べるのに非常に役立ちます。PowerShellで以下のように詳細なログ記録を有効にしてください。
wevtutil set-log Microsoft-Windows-WMI-Activity/Operational /enabled:true次に、イベントビューアー（ eventvwr.msc ）を開き、 「アプリケーションとサービスログ」>「Microsoft」>「Windows」>「WMI-Activity」を確認します。イベントID 5858のエラーが表示されている場合は、特定のクラスまたは名前空間の問題を示しており、データベースの破損またはクラスの構成ミスが示唆される可能性があります。
WMIリポジトリの整合性を確認する
破損の疑いがある場合は、これが良い方法です。以下を実行してください。
winmgmt /verifyrepository出力結果に矛盾や破損が見られる場合は、修正を試みるタイミングです。より影響の少ない方法は次のとおりです。
winmgmt /salvagerepositoryこれは、すべてを消去せずにリポジトリを修復しようとします。その後、Winmgmtサービスを再起動します。
net stop Winmgmt && net start Winmgmtそれでも問題が解決しない場合は、すべてのDLLを再登録し、MOFファイルを再コンパイルする必要があるかもしれません。すべてを安全に再登録するためのスクリプト（GitHubのWinhanceなど）がいくつか公開されています。これらのスクリプトは、管理者権限で実行し、昇格したコマンドプロンプトで実行してください。
WMIリポジトリの再構築またはリセット
WMI を修復しようと試みても完全に壊れてしまい、 や のようなコマンドで悪い結果が出る場合は/salvagerepository、/verifyrepository完全な再構築を行う必要があるかもしれません。これには、データベースを既知の正常な状態にリセットし、カスタムクラスは失われますが、コアの問題を修正することが含まれます。
コマンドプロンプトで管理者としてこのコマンドを実行します。
winmgmt /resetrepositoryこれによりリポジトリが完全に消去されるため、注意が必要です。カスタムWMIクラスや、特定のWMIクラスに依存するサードパーティ製アプリは、この後動作しなくなる可能性があります。完了したら、Windowsを再起動し、基本的なWMIクエリで再度テストしてください。それでもエラーが続く場合は、より積極的な方法として、リポジトリを完全に削除して再作成してください。以下の手順をご覧ください。
net stop winmgmt rd %systemroot%\System32\Wbem\Repository /s /q net start winmgmt64ビットシステムでは、 %windir%\SysWOW64\wbemでも同じ操作を忘れずに実行してください。ディレクトリパスを適宜置き換えてください。その後、再起動してテストを再度実行してください。これは非常に危険な手段ですが、場合によっては必要になることもあります。
すべてが失敗したとき — ハードリセット
それでもWMIがうまく動作しない場合は、リポジトリ全体を手動でリセットし、DLLを再登録するか、特定のコンポーネントを再インストールする必要があるかもしれません。これは最終手段ですが、リポジトリの破損はクエリの失敗からシステムエラーまで、あらゆる問題を引き起こすことがよくあります。データベースを最初から再構築すれば通常は解決しますが、カスタムWMIクラスやWMIに依存するサードパーティ製アプリの再設定が必要になるなど、少なくともいくつかの副作用が生じることを覚悟してください。
私の経験では、これらのコマンドとスクリプトでWMIのトラブルのかなり多くを解決できました。必ずしも最初の試みで解決できるとは限りませんが、いくつかのコアコマンドをもう一度覚えれば確実に解決できます。Windowsはこうした問題を不必要に謎めいたものにする傾向があるため、忍耐が鍵となります。
まとめ
- Winmgmt が実行中かどうか確認し、必要に応じて再起動します。
- 簡単なクエリでWMIの応答性をテストする
- WMI ログを有効にし、イベント ビューアーでエラーを確認します。
- リポジトリの整合性を検証し、復旧を試みる
- 破損が続く場合は、WMIリポジトリを再構築またはリセットします。
- 最後の手段として完全なリセットを使用してください。副作用が発生する可能性があります。
まとめ
WMIのトラブルシューティングは確かに面倒です。しかし、健全性の確認、復旧、再構築の方法を知っていれば、通常はシステムをすぐに復旧できます。ただし、これはデリケートな問題なので、コマンドを闇雲に実行するのではなく、各ステップごとに必ずテストしてください。この記事が誰かの時間を節約し、イライラを解消してくれることを願っています。少しでもお役に立てれば幸いです。少なくとも、何が問題なのかを推測しようと頭を悩ませるよりはましです。