シナリオ ガイド: WMI パフォーマンスの問題のトラブルシューティング

  • [アーティクル]

この記事では、Windows Management Instrumentation (WMI) のパフォーマンスの問題を解決するためにメモリ リークを調べたり、リークを処理したりするさまざまな方法と、追加情報を収集する方法について説明します。

次のシナリオまたは問題が発生する可能性があります。

  • マシンの実行速度が遅くなります。
  • msinfo32.exe や compmgmt.msc などのtasklistコマンドを実行すると、応答に時間がかかるか、適切な結果が表示されません。
  • WMI に応じたアプリケーションまたはクライアントでは、情報のフェッチまたは表示に問題が発生するか、最終的に失敗します。
  • WMI クエリは、WBEM_E_INVALID_CLASSやWBEM_E_NOT_FOUNDなどのエラーで失敗します。
  • WMI サービス (Winmgmt) が応答していません。
  • マシンの合計メモリは 100% に達します。

また、 svchost.exe (Winmgmt サービスをホストしている) または WmiPrvse.exe プロセスのいずれかが高いメモリを消費しているか、特定の時点でタスク マネージャーで高いハンドル数を持っていることにも気付きます。 マシンまたは Winmgmt サービスが再起動された場合、または問題のある WmiPrvse.exe プロセスが手動で終了した場合、メモリの高い状況は一時的に軽減されます。 ただし、しばらくすると問題が再発します。

メモリ リークまたはハンドル リークの考えられる原因

WMI サービスまたは WmiPrvse.exe プロセスがメモリまたはハンドルを消費し、時間の経過と同時にハンドルを減少または解放しない場合、それぞれメモリ リークまたはハンドル リークと見なされます。

リークの理由はシナリオによって異なりますが、一般的には次のことが原因です。

  • アプリケーションまたはサービスによって行われた問題のある、非効率的、または巨大な WMI クエリ。
  • クエリの頻度が高い。
  • Microsoft 以外の製品の干渉。
  • クエリ対象の WMI クラスに関連付けられているオブジェクト。

メモリまたはハンドル リークを調査するには、WMI サービスまたはWmiPrvse.exeプロセスのクエリとデバッグ ダンプの詳細な分析 が 必要ですが、最初のトラブルシューティング手順は、問題を絞り込んだり解決したりするのに役立ちます。

WMI クエリを実行するライフサイクルを次に示します。

  1. クライアントがクエリを送信します。
  2. WMI サービスは、クエリをタスクとして "仲裁バッファー メモリ" と呼ばれるメモリに格納します。
  3. WMI サービスは、適切な WMI プロバイダーを呼び出してクエリを実行します。
  4. WMI プロバイダーは、WMI サービスにクエリ結果を返し、その結果を仲裁バッファーに格納します。
  5. クライアントはクエリ結果を取得します。
  6. クエリと結果は、仲裁バッファーから割り当て解除されます。

WMI サービス のメモリまたはハンドル リークが発生した場合、仲裁バッファーに多すぎるタスクまたはクエリ結果が格納され、他のクエリの領域が増えなくなる可能性があります。

  • Windows Server 2016より前のバージョンのオペレーティング システム (OS) を使用している場合、WMI サービスは、他のサービスと共に共有 svchost.exe コンテナーで実行されます。
  • svchost.exe コンテナーがメモリまたはハンドルをリークしている場合は、最初に、このリークが WMI サービスまたは svchost.exe コンテナー内の他のサービスによって発生しているかどうかを判断する必要があります。

これを確認するには、次の手順に従います。

  1. コマンドを使用して、WMI サービスを独自 のsvchost.exe コンテナーに SC Config WINMGMT Type= Own 分離します。
  2. Winmgmt サービスを再起動します。
  3. コマンドには tasklist /svc 、各svchost.exeコンテナーでホストされているすべての実行中のプロセスとサービスの一覧 が 表示されます。 コマンドが正しく機能する場合は、別の分離された svchost.exe コンテナーで Winmgmt サービスが実行されていることがわかります。
  4. 引き続きメモリを監視するか、使用状況を処理します。 時間の経過と同時に増加し続け、まったく減少しない場合は、Winmgmt サービスがメモリまたはハンドルをリークしているサービスであることを意味します。 そうでない場合は、他のサービス リーク メモリまたはハンドルをホストしている別 のsvchost.exe コンテナーが表示されることがあります。
  5. 変更を元に戻すには、 コマンドを SC Config WINMGMT Type= Share 実行します。

リークは通常、問題のあるクライアントの動作または接続の問題が原因で、クエリに関連するタスク オブジェクトが適切に解放されないようにします。

問題のあるクライアントが関与しているかどうかを判断するには、リークのパターンを理解し、タスク マネージャーを確認して、特定の時間またはアプリケーションの特定のアクション中にメモリが増加するかどうかを確認する必要があります。 たとえば、Windows 更新プログラムがインストールされるたびに WMI サービスのメモリ消費量が増加します。

