web-dev-qa-db-ja.com

WMIプロバイダホスト（WmiPrvSE.exe）が私のCPUを急上昇させ続けるのはなぜですか？

私は一般的に私のラップトップを24時間年中無休の状態に保っています、そして一日の終わりには過熱のために私の太ももを焼くのは本当に厄介です。

過熱は、WMI Provider Host（WmiPrvSE.exe）が数分ごとにCPU使用率を25％に急上昇させたためと考えられます。なぜこれが起こるのですか？

私は、Windows 7 Home Premiumで実行されているHP Envy 14（HPが付属のがらくた付き）を持っています。

（注：@ nhinkleの 過去の観測 に基づくと、HP Wireless Managerが原因である可能性があります。確認する方法はありますかこれ？）

この質問は今週のスーパーユーザー質問でした。
2011年2月28日ブログのエントリを読むか、 /] 自分の今週の質問を送信してください。

windows-7processwmihp-envy
85
Sathyajith Bhat

Sathyaが彼の質問で述べたように、私は私の同じようなHPラップトップの上でこの問題に関する以前の経験をしました、そして私は今HPラップトップのCPUスパイクがHP Wireless Assistantによって引き起こされるという科学的方法を使って確認しました。または、HP CPU Assassinを呼び出します。

実験の概要

  • 質問：HPラップトップのCPUが頻繁に急上昇している原因、特にWmiPrvSE.exe処理しますか？

  • 仮説：HPワイヤレスアシスタント（HPWA）が問題を引き起こしています

  • 方法：

    1. HPWAのインストール時に問題が発生し始めるかどうかを確認してください。
    2. HPWAプロセスが中断されたときに、CPUがスパイクを停止し、WmiPrvSE.exeプロセスが20％を超えるCPUの使用を停止するかどうかを確認します。
    3. HPWAプロセスが再び有効になったときに、CPUが再びスパイクを開始するかどうかを確認します。
    4. 正確な結果を確実にするために、複数の試行についてステップ2と3を繰り返します。

  • 結果：HPWAが極端なCPU使用率を引き起こしています

  • 結論：HPWAはアンインストールしても役に立ちません。

背景情報

私のHP Pavillion dm4tラップトップを手に入れたとき、私はCPUが頻繁に50％もの使用率まで、ほぼ一秒おきに急上昇することに気づいた。これはバッテリーの寿命を浪費させ、ラップトップを暖めていました。 Sathyaが経験したのとほとんど同じ症状。 Windows 7のリソースモニタを見るだけで、プロセスWmiPrvSE.exeに問題があることがわかりました。

cpu nom nom

簡単なGoogle検索の結果、これは Windows Management Instrumentation （WMI）Hostプロセスであると推測されました。つまり、WMIを使用して、プロセッサの使用状況、実行中のプロセス、ログオンしているユーザー、その他あらゆる種類の情報などのシステム情報を照会できます。 WMIホストプロセスは、それらを作成する他のプロセスに対してWMIクエリを実行します。したがって、WmiPrvSE.exeはそれ自体が原因ではなく、単に仲介者でした。

どの特定のプロセスがこの問題を引き起こしているかを突き止めるために、私は Systinternals Process Explorer を使いました。私は、どのインスタンスのWmiPrvSE.exeプロセスが大量のCPUを使用しているのかを見つけ、それをクリックして詳細な情報を開きました。

process Explorer

残念ながら、どのプロセスがすべてのクエリを実行しているのかを突き止める方法はありませんでしたが、これをCPUスパイクの原因として特定し、サービスであることがわかっていたので、サービスマネージャにアクセスしました。サービスはWMIに依存しており、それが私を別の手がかりに導いてくれるかもしれないと考えていました。

services nom nom

私はそれが問題の原因となっている組み込みのWindowsサービスではないことを考え出した、それでそれらを排除して、私はリストを下にして各サービスを無効にして問題が解決するかどうか見ることに決めた。リストの一番上にあるのが、HP Wireless Assistant Serviceです。サービスメニューに戻り、そのサービスを無効にしました。タスクマネージャを振り返ってみると、CPU使用率がほとんどないことがわかりました。私はHPWAサービスに戻りました。 CPU使用率が回復しました。私は今私の理論を形作るのに十分なデータを持っていた。私はHPWAサービスをアンインストールし、そして二度と問題を抱えていなかった。

