システムまたはsvchost.exeによるCPU使用率の急上昇 – ステップバイステップのテクニカルガイド

システムやsvchost.exeからのCPU使用率の急上昇は、どんな日も悪夢に変えてしまう可能性があります。 パソコンが遅くなり、ファンがゴロゴロと音を立て、何もかもがうまくいっていないように見える。幸いなことに、体系的なアプローチをとれば、どのサービス、プロバイダー、またはアプリケーションが原因かを特定し、効果的な解決策を実装することが可能です。

この実践ガイドでは、ステップバイステップで説明します。 CPUを大量に消費しているプロセス（System、svchost.exe、WmiPrvse.exe）の特定から、問題のあるWMIクエリの分離、サービスの分割、Perfmonによる使用状況の測定、ドライバーの確認、システム障害、マルウェア、古い構成といった一般的な原因への対処まで、幅広く対応します。「なぜ100%で動作しているのか？」という疑問から、「原因と軽減策が明確にわかる」という疑問へと繋げていくことが重要です。

正確なプロセスとそのPIDを特定する

最初のステップは、どのバイナリとPIDがCPUを消費しているかを調べることです。 そして、実際の原因が WmiPrvse.exe (WMI プロバイダー ホスト)、svchost.exe (Winmgmt/WMI をホスト)、またはシステム自体 (システムおよびカーネル割り込み) であるかどうかを確認します。

から タスクマネージャ 詳細タブに移動し、名前またはCPUで並べ替えます。 実行中のWmiPrvse.exeまたはsvchost.exeを見つけ、そのPIDをメモします。タスクマネージャー内のサービスでWinmgmtを探し、そのPIDをメモし、「詳細へ移動」を使用して、それをホストするsvchost.exeに移動します。これにより、どのインスタンスが過負荷状態にあるかが明確になります。

使用パターンを観察します。 定期的なスパイク、持続的な消費、ランダムな消費、勤務時間中のみ、またはログイン/ログアウト時のみ？これらの詳細は、タスク、スクリプト、監視ツール、または apps WMI をトリガーするサードパーティから。

パフォーマンスモニター（Perfmon）による測定と相関

Perfmonを使用すると、PIDと%CPUのグラフ表示を相互参照できます。 WmiPrvse.exe または svchost.exe のどのインスタンスがリソースを消費しているかを正確に区別します。

