私は通常ラップトップを24時間年中無休で保管していますが、1日の終わりに過熱して太ももが焼けてしまうのは本当に迷惑です。

オーバーヒートは、WMIプロバイダーホスト（WmiPrvSE.exe）がCPU使用率を数分ごとに25％に急上昇させた結果と思われます。なぜこれが起こるのですか？

Windows 7 Home Premiumで実行されているHP Envy 14（HPにバンドルされたがらくた）があります。

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

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

Sathyaが質問で言及したように、私は同様のHPラップトップでこの問題を以前に経験しており、HPラップトップのCPUスパイクがHP Wireless Assistantによって引き起こされることを科学的方法を使用して確認しました。または、HP CPU Assassin、私はそれを呼び出し始めるかもしれません。

実験の概要

• 質問：HPラップトップのCPUが頻繁に、特に プロセスで急増する原因は何WmiPrvSE.exe ですか？

• 仮説：HP Wireless Assistant（HPWA）が問題の原因です

• 方法：

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

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

• 結論：HPWAは何も役に立たないのでアンインストールする必要があります

背景情報

HP Pavillion dm4tラップトップを手に入れたとき、CPUの使用率が1秒おきに50％に達することがよくあることに気付きました。これはバッテリー寿命を消耗させ、ラップトップを加熱していました。サティアが経験したのとほぼ同じ症状。Windows 7のリソースモニターを見るだけで、プロセスに問題があることがわかりましたWmiPrvSE.exe。

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

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

残念ながら、どのプロセスがすべてのクエリを作成しているかを知る方法がわかりませんでしたが、これをCPUスパイクのソースとして分離し、それがサービスであることがわかっていたので、サービスマネージャーに行って、サービスはWMIに依存していたので、別の手がかりになるかもしれないと考えていました。

私はそれが問題を引き起こすビルトインのWindowsサービスではないだろうと思ったので、それらを排除して、私はリストを調べて、各サービスを無効にして、問題が持続するかどうか確かめることに決めました。リストのすぐ上にHPワイヤレスアシスタントサービスがありました。サービスメニューに戻り、そのサービスを無効にしました。タスクマネージャーを振り返ると、CPU使用率がほとんどゼロになっていることがわかりました。HPWAサービスに戻ります。CPU使用率が急上昇しました。理論を形成するのに十分なデータが得られました。HPWAサービスをアンインストールしましたが、二度と問題はありませんでした。

仮説の検証

数ヶ月後、サティアはこの質問をします。私はこれがHPWAのせいであることを一度だけ証明することにしました。HP Wireless Assistantを再インストールしましたが、これは何ヶ月もインストールしていませんでした。すぐに、プロセッサの使用量が急増しました。その後、上記の実験を実施しました。

最初に、リソースモニターでHPWAサービスを担当するプロセスを分離しました。HPWA_Service.exeそしてHPWA_Main.exe2つです。これらの処理された両方の実行でのCPU使用率は次のとおりです。

次に、両方のプロセスを中断しました。CPU使用率はすぐに低下しました。グラフ上の以前のCPU使用率がクリアされるまでしばらくしてから、次のようになりました。

プロセスを再度有効にして、使用量が回復するかどうかを確認しました。やった：

^{HPWAを有効にしたときの最初のスパイク}

^{HPWAを有効にした少し後}

プロセスを再度中断すると、CPU使用率が低下します。

これをもう1回繰り返してテストしましたが、3回目の試行で、まったく同じことが再び起こりました。この十分な証拠を考慮して、HPワイヤレスアシスタントが問題を引き起こしていることを示し、その後サービスを無効にしてから、アンインストールします。

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

注： HPWAをアンインストールすると、キーボードのワイヤレススイッチが機能しなくなることが少なくとも1人から報告されています。私のラップトップでは、HPWAをアンインストールした後も正常に動作しましたが、動作が停止した場合は、Windows内からいつでもワイヤレスカードを無効にできます。+ xを押してWindowsモビリティセンターを開き、Turn Wireless Offボタンをクリックします。

HPサポートフォーラムでの議論によると、この問題はHP Wireless Assistantの最新バージョンで修正されています。ラップトップでHPWAがwifiオン/オフボタンを使用する必要がある場合は、HPのドライバーWebサイトから最新バージョンをダウンロードできます。おそらく、この問題はもう発生しません。それでも、wifiのオン/オフボタンに必要ない場合、このソフトウェアをインストールしても付加価値はないようです。

