次の方法で共有

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

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

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

  • マシンの実行速度が遅くなります。
  • tasklistやmsinfo32.exeを開く、compmgmt.mscなどのコマンドを実行すると、応答に時間がかかるか、適切な結果が表示されません。
  • 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. SC Config WINMGMT Type= Own コマンドを使用して、WMI サービスを独自のsvchost.exe コンテナーに分離します。
  2. Winmgmt サービスを再起動します。
  3. tasklist /svc コマンドには、各svchost.exe コンテナーでホストされているすべての実行中のプロセスとサービスの一覧が表示されます。 コマンドが正常に動作する場合は、Winmgmt サービスが別の分離された svchost.exe コンテナーで実行されていることがわかります。
  4. メモリの監視または使用状況の処理を続行します。 時間の経過とともに増加し続け、まったく減少しない場合は、Winmgmt サービスがメモリまたはハンドルをリークしているサービスであることを意味します。 そうでない場合は、他のサービス リーク メモリまたはハンドルをホストしている別の svchost.exe コンテナーが表示されることがあります。
  5. 変更を元に戻すには、 SC Config WINMGMT Type= Share コマンドを実行します。

リークは通常、問題のあるクライアントの動作または接続の問題が原因で発生するため、クエリに関連するタスク オブジェクトが正しく解放されません。

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

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

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

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

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

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

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

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

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

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

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

  8. もう一度 カウンターの追加 を選択し、 Process で Handle Count、 Private Bytes、 Thread Count、および Working Set を選択します。

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

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

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

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

    Note

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

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

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

リポジトリの肥大化

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

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

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

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

RSoP ログの問題については、「 Windows または Windows Server の大きな WMI リポジトリによって引き起こされるログオンが遅くなるを参照してください。

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

上記の手順で問題を解決できない場合は、「 Data コレクション 」セクションで説明されているように、トレースとダンプを収集し、Microsoft サポート担当者に送信して詳細な調査を行う必要があります。

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

WmiPrvse.exe プロセスがハンドルまたはメモリをリークしている場合は、次のいずれかのケースが発生する可能性があります。

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

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

データ コレクション

詳細な調査のためにサポート ケースを開くには、 Gather 情報に記載されている手順に従って、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. スクリプトは、すべてのトレースの結果と診断情報を含むサブフォルダーを作成します。 フォルダーを圧縮します。 サポート ケースが作成されたら、このファイルをセキュリティで保護されたワークスペースにアップロードして分析できます。