トラブルシューティング

Question 1

Sathya が質問で述べたように、私も以前、同様の HP ラップトップでこの問題を経験したことがあり、科学的手法を使用して、HP ラップトップの CPU スパイクの原因が HP ワイヤレスアシスタントであることを確認しました。または、HP CPU アサシンとでも呼ぶかもしれません。

実験の概要

質問:HPのノートパソコンのCPUが頻繁に急上昇する原因は何でしょうか？具体的には WmiPrvSE.exe プロセス？
仮説:HPワイヤレスアシスタント（HPWA）が問題の原因です
方法:
1. HPWA をインストールすると問題が発生するかどうかを確認します。
2. WmiPrvSE.exeHPWA プロセスが一時停止されたときに、CPU のスパイクが停止し、プロセスが 20% を超える CPU の使用を停止するかどうかを確認します。
3. HPWAプロセスが再度有効になったときにCPUが再び急上昇し始めるかどうかを確認します。
4. 結果の正確性を確保するために、手順2と3を複数回繰り返します。
結果:HPWA は CPU 使用率を極端に高めます
結論:HPWAは役に立たないのでアンインストールすべきです

背景情報

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

CPU 公称値

グーグルでちょっと検索してみると、これがWindows 管理インストルメンテーション(WMI) ホストプロセス。簡単に言うと、WMI は、プロセッサの使用状況、実行中のプロセス、ログオンしているユーザー、その他さまざまな情報などのシステム情報を照会するために使用できます。WMI ホストプロセスは、他のプロセスが WMI クエリを実行するため、それWmiPrvSE.exe自体が原因ではなく、単に仲介役です。

この問題を引き起こしている特定のプロセスを追跡するために、私はSystinternals プロセスエクスプローラーWmiPrvSE.exeプロセスのどのインスタンスが大量の CPU を使用しているかを確認し、それをクリックして詳細情報を開きました。

プロセスエクスプローラー

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

サービス nom nom

問題の原因は Windows の組み込みサービスではないと考えたので、それらのサービスを排除し、リストの上から順に各サービスを無効にして、問題が解消されるかどうか確認してみることにしました。リストの一番上には HP Wireless Assistant Service がありました。サービスメニューに戻り、そのサービスを無効にしました。タスクマネージャーで確認すると、CPU 使用率がほとんどなくなっていました。HPWA サービスを再びオンにすると、CPU 使用率が再び上昇しました。これで、仮説を立てるのに十分なデータが得られました。HPWA サービスをアンインストールすると、問題は再び発生しなくなりました。

仮説の検証

数か月後、Sathya がこの質問をしました。私は、これが HPWA のせいであることを最終的に証明することにしました。数か月間インストールしていなかった HP Wireless Assistant を再インストールしました。するとすぐに、プロセッサの使用率が急上昇しました。そこで、上記の実験を実行しました。

まず、リソースモニターで HPWA サービスを担当するプロセスを分離しました。HPWA_Service.exeとHPWA_Main.exeの 2 つです。これら 2 つのプロセスを実行した場合の CPU 使用率は次のとおりです。

hpwa が動作しているタスクマネージャー

次に、両方のプロセスを一時停止しました。CPU 使用率はすぐに下がりました。グラフ上の以前の CPU 使用率がクリアされるまで数分かかると、次のようになります。

HPWA を実行せずにタスクマネージャーを実行する

プロセスを再度有効にして、使用量が再び増加するかどうかを確認しました。結果は次のようになりました。

タスクマネージャーがHPWAを有効にしました
^{HPWAを有効にしたときの最初のスパイク}

HPWA を有効にした後のタスクマネージャー
^{HPWAを有効にしてからしばらくして}

プロセスを再度一時停止すると、CPU 使用率が再び低下しました。

hpwa を無効にした後の CPU 使用率の低下

これをもう一度繰り返してテストしたところ、3 回目の試行でまったく同じことが再び発生しました。これは、HP Wireless Assistant が問題の原因であることを示す十分な証拠であると判断し、サービスを無効にし、アンインストールすることにしました。

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

注記：HPWA をアンインストールするとキーボードのワイヤレススイッチが機能しなくなるという報告が少なくとも 1 件あります。私のノート PC では、HPWA をアンインストールした後も問題なく機能していましたが、お使いのノート PC が機能しなくなった場合は、いつでも Windows 内からワイヤレスカードを無効にすることができます。+を押しxて Windows モビリティセンターを開き、Turn Wireless Offボタンをクリックします。

Windows モビリティセンター

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

Answer

