windows – 「システム」プロセスによる高いCPU使用率のトラブルシューティング

cpu-usage performance troubleshooting windows windows-8

私はいつからか私のシステムがフリーズしていることに気づいたし、それはおそらくシステムプロセスによって引き起こされるCPUの使用率が高いことが原因であると考えられます

私が実行しているアプリケーションはすべてSkype、TeamSpeak、Chromeなので、その分のCPUを食うことはないはずです

下のスクリーンショットで問題そのものと実行中のプロセスを確認することができます

CPUの使用率が90%に達している時もありますが、平均的な使用率は40~65%のようです

私のPCのパラメータ

  • Windows 8(カスタマープレビュー)
  • インテル Core i3 – 2350M
  • 8 GB RAM

私はどんな助けの試みも感謝しています宜しくお願いします

–UPDATE–

下のユーザーさんが素晴らしい回答をされているように、システムで一番CPUを食っているプロセスはArthurx.sysと呼ばれるもので、グーグルで簡単に調べるとTPLinkドライバ(2週間ほど前に購入したwifiアダプタ!)だそうで、ドライバはWindowsのMSDNからインストールされていますが、付属のCDからもインストールしようとしましたがダメでした。システム起動時からCPUの5%程度しか使っていないのですが、2~4時間作業しているとどんどん増えていき、40~60%程度のCPU使用率に達しています

デバイス名。TPLink WN722N

  145  Scott  2013-01-03


ベストアンサー

Introduction

システム」プロセスによるCPU使用率の高さは、多くの場合、ハードウェアドライバの問題(バグ、古いバージョン、不適合性など)が原因となることがあります

システムプロセスは、より高いレベルのメモリアクセスを必要とする異なるベンダーの複数のハードウェアドライバをロード(またはホスト)します。 このため、特定の原因を診断するには、以下に説明するように、ちょっとした探偵作業が必要になることがあります

問題を診断します

CPU使用率の問題を診断するには、Event Tracing for Windows (ETW)を使用してCPUのサンプリングデータ/プロファイルを取得する必要があります

データを取得するには、Windows SDKの一部であるWindows Performance Toolkitをインストールします

Windows 10 WPTは、Windows 8/Server 2012、Windows 8.1/Server 2012R2、Windows 10/Server 2016で使用できます。まだWindows 7を使用している場合は、SDK/WPT with Build 15086を使用してください

(他のすべてのエントリは非選択可能)

ここでWPRUI.exeを実行し、First Levelを選択し、Resourceの下でCPU使用量を選択し、startをクリックします

今度は1分間のCPU使用量をキャプチャします。1分後、保存をクリックします

生成されたETLファイルをWindows Performance Analyzerで分析します

WPAの内部では、デバッグシンボルを読み込み、SYSTEMプロセスのStackを展開します。このデモでは、CPUの使用量はnVIDIAドライバから来ています


次のデモでは、CPU使用率はRealtek NICドライバから来ています


ntoskrnl.exe!ViKeTrimWorkerThreadRoutine、ntoskrnl.exe!MmVerifierTrimMemory、ntoskrnl.exe!VerifierKeLeaveCriticalRegionのような呼び出しがあった場合、これはDriver Verifierが有効になっていることを意味します。これもまた、パフォーマンスに大きく影響し、SYSTEMの使用率が高くなります。Driver Verifierを無効にして、再起動してください


このデモでは、ドライバ iai2ce.sys (Intel Serial IO GPIO Controller ドライバ) が原因となっています


この例では、CPUの使用量はファイルrtsuvc.sysから来ているので、Realtek UVC webcam Driverと思われます


このデモでは、Bitdefenderのドライバignis.sysを使用しています


以下の例では、broadcomネットワークドライバbcmwl664.sysでCPU使用量を計算しています


原因としてntoskrnl.exe!MiZeroWorkerPagesを見ると厄介です。これは、メモリを再利用する前にメモリをゼロにするカーネルの機能が、CPUの使用率を高くする原因になっていることを意味しています