仮説の検証

数ヵ月後、Sathyaはこの質問をします。私はこれがHPWAのせいであることを一度限り証明することにしました。私は数ヶ月でインストールしていなかったHP Wireless Assistantを再インストールしました。すぐに、プロセッサ使用率は急上昇しました。それから私は上で概説した実験を経験しました。

まず、HPWAサービスを担当するプロセスをリソースモニターで分離しました。 HPWA_Service.exeとHPWA_Main.exeは2つです。これら両方の処理された実行でCPU使用率がどのように見えたかはここにあります：

task manager with hpwa running

その後、両方のプロセスを中断しました。 CPU使用率はすぐに低下しました。グラフ上の前回のCPU使用率を確認するためにしばらくして、次のようになりました。

task manager without hpwa running

使用状況が回復するかどうかを確認するために、プロセスを再度有効にしました。それはしました：

task manager just enabled hpwa
HPWAを有効にしたときの最初の急上昇

task manager after enabling hpwa
HPWAを有効にしてからしばらくして

プロセスを再び一時停止すると、CPU使用率は元に戻ります。

lower cpu usage after disabling hpwa

もう1回繰り返してテストしましたが、3回目の試行でも、まったく同じことが起こりました。私はこの十分な証拠を考慮して、HPワイヤレスアシスタントが問題の原因であり、その後サービスを無効にしたため、アンインストールします。

HPWAがしているように見えるのは、ワイヤレスがオンまたはオフになったときにユーザーに通知し、CPUを奪うことだけです。内蔵のワイヤレス管理ツールではできないことができることは何もないので、このソフトウェアをインストールしている場合は削除することをお勧めします。

注：少なくとも1人が、HPWAをアンインストールするとキーボードのワイヤレススイッチが機能しなくなったと報告しています。私のラップトップでは、HPWAをアンインストールした後も問題なく動作していましたが、あなたが動かなくなってしまった場合は、いつでもWindowsの中からワイヤレスカードを無効にすることができます。押す Winkey+x Windows Mobility Centerを開くには、Turn Wireless Offボタンをクリックします。

windows mobility center

HPサポートフォーラムの ディスカッション によると、この問題はHPワイヤレスアシスタントの最新バージョンで修正されています。あなたのラップトップがwifiのオン/オフボタンを使うのにHPWAを必要とするなら、あなたはHPのドライバのウェブサイトから最新バージョンをダウンロードすることができ、おそらくもうこれ以上問題はないでしょう。それにもかかわらず、あなたが無線LANのオン/オフボタンのためにそれを必要としない場合、それでもこのソフトウェアをインストールしておくことによる付加価値はないようです。

108
nhinkle

トラブルシューティング

  1. Microsoft Sysinternalsから ProcDump をダウンロードします。

  2. WmiPrvSE.EXEが1秒間で25％に達すると、ダンプを取ります。

    procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp

    これはあなたのUserフォルダにダンプを作成します。

    これを1〜2回繰り返して自由に繰り返して、より多くのダンプを作成し、原因が確実にダンプされ、他の通常のイベントではないことを確認できます。

  3. ダンプを分析して{ online }、必要に応じて SpeedyShare で共有します。

    Alternative： WinDBG は、コマンド!analyze -vと共に使用できます。必ず set symbols を使用してください。

  4. 表示されるスタックトレースはこれを引き起こすプロシージャを含むはずです。