パフォーマンス モニター (Perfmon) を使用して、メモリ使用量を監視するか、プロセス (WMI サービスまたは WmiPrvse.exe プロセス) の数を処理するには、次の手順に従います。

  1. メモリまたはハンドルをリークしている Winmgmt サービスまたは WmiPrvse.exe プロセスを含む svchost.exe のプロセス ID (PID) に注意してください。

  2. [実行] ウィンドウに「Perfmon」と入力して、パフォーマンス モニターを開きます。

  3. 左側のウィンドウで [パフォーマンス モニター] を選択し、右側のウィンドウでプラス記号 (+) を選択して、[カウンターの追加] ウィンドウを開きます。

  4. [ プロセス] を 展開し、[ ID プロセス] を選択します。 すべての WmiPrvse# インスタンスと svchost# インスタンスを選択し、[OK の追加>]を選択します。

    すべての WmiPrvse# インスタンスと svchost# インスタンスが選択されていることを示すスクリーンショット。

  5. リスト内の各項目について、 Last、 Average、 Minimum の値が同じで、これがそのプロセスの PID であることがわかります。

    同じ Last、Average、Minimum の値を持つ項目がプロセスの PID であることを示すスクリーンショット。

  6. 一覧内のすべての項目を確認し、Winmgmt サービスの PID またはメモリまたはハンドルをリークしている プロセスWmiPrvse.exe 見つけます。 その後、正確な svchost# または WmiPrvse# インスタンスに 注意してください。

  7. リストからすべての項目を削除します。

  8. [ カウンターの追加] をもう一度選択し、[ プロセス] で [ ハンドル数]、[ プライベート バイト数]、[ スレッド数]、および [ワーキング セット] を選択します。

  9. 適切な svchost# または WmiPrvse# インスタンスを 選択し、[ 追加] を選択します。 選択したプロセスによって消費されたリソースのグラフィカルな表現が表示されます。

    WmiPrvse# インスタンスが選択されている [カウンターの追加] ウィンドウのスクリーンショット。

  10. メモリまたはハンドルの数が、特定の時間間隔または 1 日の特定の時刻、または任意のアクションで増加するかどうかを結論付けます。 リーク パターンを理解したら、メモリまたはハンドルの増加の前後の 受信クエリを分析 します。

  11. 膨大なクエリ、頻繁なクエリ、またはタスクに長く留まりすぎるクエリを探します。

    注:

    受信クエリの確認は、問題のあるクエリを実行したり、異常に動作したりする可能性がある 1 つ以上のクライアント プロセスを決定することです。

  12. 不審なクライアントが作成されたら、一時的にアンインストールまたは無効にしてから WMI サービスを再起動することでテストできます。

メモリ リークが発生しない場合は、特定されたクライアント プロセスが問題の原因です。

リポジトリの肥大化

C:\Windows\System32\wbem\Repository に格納されている WMI リポジトリのサイズを確認します。 リポジトリのサイズを理解または決定します。

  • リポジトリのサイズは、リソースとマシンの負荷、マシンにインストールされているアクティブなサービスとアプリケーション、環境 (クラスターや SQL サーバーのいずれに属しているかなど) など、複数の要因によって異なります。
  • サーバー OS の場合、正常なリポジトリ サイズは数百 MB から 1.5 GB です。 クライアント OS の場合、サイズは数百 MB です。 リポジトリは必ずしも特定のサイズに留まるわけではありません。また、書き込まれた制限はありません。
  • 通常、この記事の冒頭で説明した問題や症状がマシンで発生している場合にのみ、巨大なサイズ (1 GB を超える) が疑わしいと見なされます。
  • リポジトリのサイズが異常に大きいか、時間の経過と同時に大きくなります。 この場合、リポジトリは肥大化している可能性があります。

肥大化したリポジトリは、その正確な原因を特定するために、特殊なツールを使用して調べる必要があります。 キャプチャされたデータを含む Microsoft サポート ケースを開く場合があります。

ただし、ほとんどの場合、肥大化した WMI リポジトリは、ポリシーの結果セット (RSoP) のログ記録や、Microsoft System Center Configuration Manager (SCCM) などのアプリケーションの監視によって発生します。

RSoP ログの問題については、「 Windows または Windows Server の大きな WMI リポジトリが原因でログオンが予期せず遅くなる」を参照してください。

ソリューションを適用した後でも、WMI リポジトリをリセットしてサイズを小さくする必要があります。 Microsoft サポート プロフェッショナルからの事前のガイダンスなしで WMI リポジトリをリセットすることはお勧めしません。

上記の手順で問題を解決できない場合は、「 データ 収集」セクションで説明されているように、トレースとダンプを収集し、より深い調査のために Microsoft サポート プロフェッショナルに送信する必要があります。

WmiPrvse.exe プロセスがハンドルまたはメモリをリークしている

WmiPrvse.exe プロセスがハンドルまたはメモリをリークしている場合は、次のいずれかのケースが考えられます。

  • クライアント アプリケーションは、異常なクエリ、非効率的なクエリ、または大規模なクエリを実行します。
  • WmiPrvse.exe プロセスでは、WMI クエリの処理中にリソースが期待どおりに解放されないため、メモリ リークが発生し、WmiPrvse.exe プロセスが停止します。
  • 機械または環境のセットアップの規模は大きいです。

このような場合は、「シナリオ ガイド: 問題またはシナリオを超える WmiPrvse.exe クォータのトラブルシューティング」を参照してください。

データ収集

さらに調査するためのサポート ケースを開くには、「 TSS for User Experience の問題を使用するか 、最近問題が発生したコンピューターで WMI-Collect ツールを使用して情報を収集する」で説明されている手順に従って情報を収集できます。 それらのステップは次のとおりです。

  1. WMI-Collect.zip をダウンロードし、C:\temp などのフォルダーに展開します。

  2. 管理者特権の PowerShell コマンド プロンプトから、スクリプトが保存されているフォルダーから WMI-Collect.ps1 スクリプトを実行します。 例:

    C:\temp\WMI-Collect.ps1 -Logs

  3. PowerShell コマンド プロンプトを開いたままにし、"Enter キーを押してキャプチャを停止します:" というメッセージを表示します。

  4. スクリプトは、すべてのトレースの結果と診断情報を含むサブフォルダーを作成します。 フォルダーを圧縮します。 サポート ケースが作成されると、このファイルをセキュリティで保護されたワークスペースにアップロードして分析できます。