Sathya が質問で述べたように、私も以前、同様の HP ラップトップでこの問題を経験したことがあり、科学的手法を使用して、HP ラップトップの CPU スパイクの原因が HP ワイヤレスアシスタントであることを確認しました。または、HP CPU アサシンとでも呼ぶかもしれません。

実験の概要

質問:HPのノートパソコンのCPUが頻繁に急上昇する原因は何でしょうか？具体的には WmiPrvSE.exe プロセス？
仮説:HPワイヤレスアシスタント（HPWA）が問題の原因です
方法:
1. HPWA をインストールすると問題が発生するかどうかを確認します。
2. WmiPrvSE.exeHPWA プロセスが一時停止されたときに、CPU のスパイクが停止し、プロセスが 20% を超える CPU の使用を停止するかどうかを確認します。
3. HPWAプロセスが再度有効になったときにCPUが再び急上昇し始めるかどうかを確認します。
4. 結果の正確性を確保するために、手順2と3を複数回繰り返します。
結果:HPWA は CPU 使用率を極端に高めます
結論:HPWAは役に立たないのでアンインストールすべきです

背景情報

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

CPU 公称値

グーグルでちょっと検索してみると、これがWindows 管理インストルメンテーション(WMI) ホストプロセス。簡単に言うと、WMI は、プロセッサの使用状況、実行中のプロセス、ログオンしているユーザー、その他さまざまな情報などのシステム情報を照会するために使用できます。WMI ホストプロセスは、他のプロセスが WMI クエリを実行するため、それWmiPrvSE.exe自体が原因ではなく、単に仲介役です。

この問題を引き起こしている特定のプロセスを追跡するために、私はSystinternals プロセスエクスプローラーWmiPrvSE.exeプロセスのどのインスタンスが大量の CPU を使用しているかを確認し、それをクリックして詳細情報を開きました。

プロセスエクスプローラー

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

サービス nom nom

問題の原因は Windows の組み込みサービスではないと考えたので、それらのサービスを排除し、リストの上から順に各サービスを無効にして、問題が解消されるかどうか確認してみることにしました。リストの一番上には HP Wireless Assistant Service がありました。サービスメニューに戻り、そのサービスを無効にしました。タスクマネージャーで確認すると、CPU 使用率がほとんどなくなっていました。HPWA サービスを再びオンにすると、CPU 使用率が再び上昇しました。これで、仮説を立てるのに十分なデータが得られました。HPWA サービスをアンインストールすると、問題は再び発生しなくなりました。

仮説の検証

数か月後、Sathya がこの質問をしました。私は、これが HPWA のせいであることを最終的に証明することにしました。数か月間インストールしていなかった HP Wireless Assistant を再インストールしました。するとすぐに、プロセッサの使用率が急上昇しました。そこで、上記の実験を実行しました。

まず、リソースモニターで HPWA サービスを担当するプロセスを分離しました。HPWA_Service.exeとHPWA_Main.exeの 2 つです。これら 2 つのプロセスを実行した場合の CPU 使用率は次のとおりです。

hpwa が動作しているタスクマネージャー

次に、両方のプロセスを一時停止しました。CPU 使用率はすぐに下がりました。グラフ上の以前の CPU 使用率がクリアされるまで数分かかると、次のようになります。

HPWA を実行せずにタスクマネージャーを実行する

プロセスを再度有効にして、使用量が再び増加するかどうかを確認しました。結果は次のようになりました。

タスクマネージャーがHPWAを有効にしました
^{HPWAを有効にしたときの最初のスパイク}

HPWA を有効にした後のタスクマネージャー
^{HPWAを有効にしてからしばらくして}

プロセスを再度一時停止すると、CPU 使用率が再び低下しました。

hpwa を無効にした後の CPU 使用率の低下

これをもう一度繰り返してテストしたところ、3 回目の試行でまったく同じことが再び発生しました。これは、HP Wireless Assistant が問題の原因であることを示す十分な証拠であると判断し、サービスを無効にし、アンインストールすることにしました。

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

注記：HPWA をアンインストールするとキーボードのワイヤレススイッチが機能しなくなるという報告が少なくとも 1 件あります。私のノート PC では、HPWA をアンインストールした後も問題なく機能していましたが、お使いのノート PC が機能しなくなった場合は、いつでも Windows 内からワイヤレスカードを無効にすることができます。+を押しxて Windows モビリティセンターを開き、Turn Wireless Offボタンをクリックします。

Windows モビリティセンター

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

Question 2

トラブルシューティング