どのプロセスが原因なのかを見極める方法は実際にはありませんが、Chromeでハードウェアアクセラレーションを有効にしていると、Chromeが原因になることは知っています。そのため、これが表示されてChromeを使用している場合は、Chromeのハードウェアアクセラレーションをオフにしてください


それらのntoskrnl.exe!RtlpGenericRandomPatternWorker、ntoskrnl.exe!RtlpTestMemoryRandomUpの呼び出しを見ると

CPU の使用量は、問題がないかどうかメモリをテストするためにカーネルから送られてきます (memtest)。この使用量は、Windows 8.1/10のアイドルメンテナンスタスクを介してトリガーされます。タスクスケジューラを使用してアイドルタスクを無効にすることができます

Windows 10では、タスクはMicrosoft > Windows > MemoryDiagnostic > RunFullMemoryDiagnosticの下でRunFullMemoryDiagnosticsと呼ばれています


この場合、CPUの使用量はWindows ServerのData Deduplication機能(dedup.sys!DdpPostCreate)から来ているようです


今回のデモでは、WIFIカードドライバathrx.sysが原因でCPU使用率が低下しています

これを見たらドライバーのアップデートを検索してみてください


以下のデモでは、CITRIXドライバを使用しています

そこで、Citrixの問題を解決する方法については、IT部門にお問い合わせください


このデモでは、関数usbhub.sys!UsbhPortRecycleがCPUを使用する原因となっています

USB2.0ポートを1.1の速度に変更したり、USBドライブを他のUSB2.0ポートに接続したりすることで、一部のユーザーには効果がありました


この場合、SYSTEMの使用量が少ないのは、Acronisドライバtdrpm251.sysからです


今回のデモでは、CPU使用率ntoskrnl.exe!KeAcquireSpinLockRaiseToDpcntoskrnl.exe!KeReleaseSpinLock

ドライバーがSpinLocksを非常に多用しています。原因となるデバイス/ドライバが見つかるまで、いくつかのデバイス/ドライバを無効にしてください


この場合、CPUの使用量はドライバL1C62x64.sysが原因です

これはqualcomm atheros AR8171/8175 PCI-E gigabit Ethernetのドライバです。そのため、スタックに表示されていたらドライバを更新してください


ここでは、CPU使用量はホストファイル(netbt.sys!DelayedScanLmHostFile)のスキャンから来ています

この使用を避けるために、hosts ファイルが大きすぎないことを確認してください


この場合、CPU使用量はsymantecのSRTSP64.SYSから来ています

中古のシンマンテック製品を最新版にアップデートしてください


ここでは、CPUの使用量はAMDのGPUドライバ(atikmdag.sys)から来ています

これが表示された場合は、AMD のサイトに移動し、あなたの AMD カードの最新のドライバを取得します


ここでは、ドライバTMXPFlt.sysとVsapiNt.sysが高いCPU使用率の原因となっています

私が見たところ、これらのファイルはトレンドマイクロのAVスイートの一部です。ツールをアップデートするか、削除してください


この例では、CPUの使用量は関数ntoskrnl.exe!MmGetPageFileInformationから来ています

この関数は、ページファイルの情報を取得します

ルーチンの説明。このルーチンは、現在アクティブなページング ファイルに関する情報を返します

ページファイルを無効にして、再起動して再度有効にして、これで修正されるかどうかを確認してください。また、Intelのサービスを削除することもできます (例: Intel Content Protection HECI Service) あるユーザーのために修正されたようです


ここでは、ドライバNetwtw04.sys(Intel Wifiドライバ)がflushCompleteAllPendingFlushRequestsの機能を呼び出しているため、CPU使用率が高くなっていることがわかります

デバッグシンボルが読み込まれるので、Windowsのinboxドライバを使用しています。ここだけは、関数名flushCompleteAllPendingFlushRequestsのコールスタックを見るためのデバッグシンボルを取得しています

ここでは、インテルから最新のドライバをインストールする必要があります それを修正します


SYSTEM使用の最も複雑なケースは、コールスタックでのACPI.sys使用です