おそらく、スタックの最上位手順のいくつかをグーグルして、それらが何をするのかをよりよく理解するようにします。
それらが役に立たない場合は、もっと高度な分析が必要かもしれません。次のセクションを見てください。

  1. ご使用のWindowsバージョン用のセットアップを Windows Performance Analysis Tools からダウンロードします。
  2. システムにソフトウェアをインストールしてください。

  3. コマンドPromptをadministratorとして開き、次のコマンドをコピーして貼り付けます。

    xperf -start perf!GeneralProfiles.InBuffer -stackwalk profile && timeout -1 && xperf -stop perf!GeneralProfiles.InBuffer %HOMEPATH%\myTrace.etl

  4. 押す ENTER onceコマンドを起動するには、スパイクが発生するまで待つ必要があります。

  5. スパイクのすぐ後にコンソールに行き、を押します。 ENTER。
  6. しばらく待ってから、ログファイルmyTrace.etlがユーザーフォルダに作成されます。

  7. 次のコマンドを実行してファイルを表示し、分析します（ WinDBG / Symbols 必須）。

    xperf %HOMEPATH%\myTrace.etl

あなたが私にそれを調べて欲しいなら：

  1. MyTrace.etlをユーザーフォルダからZipファイルに圧縮します。
  2. 圧縮されたZipファイルを SpeedyShare で共有します。
  3. ここでリンクを共有してください、私はあなたにあなたの問題の原因を見つけて見せる試みをします。

WmiPrvSE.EXEはCAPIストアに対してWMIクエリを実行するためのホストであるため、 IPC のためXPerfを使用しても原因を特定できない可能性があります。 here の説明に従ってWMIのログ記録とログのチェックを有効にするには、ClientProcessIdをWMIクエリを作成したプロセスのPIDにします。このPIDは、PID列をタスクマネージャまたは Process Explorer に追加するか、tasklist /FI "PID eq X"を使用してプロセスに追跡することができます。ここで、Xは見つけたPIDです。

ダンプ1 の分析：行94-115は リモートプロシージャコール を示します。
ダンプ2 の分析：行84-105は リモートプロシージャコール を示します。

カーネルでは、新しいスレッドが開始されます Remote Procedure Callスタブを処理するため 、これは本質的にはWMIプロバイダが実行して応答するクエリ要求です。これにより、レジストリやパフォーマンスの情報が読み取られるため、CPU使用率が高くなります。

ダンプは一瞬のキャプチャなので、どのプロセスがRPCを実行したのかわかりません。
そのため、RPCを実行している前のスレッドを確認するには、XPerfのようにトレースするプログラムが必要です。

または、{ RPC状態情報を有効にする _の場合は、 rpcdbg _を使用して誰が呼び出しを開始したかを確認できます。

例：

0:000> bp rpcrt4!RpcServerUseProtseqEpA
0:000> g
Breakpoint 0 hit
eax=00452000 ebx=7ffd5000 ecx=00452008 edx=00000014 esi=00d5f55c edi=7c911970
eip=77e97a0b esp=0012ff3c ebp=0012ff6c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
RPCRT4!RpcServerUseProtseqEpA:
77e97a0b 8bff mov edi,edi
0:000> kb
ChildEBP RetAddr Args to Child
0012ff38 00401046 00452000 00000014 00452008 RPCRT4!RpcServerUseProtseqEpA
0012ff6c 00401e37 00000001 003330a0 00333120 hellos!main+0x46 [e:\projects\hello\hellos.c @ 21]

上記の例ではRPCにブレークポイントを設定しているので、スタックの2行目で誰がそれを実行しているかがわかります。しかし、最初の呼び出しでブレークポイントを設定すると（これはライブデバッグであることに注意してください）、毎回誰がWMIプロバイダを呼び出すのかを確認するのに役立つことはほとんどありません。

その記事には RPC State Information についてもっと多くの情報があるかもしれませんが、代わりにXPerfを使うことができたときに私たちのような気が遠くなるのを通過するのはそれだけではありません。 :-)