1. を開く コマンドプロンプト 昇格して処刑される perfmonパフォーマンス モニターを選択し、+ ボタンを押してカウンターを追加します。
2. カウンター「プロセス\プロセスID」を追加します すべてのWmiPrvse#インスタンス（該当する場合はsvchost#インスタンス）を選択します。Last/Average/Minimum/Maximumの値はPIDを反映しています。Delで指定したPIDと一致しない値はすべて削除してください。
3. ここで「プロセス\％プロセッサ時間」を追加します ホット PID と一致するインスタンス (例: WmiPrvse#1) を正確に特定し、消費曲線をリアルタイムで観察します。

svchost.exe には多くのサービスがありますか? WMI に影響を与えるものを確認します: tasklist /svc /fi "Services eq Winmgmt"より適切に診断したり影響を抑えたりするために、WMI を独自のプロセスに分離する場合は、以下を使用します。

sc config Winmgmt type= own
net stop winmgmt && net start winmgmt

問題を解決したら、共有プロセスに戻すことができます。 とともに sc config Winmgmt type= share WMI サービスを再起動します。

プロセスを内部から検査する: WMI リソースとプロバイダー

CPUだけに注目するのではなく、メモリ、ハンドル、スレッド、ユーザーをチェックしましょう。 タスクマネージャーの「詳細」タブでPIDを確認してください。ハンドルリークやスレッド数が多すぎる場合は、WMIプロバイダーまたはクライアントの効率が悪いという仮説が裏付けられます。

特定のWmiPrvse.exe内にロードされたWMIプロバイダー（DLL）を識別します。 例えば、Process Explorer（管理者として実行）では、調査対象のPIDでWmiPrvse.exeのプロパティを開き、「プロバイダー」タブでプロバイダー名、名前空間、DLLパスなどの詳細が表示されます。典型的なケースとしては、MS_NT_EVENTLOG_PROVIDERが挙げられます。 root\CIMV2 DLLを使用して %systemroot%\system32\wbem\ntevt.dllその他のテクニックについては、 WMI におけるスケジュールされたクエリとプロバイダーの分析.

問題が断続的に発生する場合 WmiPrvse.exe がリサイクルされている場合、次のコマンドで特定の DLL を含むインスタンスをすばやく見つけることができます。 tasklist /m <Proveedor.dll>。 例： tasklist /m ntevt.dll.

WMI (イベント ビューアー) への受信クエリを監査する

Microsoft-Windows-WMI-Activity ログはレーダーです。 これは、すべての受信 WMI 操作を反映し、どのクエリがどのクライアント PID から、どのユーザーで、どのクラス/名前空間に対して送信されたかを示すためです。

2 つのソースをアクティブ化して確認します。 運用ログと分析/デバッグログ。イベントビューアーで、「アプリケーションとサービスログ」>「Microsoft」>「Windows」>「WMIアクティビティ」に移動します。「表示」メニューで「分析ログとデバッグログを表示」を選択し、「トレースとデバッグ」のログ記録を有効にします。CPU使用率の急上昇をキャプチャしている間はこれらのログをアクティブにし、.csvまたは.xml形式でエクスポートします。

主なイベントとその読み方: 同上11（例えばオペレーションスタート） IWbemServices::ExecQuery o CreateInstanceEnum）とID 12（ProviderInfo、操作をHostId/PIDとプロバイダーDLLにマッピングします）です。説明には、CorrelationId、GroupOperationId、OperationId、Operation、ClientMachine、User、ClientProcessId、NamespaceNameなどのフィールドと、クエリ自体が表示されます。例： select * from Win32_Product o CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent.

クラス（例：「Win32_NTLogEvent」）とHostId/PIDのいくつかのフィルターを使用して、 次のタイプのシーケンスを一覧表示できます: CreateInstanceEnum 反対の Win32_NTLogEvent クライアントPID 5484から、DLLがHostId 556（ホットWmiPrvse.exe）のMS_NT_EVENTLOG_PROVIDERにマッピングされます。 ntevt.dllこの相互参照により、最終的に負荷を発生させるクライアント プロセスがわかります。

WMIMon: WMI呼び出しのライブ監視

誰がどのくらいの頻度でWMIを呼び出しているかを素早くリアルタイムで確認したい場合は、 公開ツール WMIMon.exe (GitHub のプロジェクト「luctalpe/WMIMon」) は、操作ごとにクライアント PID、名前空間、クラス、およびユーザーを一覧表示するのに非常に便利です。

1. WMIMonをダウンロードして管理者権限で実行します。 できれば、CPU 使用率の高い WmiPrvse.exe を識別した後、重要な瞬間をキャプチャします。
2. WMIアクティビティを収集する 数分間かけて、ループ内でどの PID が照会され、どのクラスが照会されるかを分析します (設計が不十分な監視プローブまたはスクリプトの一般的なパターン)。

特定のアプリに絞り込めない場合は、 ユーザーアカウントまたはソースコンピュータごとにグループ化されます。多くの場合、インベントリツールSCCMに関連付けられたサービスアカウントです（ポリシーエージェント/監視ホスト）またはスクリプト PowerShellの あまりにも頻繁に、または途方もなく短い間隔で相談する人。

WMIおよび関連サービスに対する修正措置

容疑者を捕まえたら、まず非破壊的な手段を講じます。 そのアプリケーションのサービスを一時的に無効にするか、監視エージェントを停止するか、 スクリプト （特定のプロパティを照会し、フィルターを使用し、範囲を広げ、次のような問題のあるクラスを避けます。 Win32_Product 遅いです)。CPU が低下するかどうかを確認します。

svchost.exeがあまりにも多くのサービスをグループ化してしまい、分離が困難になっている場合は、 Winmgmtを独自のプロセスに残し、 sc config Winmgmt type= ownWMIを再起動して測定を繰り返してください。これにより、爆発範囲が制限され、診断が容易になります。最適化の詳細については、こちらをご覧ください。 WMIパフォーマンスの向上.