Line #, DPC/ISR, Module, Stack, Count, Process, Weight (in view) (ms), TimeStamp (s), % Weight
6, , ,   |    |- ACPI.sys!ACPIWorkerThread, 40246, , 39.992,941063, , 4,13
7, , ,   |    |    ACPI.sys!RestartCtxtPassive, 40246, , 39.992,941063, , 4,13
8, , ,   |    |    ACPI.sys!InsertReadyQueue, 40246, , 39.992,941063, , 4,13
9, , ,   |    |    ACPI.sys!RunContext, 40246, , 39.992,941063, , 4,13
10, , ,   |    |    ntoskrnl.exe!KeReleaseSpinLock, 40246, , 39.992,941063, , 4,13
11, , ,   |    |    ntoskrnl.exe!KiDpcInterrupt, 40246, , 39.992,941063, , 4,13
12, , ,   |    |    ntoskrnl.exe!KiDispatchInterruptContinue, 40246, , 39.992,941063, , 4,13
13, , ,   |    |    ntoskrnl.exe!KxRetireDpcList, 40246, , 39.992,941063, , 4,13
14, , ,   |    |    ntoskrnl.exe!KiRetireDpcList, 40246, , 39.992,941063, , 4,13
15, , ,   |    |    |- ntoskrnl.exe!KiExecuteAllDpcs, 40198, , 39.945,173325, , 4,13
16, , ,   |    |    |    |- ACPI.sys!ACPIInterruptDispatchEventDpc, 27565, , 27.408,930428, , 2,83
17, , ,   |    |    |    |    |- ACPI.sys!ACPIGpeEnableDisableEvents, 24525, , 24.384,921620, , 2,52
18, , ,   |    |    |    |    |    ACPI.sys!ACPIWriteGpeEnableRegister, 24525, , 24.384,921620, , 2,52
19, , ,   |    |    |    |    |    |- hal.dll!HalpAcpiPmRegisterWrite, 24421, , 24.281,015516, , 2,51
20, , ,   |    |    |    |    |    |    |- hal.dll!HalpAcpiPmRegisterWritePort, 24166, , 24.027,316013, , 2,48

これはデバッグが非常に困難です。sysinternalsトピックで、いくつかのアドバイスを挙げました


以下のデモでは、Intel HD 630用のバージョン.4574のIntel HDドライバigdkmd64.sysで問題が発生しています

解決策は、少なくとも.4590のバージョンのドライバにアップデートすることです


以下の場合、SYSTEMプロセスのCPU使用率がドライバstdriverx64.sysに起因しています

これはaudio streaming driverのようです。なので、WPAでこれを見たら、このソフトウェア/ドライバをアップデートしてください


SYSTEMのコールスタックにrisdxc64.sysというドライバが表示され、CPU使用率が高くなっている場合は、RICOH PCIe SDXC/MMC Host Controllerのドライバをアップデートするか、ドライバのアップデートで解決しない場合はデバイスマネージャでSDカードリーダーを無効にしてください

このSDカードリーダーはLenovoの多くの端末に内蔵されているようです


ユーザーの@stevemidgley氏は、Wdf01000.sys!FxSystemWorkItem::_WorkItemThunkでCPU使用率が高くなる問題を新たに示した

ここでは、UDE.sysのドライバが原因となっていることがわかります

シンボルハブ内

モデムドライバに属していることがわかり、トレースのPNPデータではFibocom L850-GL (LTE Modem)がデバイスの可能性があることがわかりました

そして解決策は、デバイスマネージャーでモデムとUSBコンポジットデバイスを無効にすることです


161  magicandre1981  2017-01-06


これは、システムによってロードされたドライバや他のモジュールの欠陥が原因である可能性があります。システムプロセスの内部を見るには、プロセスエクスプローラのようなツールを使用することができます

ダウンロードして実行し、システムプロセスを選択し、右クリックしてプロパティを選択します

スレッドタブに切り替えます(シンボルに言及しているダイアログボックスは無視してください)

これにより、どのファイルが過剰なCPU使用量を使用しているかがわかり、そこから診断を試みることができます