RPCがどのように機能するかについての内部の動作についてはわかったので、 API Monitor を使用することもできます。

  1. API Monitorをダウンロード、インストール、および起動します。 （twice64ビットの場合：x86 1回、x64 1回）
  2. File - >管理者として実行に移動します。

  3. APIキャプチャフィルタをRpcrt4.dllモジュールに設定します。

    enter image description here

  4. ブレークポイントと同様に、誰がRpcServerUseProtSeq関数を呼び出すのかを知りたいです。

    enter image description here

  5. （クラッシュを防ぐために）PIDが小さいものを除いて、各実行中のプロセスをフックします。
    理想的には、dwm.exe/winlogon.exe以下をフックしたくはありません。
    また、単一のプロセスを試して、後でHooked Processesウィンドウからフック解除することもできます。

    しかし...私はそれを試してみたし、任意のプロセスについてフックすることができます。

  6. すべてうまくいけば、RPC呼び出しを行うフックプロセスにスレッドが含まれます。
    そして、これらのスレッドをクリックすると、たくさんの呼び出しが表示されるはずです。
    そうした場合、問題の原因となっているプロセスが見つかりました。

溶液

コンピュータを常に最新の状態に保つことが重要です。 HPWA 4.0.10. をインストールすると解決できます！;-)

38
Tamara Wijsman

マイクロソフトのブログエントリWMIprvseは本当の悪役ですか？ WmiPrvSE.exeが使用しているCPU。

このメソッドは、[Show Analytic and Debug Logs]の[Event viewer]オプションを使用してすべてのWMIアクティビティを追跡し、それによって有罪プロセスのprocess-idを取得します。

13
harrymc

同じ船に乗っている誰かにこれを付け加えるだけで、このページはグーグルのいたるところにある。 Windows 8.1上のLenovo Yoga 2 Proで、WmiProvderHostが最大50％のCPUのスパイクとバッテリーの消耗を起こしても、同じ問題が発生しました。

上記の優れた調査アドバイスに従って、私の問題は実際にGoPro Studio（GoProカメラに付属の無料のビデオ編集ソフトウェア）であることがわかりました。それはあなたがあなたのカメラを接続するのを待つ監視サービスをインストールします、そして私にとってこれは原因でした。

7
DannyT

デバッグするには、 Windows Performanceツールキット のxperfを使用して、次のcmdファイルを実行します。

xperf -on PROC_THREAD+LOADER+PROFILE+INTERRUPT+DPC+DISPATCHER -stackwalk profile -BufferSize 1024 -MaxFile 256 -FileMode Circular -f Kernel.etl
xperf -start WMILogger -on Microsoft-Windows-WMI-Activity::0xff -BufferSize 1024 -f WMI.etl

echo Please capture about 30s of the WMI activity.

pause

xperf -stop
xperf -stop WMILogger
xperf -merge WMI.etl kernel.etl WMItracing.etl

del WMI.etl
del kernel.etl

WPA.exeで生成されたWMItracing.etlを開き、左側から[Generic Events]グラフを分析ウィンドウにグラムアンドドロップします。

enter image description here

今すぐMicrosoft-Windows-WMI-Activityイベントのみにフィルタをかけ、WMI操作とClientProcessIdを探します。

私の例では、このCLientProcessIdはVeeam ONE Monitor Serverというツールに属しています。 停止すると、CPU使用率の問題が修正されました 。

そして、2番目の例がここに示されています。

enter image description here

Intel ProSet Monitoringサービスに属するPIDが1924のProcessの呼び出しが繰り返し発生します。

ここでは、CPU使用率もCPUサンプリングコールスタックに表示されています。

enter image description here

そのため、IntelツールはWMI通知クエリを頻繁に実行し、これが問題を引き起こします。 停止して問題を修正しました。

4
magicandre1981

ウイルスかどうか見てみましたか。一部のウイルスは、Windowsサービスがそのようなものとしてパレードするのを本当に好みます。 WmiPrvSE.exeプロセスがc:\windows\system32\wbemディレクトリにあることを確認してください。そうでない場合は、一般的なスパイウェア検出プログラムを実行することをお勧めします。スパイウェアでなければ、それを呼び出している別のサービスかもしれません。コンピュータ上でいくつかのガジェットをすばやく実行していることを知っていますが、皮肉なことにパフォーマンスモニタのガジェットでCPUが少し急増することがあります。また、それは時々そのガスを押す別のサービスかもしれません。たとえば、HP、Dellなどのブロートウェアです。

それ以外に、TomWijからの他の答えはそれを解決するためにかなりいいようです！

1
Duall