ダウンロードプロセスダンプMicrosoft Sysinternals より。
WmiPrvSE.EXE が 1 秒間 25% に達したらダンプを実行します。
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
これにより、ユーザーフォルダーにダンプが作成されます。

これをあと 1 ～ 2 回繰り返して、ダンプをさらに取得し、原因がダンプであり、別の通常のイベントではないことを確認できます。
ダンプを分析するオンラインそしてオプションで共有するスピーディーシェア。

代替:ウィンDBGコマンドと一緒に使用できる場合は!analyze -v、必ずシンボルを設定する。
表示されるスタックトレースに、この問題の原因となる手順が含まれている必要があります。

おそらく、スタックのトッププロシージャのいくつかを Google で検索して、それらが何をするのかをよりよく理解してください。
役に立たない場合は、より高度な分析が必要になる可能性があります。次のセクションを参照してください。

セットアップをダウンロードするにはWindows パフォーマンス分析ツールWindows バージョン用。
システムにソフトウェアをインストールします。

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

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

プレスENTER 一度コマンドを開始するには、スパイクが発生するまで待つ必要があります。
スパイクの直後コンソールに移動してを押しますENTER。
しばらく待つと、ユーザーフォルダーにログファイル myTrace.etl が生成されます。
次のコマンドを実行してファイルを表示し、分析します（ウィンDBG/シンボル必須）：
```
xperf %HOMEPATH%\myTrace.etl
```

調べて欲しい場合は:

ユーザーフォルダーから myTrace.etl を zip ファイルに圧縮します。
圧縮されたzipファイルを共有するスピーディーシェア。
ここでリンクを共有してください。問題の原因を見つけて示すように努めます。

WmiPrvSE.EXEはCAPIストアに対してWMIクエリを実行するためのホストであるため、XPerfを使用しても原因が見つからない場合があります。国際PC私が見つけたもう一つの解決策は、WMIログを有効にして、説明されているようにログを確認することです。ここClientProcessIdはWMIクエリを作成したプロセスのPIDになります。このPIDは、タスクマネージャーにPID列を追加するか、プロセスエクスプローラー、または、tasklist /FI "PID eq X"X が見つかった PID である場合...

の分析ダンプ 1:94行目から115行目は、リモートプロシージャコール。
の分析ダンプ2:84行目から105行目は、リモートプロシージャコール。

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

ダンプは 1 つの瞬間をキャプチャしたものなので、どのプロセスが 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 状態情報それは役に立つかもしれませんが、私たちのような気の弱い人は、代わりに XPerf を使用すれば済むのに、そんなことをするのは無理です。:-)

RPCの内部動作がわかったので、API モニター:

API モニターをダウンロード、インストールして起動します。_{(2回64 ビットの場合: x86 が 1 回、x64 が 1 回)}
へ移動ファイル-->管理者として実行
をセットするAPI キャプチャフィルターモジュールにRpcrt4.dll。
ブレークポイントと同様に、誰が関数を呼び出しているかを知りたいのですRpcServerUseProtSeq。
それぞれフック実行中のプロセスただし、クラッシュを防ぐため、PIDが低いものは除きます。理想的には、 /またはそれ以下の値を
フックしたくないでしょう。また、単一のプロセスを試してみて、後でそれらをアンフックすることもできます。dwm.exewinlogon.exe
フックされたプロセス窓...

ただし...試してみたところ、どのプロセスでもフックできました。
すべてがうまくいけば、フックプロセスRPC 呼び出しを行うプロセスにはスレッドが含まれます。
これらのスレッドをクリックすると、多数の呼び出しが表示されます。
そうであれば、問題の原因となっているプロセスが見つかります。

解決

コンピュータを最新の状態に保つことは重要です。HPWA4.0.10.0これを解決します!;-)

Answer

トラブルシューティング

ダウンロードプロセスダンプMicrosoft Sysinternals より。
WmiPrvSE.EXE が 1 秒間 25% に達したらダンプを実行します。
```
procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
```
これにより、ユーザーフォルダーにダンプが作成されます。

これをあと 1 ～ 2 回繰り返して、ダンプをさらに取得し、原因がダンプであり、別の通常のイベントではないことを確認できます。
ダンプを分析するオンラインそしてオプションで共有するスピーディーシェア。

代替:ウィンDBGコマンドと一緒に使用できる場合は!analyze -v、必ずシンボルを設定する。
表示されるスタックトレースに、この問題の原因となる手順が含まれている必要があります。

おそらく、スタックのトッププロシージャのいくつかを Google で検索して、それらが何をするのかをよりよく理解してください。
役に立たない場合は、より高度な分析が必要になる可能性があります。次のセクションを参照してください。