しかし、他の人がコメントで言っているように、できるだけ早くプレビュー版から離れる必要があります

100  Graham Wager  2013-01-03


magicandre1981さんの素晴らしい回答に追加して、デバッグシンボルの読み込みについての注意事項: Windows Performance Analyzerでシンボルの読み込みが正しく動作している場合、「Trace > Load Symbols」にチェックを入れた後、上部に「Loading symbols」と書かれたプログレスバーが表示され、その横にファイル名が表示され、完了するまでに数分かかります。また、Diagnostic Consoleには以下のような行がたくさん表示されているはずです

SYMSRV:  File: Accessibility.ni.pdb

SYMSRV:  Notifies the client application that a proxy has been detected.
SYMSRV:  Connecting to the Server: http://msdl.microsoft.com/download/symbols.
SYMSRV:  Successfully connected to the Server.
SYMSRV:  Sending the information request to the server.
SYMSRV:  Successfully sent the information request to the server.
SYMSRV:  Waiting for the server to respond to a request.
SYMSRV:  Successfully received a response from the server.
SYMSRV:  Closing the connection to the Server.
SYMSRV:  Successfully closed the connection to the Server.
SYMSRV:  Get File Path: /download/symbols/Accessibility.ni.pdb/7B46178957827CDAB7EE4C86EDEE1DAE1/Accessibility.ni.pdb

これらのいずれかが表示されない場合は、デバッグシンボルの読み込みがうまくいっていない可能性が高く、トレースを適切に解釈することができません

私の場合、最初にデバッグシンボルをロードしてもうまくいきませんでした。私は、これらの指示に従うことで修正しました

  1. Windows Performance Toolkit の x86 または x64 バージョンを使用しているかどうかを確認します

    これは、Windowsのx86ビルドでは簡単です。x64 ビルドでは、タスクマネージャーで *32 タグを確認できます。もしそれがなければ、あなたは x64 バージョンを実行していることになります

    WPT はアーキテクチャに関係なく、常に Program Files (x86) にインストールされることに注意してください

  2. 正しいデバッガ・ディレクトリからdbghelp.dllsymsrv.dllファイルをWindows Performance Toolkitディレクトリにコピーしてください。私のシステムでは、関連するディレクトリは以下の通りです

    C:\Program Files (x86)\Windows Kits\10\Debuggers\x64C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit

  3. dbghelp.dllの正しいバージョンが検出されるように、Windows Performance Analyzerを再起動します

4  AronVanAmmers  2017-07-13


私の問題は、何かをダウンロードするときにCPUの使用率がバカ高くなることでした(最大4GHz)。私はPredator Helios 300とKiller WiFiカードを持っているので、Killerドライバはプリインストールされていました。プロセスエクスプローラを使ってSystemのプロパティ→スレッドタブに入ってみたところ、「kfeco10x64.sys」がCPU使用率の高さの原因になっていることがわかりました。kfeco10x64.sys “はキラーネットワークサービスの一部だったので、msconfigを実行して無効化し、”Rivet Networks “から全てのサービスのチェックを外しました

再起動後、問題は私のために消えました。何よりも重要なのは、ダウンロード時の速度低下がないことです。同じ問題に直面している方のお役に立てれば幸いです

0  zUmA  2020-03-04


回答 @magicandre1981 が追加したものが、どんな問題でも解決の鍵となります。私の場合はそこには記載されていませんでしたが、The most complicated case of SYSTEM usage is ACPI.sys usage in the callstack:の下に記載されているスタックの中に似たような言葉がありました。私の場合はIntel Rapid Storageのドライバをインストールすることで解決しました。私の場合は、Intel Rapid Storageドライバをインストールすることで解決しましたが、このドライバなしで長時間動作し、CPUの問題もなかったので、これは予想外でした。私のスタックをここに書きましたが、おそらく誰かが似たようなキーワードでこの答えを見つけてくれると思います