高度なMicrosoftサポートについては、 管理者特権の PowerShell で実行される TSS (トラブルシューティング スクリプト セット) パッケージを使用して、すべてをキャプチャできます。 .\TSS.ps1 -UEX_WMIBase -WIN_Kernel -ETWflags 1 -WPR CPU -Perfmon UEX_WMIPrvSE -PerfIntervalSec 1 -noBasicLog完了すると、ETW、Perfmon、WPR などを含む ZIP ファイルが生成され、アップロードできるようになります。

システムとシステム割り込み: カーネルが請求額を上げるとき

「システム」プロセス（システム中断）が5～10％の持続または急上昇で推移する場合、 おそらくドライバーか ハードウェア 問題（DPCとレイテンシ）が発生しています。ここで焦点が変わり、ドライバーとデバイスのレイテンシを診断します。

DPC Latency Checker と LatencyMon を使い始めましょう: 最初の警告はカーネルのレイテンシの急上昇について警告し、2番目の警告はどのドライバー（オーディオ、ネットワーク、 ストレージ、USB）などのデバイスは、長時間のDPC（遅延時間）を生成します。赤いバーやハイライト表示されたドライバが表示されている場合は、既にその状態です。

一部から容疑者をオフにする デバイスマネージャ, ネットワーク アダプター、内部オーディオ、キャプチャ カード、PCI/PCIe/USB ハブなどを一時的に無効にします。「システム割り込み」で CPU への影響を確認します。影響を受けていないものを再度有効にして、問題のあるコンポーネントが見つかるまで繰り返します。

外付け周辺機器（USBハブを含む）を1つずつ取り外します タスクマネージャーを監視しながら操作してください。面倒な場合は、デバイスマネージャーからUSBハブを無効にしてください（マウスやキーボードがUSBハブに依存している場合は注意が必要です。別のリモコンを用意してください）。

ハードウェアの損傷や電源の不安定さも排除しないでください。 電源やノートパソコンの充電器の故障は、IRQ/DPCスパイクを引き起こす可能性があります。唯一の解決策は、一時的に交換してテストすることだけです。

古いWindows（例：7）でサウンド効果を無効にしてみてください。 遅延が発生する場合があります: サウンド パネル > 再生デバイス > スピーカーのプロパティ > エフェクト タブ > エフェクトを無効にする。

BIOS/UEFI を最新の状態に保ち、更新する前にバージョンを確認してください。 開く CMD 実行します systeminfo | findstr /I /c:bios y wmic bios get manufacturer, smbiosbiosversion次に、ボードが壊れないように細心の注意を払いながら、製造元の手順に従ってください。

CPUスパイクを抑える一般的な対策

• 使用していないアプリを閉じ、過度なマルチタスクを避けてください。 特に、バックグラウンドで多数のタブやプロセスが実行されている場合は、リソースを解放して、CPU が 90 ～ 100% を下回るかどうかを確認してください。
• 最新の完全スキャンでマルウェアを排除し、 アドウェア、マイナー、ワームは CPU を大量に消費することが多いため、システムと外部ドライブの両方をスキャンしてください。
• バグが発生しやすいドライバーやソフトウェアを更新し、 特にネットワーク、オーディオ、グラフィックに問題があります。古いWi-Fiドライバーは、Windowsアップデート後にCPUを飽和させる原因となる可能性があります。
• 熱制限や不要な制限を回避するために電力を調整します。 バランスの取れたプランを使用し、スポット熱を軽減する必要がある場合は、詳細な電源オプションから「最大プロセッサ状態」を 90% に制限します。
• Windowsの通知やバックグラウンドプロセスからのノイズを軽減します。 貢献しない通知と配信の最適化を無効にする（Windows Updateの > 詳細オプション > 配信の最適化 > 許可 ダウンロード 他のデバイスから: 無効)。
• Cortanaを使用しない場合は、レジストリでヘルパーサービスを無効にすることができます。 入ってきます HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TokenBroker そして確立する Start en 4 (まずレジストリをバックアップしてください)。
• WMIプロバイダーホスト（Winmgmt）がハングした場合は再起動してください。 サービスから：「Windows Management Instrumentation」を検索し、「再起動」を押して、CPU 使用率が低下するかどうかを確認します。
• 身体のメンテナンスを忘れないでください: ファンやヒートシンクにほこりが付着すると温度が上昇し、CPU は周波数を下げて自身を保護します。圧縮空気で清掃し、空気の流れを確認してください。