トラブルシューティング

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

2. WmiPrvSE.EXEが1秒間25％に達したら、ダンプを取得します。

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

   これにより、ユーザーフォルダーにダンプが作成されます。

   これをさらに1-2回繰り返して、より多くのダンプが得られるようにしてください。これにより、通常のイベントではなく、原因がダンプされたことを確認できます。

3. ダンプをオンラインで分析し、オプションでSpeedyShareで共有します。

   代替：コマンドでWinDBGを使用できます。!analyze -v必ずシンボルを設定してください。

4. 表示されるスタックトレースには、これを引き起こす手順を含める必要があります。

おそらく、スタックの上位の手順のいくつかをグーグルで調べて、それらが何をするのかをよりよく理解してください。
役に立たない場合は、より高度な分析が必要になる場合があります。次のセクションをご覧ください。

1. ご使用のWindowsバージョンのWindowsパフォーマンス分析ツールからセットアップをダウンロードします。
2. システムにソフトウェアをインストールします。

3. 管理者としてコマンドプロンプトを開き、次のコマンドをコピーして貼り付けます。

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

4. ENTER 一度押してコマンドを開始します。スパイクが発生するまで待つ必要があります。

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

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

   xperf %HOMEPATH%\myTrace.etl
   

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

8. ユーザーフォルダのmyTrace.etlをzipファイルに圧縮します。
9. SpeedyShareで圧縮されたzipファイルを共有します。
10. ここでリンクを共有してください、私はあなたの問題の原因を見つけて見せようと試みます。

Wmiprvse.exeは、CAPIストアに対してWMIクエリを実行するためのホストであるとして、あなたが原因にさえXperfはして原因を見つけることができない場合がありますIPC、私はちょうど見つけた別の解決策は、WMIのログを有効にするだろうとログをチェックしますここで説明するように、ClientProcessIdは、WMIクエリを作成したプロセスのPIDです。このPIDは、タスクマネージャーまたはプロセスエクスプローラーにPID列を追加することにより、またはtasklist /FI "PID eq X"Xが見つかったPIDである場合に、プロセスまで追跡できます...

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

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

ダンプは一瞬のキャプチャであるため、RPCを実行したプロセスを確認することはできません。
したがって、RPCを実行する以前のスレッドを表示するには、XPerfのようなトレースを行うプログラムが必要です。

または、RPC State Informationを有効にすると、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状態情報に関する情報がたくさんありますが、XPerfを代わりに使用できる場合に、私たちのような気弱な人がすべてを経験することはできません。:-)

RPCがどのように機能するかについての内部の仕組みについて理解したので、API Monitorを使用することもできます。

1. API Monitorをダウンロード、インストール、起動します。_{（64ビットの場合は2回：1回x86、1回x64）}
2. ファイルに移動-> 管理者として実行

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

   

4. ブレークポイントと同様に、RpcServerUseProtSeq関数を呼び出す人を知りたい：

   

5. （クラッシュを防ぐために）PIDが低いプロセスを除き、実行中の各プロセスをフックします。
   理想的には、フックしたくないdwm.exe/ winlogon.exeまたはより低いです。
   また、単一のプロセスを試して、後で「フックされたプロセス」ウィンドウからそれらをアンフックすることもできます...

   しかし...私はそれを試してみましたが、どんなプロセスにも夢中になります。

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

解決

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

MicrosoftブログエントリWMIprvseは本当の悪役ですか？WmiPrvSE.exeが使用しているCPUを担当するプロセスを見つける方法を示します。

このメソッドは、「分析ログとデバッグログを表示する」のイベントビューアーオプションを使用して、すべてのWMIアクティビティをトレースし、有罪プロセスのプロセスIDを取得します。

同じボートに乗っている他の人にこれを追加するだけで、このページはGoogle全体に表示されます。Windows 8.1のLenovo Yoga2 ProでWmiProvderHostがCPUを最大50％スパイクし、バッテリーを消耗するという同じ問題がありました。

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

デバッグするには、Windowsパフォーマンスツールキットの 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を開き、「ジェネリックイベント」グラフを左側から分析ペインにドラッグアンドドロップします。

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

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

2番目の例を次に示します。

Intel ProSet Monitoringサービスに属する1924のPIDを持つプロセスの呼び出しが繰り返し発生しているのを確認できます。

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

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

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

それ以外に、TomWijからの他の答えは、トラブルシューティングに非常に良いようです！