セットアップをダウンロードするにはWindows パフォーマンス分析ツールWindows バージョン用。
システムにソフトウェアをインストールします。

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

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

プレスENTER 一度コマンドを開始するには、スパイクが発生するまで待つ必要があります。
スパイクの直後コンソールに移動してを押しますENTER。
しばらく待つと、ユーザーフォルダーにログファイル myTrace.etl が生成されます。
次のコマンドを実行してファイルを表示し、分析します（ウィンDBG/シンボル必須）：
```
xperf %HOMEPATH%\myTrace.etl
```

調べて欲しい場合は:

ユーザーフォルダーから myTrace.etl を zip ファイルに圧縮します。
圧縮されたzipファイルを共有するスピーディーシェア。
ここでリンクを共有してください。問題の原因を見つけて示すように努めます。

WmiPrvSE.EXEはCAPIストアに対してWMIクエリを実行するためのホストであるため、XPerfを使用しても原因が見つからない場合があります。国際PC私が見つけたもう一つの解決策は、WMIログを有効にして、説明されているようにログを確認することです。ここClientProcessIdはWMIクエリを作成したプロセスのPIDになります。このPIDは、タスクマネージャーにPID列を追加するか、プロセスエクスプローラー、または、tasklist /FI "PID eq X"X が見つかった PID である場合...

の分析ダンプ 1:94行目から115行目は、リモートプロシージャコール。
の分析ダンプ2:84行目から105行目は、リモートプロシージャコール。

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

ダンプは 1 つの瞬間をキャプチャしたものなので、どのプロセスが 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 状態情報それは役に立つかもしれませんが、私たちのような気の弱い人は、代わりに XPerf を使用すれば済むのに、そんなことをするのは無理です。:-)

RPCの内部動作がわかったので、API モニター:

API モニターをダウンロード、インストールして起動します。_{(2回64 ビットの場合: x86 が 1 回、x64 が 1 回)}
へ移動ファイル-->管理者として実行
をセットするAPI キャプチャフィルターモジュールにRpcrt4.dll。
ブレークポイントと同様に、誰が関数を呼び出しているかを知りたいのですRpcServerUseProtSeq。
それぞれフック実行中のプロセスただし、クラッシュを防ぐため、PIDが低いものは除きます。理想的には、 /またはそれ以下の値を
フックしたくないでしょう。また、単一のプロセスを試してみて、後でそれらをアンフックすることもできます。dwm.exewinlogon.exe
フックされたプロセス窓...

ただし...試してみたところ、どのプロセスでもフックできました。
すべてがうまくいけば、フックプロセスRPC 呼び出しを行うプロセスにはスレッドが含まれます。
これらのスレッドをクリックすると、多数の呼び出しが表示されます。
そうであれば、問題の原因となっているプロセスが見つかります。

解決

コンピュータを最新の状態に保つことは重要です。HPWA4.0.10.0これを解決します!;-)

Question 3

Microsoftのブログ記事WMIprvse は本当に悪者なのでしょうか?WmiPrvSE.exe が使用している CPU を担当するプロセスを見つける方法を示します。

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

Answer

Microsoftのブログ記事WMIprvse は本当に悪者なのでしょうか?WmiPrvSE.exe が使用している CPU を担当するプロセスを見つける方法を示します。

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

Question 4

デバッグするには、Windows パフォーマンスツールキット次のコマンドファイルを実行します:

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

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

フィルターをMicrosoft Windows WMI アクティビティイベントのみを検索し、WMI 操作と ClientProcessId を探します。

私の例では、このCLientProcessIdは、Veeam ONE モニターサーバー。停止するとCPU使用率の問題が修正されました。

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

ここでは、Intel ProSet Monitoring サービスに属する PID 1924 のプロセスの繰り返し呼び出しが表示されます。

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

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

Answer

デバッグするには、Windows パフォーマンスツールキット次のコマンドファイルを実行します:

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

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

フィルターをMicrosoft Windows WMI アクティビティイベントのみを検索し、WMI 操作と ClientProcessId を探します。

私の例では、このCLientProcessIdは、Veeam ONE モニターサーバー。停止するとCPU使用率の問題が修正されました。

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

ここでは、Intel ProSet Monitoring サービスに属する PID 1924 のプロセスの繰り返し呼び出しが表示されます。

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

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

トラブルシューティング

答え1

実験の概要

背景情報

仮説の検証

答え2

トラブルシューティング

解決

答え3

答え4

関連情報