svchost.exe (サービス ホスト: ローカル システム) が CPU を消費しています

svchost.exeはサービスコンテナであり、単一のプログラムではありません。 したがって、スパイクは通常、ホストされているサービス (Windows Update、WMI、ネットワークなど) のいずれかによって発生します。

特定のサービスを識別するには: タスクマネージャー > プロセスで、「サービスホスト: ローカルシステム」を展開し、サービスごとの使用状況を確認します。または、 tasklist /svc PIDとサービスを一致させます。WMIが原因の場合は、WMI診断セクションに戻ってください。

役立つ一般的な手順: パソコンを再起動し、ウイルス対策プログラムを実行し、ドライバーを更新し、Windows Updateを実行し、不要なサービスを一時的に無効にし（注意して）、電源プランを確認してください。システムとアプリを最新の状態に保つことで、電力サージの原因となる非互換性を軽減できます。

予防レベルでは、 監視ツールを使用して異常なスパイクを検出し、自動更新を構成し、疑わしいダウンロードを防ぎ、必要に応じてクリーンアップとデフラグを実行します。

エンタープライズおよびVDI環境（Citrix）: 考慮事項

環境がCitrix（XenApp/XenDesktop/StoreFront/PVS）の場合、 安定性、消費電力、セッションエクスペリエンスに影響を与える可能性のある既知の問題が複数ありますのでご注意ください。これらはSystem/svchost.exeのスパイクの典型的な原因ではありませんが、注意する価値はあります。

リリースノートに記載されている影響を受ける領域の例: Citrix Studio（ライセンス、引用符による公開、ドメイン解決、切断されたコントローラによる遅延、重複したアプリケーションIDを持つApp-V、更新ループ、配信コントローラ/SQLミラーリングの追加の問題）、Provisioning Services（SCVMM/ESXのウィザード、vDiskレプリケーション、到達不能なドメインによるSOAPタイムアウト、 %ProgramData%\Citrix\Provisioning Services\blacklist.json); StoreFront (フォルダの色、CSSのカスタマイズ時にクラッシュ、フェデレーション認証、セルフサービス、マルチサイト再接続); VDA/Receiver (Framehawk、 クリップボード、画面ロック、オーディオ、複数のモニター、仮想チャネル、SDK）、統合された App-V（同期、名前の特殊文字、マップされたドライブからの公開）。

Citrix に関する簡単なヒント: サポートされているバージョンを維持し、ホットフィックス (LCxxxx などの ID) を確認し、ラボで App-V と SCCM を検証し、変更後に VDA と Delivery Controller を監視し、CPU スパイクと Citrix タスク (カタログ更新、MCS/PVS、Director など) 間の時間的な相関関係を文書化します。

CPU 使用率が 100% になるのはどのような場合で、そうでないのはどのような場合でしょうか?

ビデオのレンダリング、コンパイル、または大規模なアップデートのインストールを行うと、CPU 使用率が瞬間的に 90 ～ 100% まで上昇することがあります。 安静時に10%を下回る場合、または軽い運動時に10～30%に低下する場合は、予測値です。正当な措置を講じずに100%レベルが続く場合は、介入が必要です。

ここまで読み進めれば、すでに完全なロードマップが完成していることになります。 PIDと実際のプロセスを特定し、PerfmonとWMIログを測定して相関関係を調べ、プロバイダーとクライアントを特定し、是正措置（クエリの最適化、サービスの分割、ドライバーと電源の調整）を講じ、一般的な原因（マルウェア、埃、周辺機器）に対処し、企業環境ではCitrixとApp-Vの特殊性にも注意を払います。適切な方法と忍耐をもって取り組めば、これらのスパイクはもはや謎ではなく、制御可能になります。