Line #, Process, Stack, Count, Weight (in view) (ms), TimeStamp (s), % Weight
3, , [Root], 45104, 45,300.439000, , 16.21
4, ,   ntoskrnl.exe!KiStartSystemThread, 45104, 45,300.439000, , 16.21
5, ,   ntoskrnl.exe!PspSystemThreadStartup, 45104, 45,300.439000, , 16.21
6, ,   |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxWorkerThread, 38830, 38,997.540000, , 13.95
7, ,   |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessEntry, 38708, 38,874.943400, , 13.91
8, ,   |    |    |- ntoskrnl.exe!memcpy, 33888, 34,032.390100, , 12.18
9, ,   |    |    |    |- ntoskrnl.exe!memcpy<itself>, 33655, 33,795.069100, , 12.09
10, ,   |    |    |    |- ntoskrnl.exe!KiDpcInterrupt, 228, 232.331300, , 0.08
11, ,   |    |    |    |- ntoskrnl.exe!KiInterruptDispatchNoLockNoEtw, 4, 3.989700, , 0.00
12, ,   |    |    |    |- ntoskrnl.exe!KiInterruptDispatch, 1, 1.000000, , 0.00
13, ,   |    |    |- ntoskrnl.exe!RtlCompressBuffer, 2571, 2,585.541600, , 0.93
14, ,   |    |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessReadyQueue, 2015, 2,022.554900, , 0.72
15, ,   |    |    |- ntoskrnl.exe!MmBuildMdlForNonPagedPool, 129, 129.294600, , 0.05
16, ,   |    |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessEntry<itself>, 63, 62.901700, , 0.02
17, ,   |    |    |- ntoskrnl.exe!ExAcquireSpinLockExclusive, 31, 31.208200, , 0.01
18, ,   |    |    |- ntoskrnl.exe!MetroHash64::Hash, 10, 10.033100, , 0.00
19, ,   |    |    |- ntoskrnl.exe!KiDpcInterrupt, 1, 1.019200, , 0.00
20, ,   |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxWorkerThread<itself>, 78, 78.477100, , 0.03
21, ,   |    |- ntoskrnl.exe!ExAcquireSpinLockExclusive, 39, 39.068100, , 0.01
22, ,   |    |- ntoskrnl.exe!KeWaitForSingleObject, 5, 5.051400, , 0.00
23, ,   |- ntoskrnl.exe!SMKM_STORE<SM_TRAITS>::SmStWorkerThread, 5420, 5,445.923200, , 1.95
24, ,   |- ntoskrnl.exe!SmKmStoreHelperWorker, 495, 496.265200, , 0.18
25, ,   |- ntoskrnl.exe!SMKM_STORE<SM_TRAITS>::SmStReadThread, 359, 360.710600, , 0.13
26, , n/a, 16760, 16,773.871200, , 6.00

Update: 残念ながら問題が再発しました。再起動後、しばらくは正常に動作していましたが、同じスタックで同じCPUリークが発生しています

0  neustart47  2020-04-24


私も同じ問題を抱えていましたが、RAMモジュールの一つを外すと消えてしまいました。どうやら不具合があったようです。Windows 7、32ビットを実行しています

-1  Cosmin  2014-12-27


最初に、提供されたレビューと情報は非常に有益ですが、通常はもっと少ない知性でこれを理解することができます!私は単に MSCOFIG.EXE とバイナリ検索を使って、問題のあるサービスを分離しました。このような問題のほとんどは、インテルのソフトウェアが原因であることがわかりました。私は、会社名のないサービスを無効にすることから始めます。次に、インテルのサービスから始めます。 それから完全なバイナリ検索を行います。通常、誰かのPCの問題を修正するには、せいぜい1時間ほどかかります。Intelは決して良いコンピュータ会社ではなかったし、彼らのソフトウェアがそれを証明している。ペンティアムアーキテクチャが発表されたときには、10年も前のことだったのだ。VAXの時代に、誰がページ化されたメモリを搭載したコンピュータ・アーキテクチャを作っただろうか?まあ、歴史の話であなたを退屈させるつもりはない。私もAMDやマイクロソフトのファンではありません。おそらく、いつかまた本物のコンピュータを作ることができるようになるだろう

-2  Leonard Umina  2018-02-11