しばらく前からシステムがフリーズしていることに気づきました。これはおそらく、システム プロセスによる CPU 使用率の高さが原因です。
私が実行しているアプリケーションは Skype、TeamSpeak、Chrome だけなので、CPU をそれほど消費することはないはずです。
以下のスクリーンショットで、問題自体と実行中のプロセスを確認できます。
CPU 使用率が 90% に達することもありますが、平均使用率は 40 ~ 65% 程度です。
私のPCのパラメータ:
- Windows 8 (カスタマー プレビュー)
- インテル Core i3 - 2350M
- 8 GB の RAM
ご協力いただければ幸いです。よろしくお願いいたします。
- アップデート -
下のユーザーが素晴らしい回答を投稿しているように、システム内で CPU を最も消費しているプロセスが と呼ばれていることに気付きました。GoogleArthurx.sys
で簡単に検索すると、TPLink ドライバー (2 週間ほど前に購入した Wi-Fi アダプター) であることがわかります。ドライバーは Windows MSDN からインストールされていますが、付属の CD からドライバーをインストールしようとしましたが、役に立ちません。システムの起動時から CPU の 5% 程度しか使用していませんが、2 ~ 4 時間稼働すると増加し、CPU 使用率が 40 ~ 60% に達します。
装置名:TPLink WN722N
答え1
導入
「システム」プロセスによる CPU 使用率が高い場合、多くの場合、ハードウェア ドライバーの問題 (バグ、古いバージョン、非互換性など) が原因である可能性があります。
システム プロセスは、より高いレベルのメモリ アクセスを必要とする、さまざまなベンダーの複数のハードウェア ドライバーをロード (またはホスト) します。このため、特定の原因を診断するには、以下に説明するような多少の調査作業が必要になる場合があります。
問題の診断
CPU 使用率の問題を診断するには、Windows イベント トレーシング (ETW) を使用して CPU サンプリング データ/プロファイルをキャプチャする必要があります。
データを取得するには、Windows パフォーマンス ツールキットをインストールするの一部であるWindows SDK。
Windows 10 WPTは、Windows 8/Server 2012、Windows 8.1/Server 2012R2、Windows 10/Server 2016で使用できます。まだWindows 7をお使いの場合は、ビルド 15086 の SDK/WPT。
を実行しWPRUI.exe
、 を選択しFirst Level
、リソースの下で を選択するCPU使用率クリックして始める。
1分間のCPU使用率を記録します。1分後にクリックします。保存。
今生成されたETLファイルをWindowsパフォーマンスアナライザーで分析するグラフをドラッグ アンド ドロップして、図のようCPU Usage (sampled)
に列を並べ替えます。analysis pane
WPA内部では、デバッグシンボルをロードするSYSTEM プロセスのスタックを展開します。このデモでは、CPU 使用率は nVIDIA ドライバーから得られます。
次のデモでは、CPU 使用率は Realtek NIC ドライバーから得られます。
次のような電話を見かけたらntoskrnl.exe!ヴィKeTrimWorkerThreadRoutine、ntoskrnl.exe!Mm検証者TrimMemory、ntoskrnl.exe!検証者クリティカルリージョンからの離脱これは、Driver Verifier が有効になっていることを意味します。これにより、パフォーマンスも大幅に低下し、システムの使用率が高くなります。ドライバー検証を無効にする再起動します。
このデモでは、ドライバーiai2ce.sys
(Intel Serial IO GPIO コントローラー ドライバー) によって次のことが起こります。
この例では、CPU使用率はファイルから来ているようrtsuvc.sys
です。Realtek UVC webcam Driver
このデモでは、Bitdefenderドライバがignis.sys
次の例では、CPU使用率はBroadcomネットワークドライバーによって発生しています。bcmwl664.sys
原因を見るとntoskrnl.exe!MiZeroWorkerPages
、それはより複雑です。つまり、メモリを再び使用する前にゼロにするカーネルの機能により、CPU 使用率が高くなります。
どのプロセスが原因かを検出する実際の方法はありませんが、Chrome でハードウェア アクセラレーションが有効になっている場合は、Chrome が原因となる可能性があります。そのため、この問題が表示され、Chrome を使用している場合は、Chrome でハードウェア アクセラレーションをオフにしてください。
これらを見るとntoskrnl.exe!RtlpGenericRandomPatternWorker、ntoskrnl.exe!RtlpTestMemoryRandomUp通話
CPU 使用率は、メモリの問題をテストするカーネル (memtest) から発生します。この使用率は、Windows 8.1/10 のアイドル メンテナンス タスクによってトリガーされます。タスク スケジューラを使用してアイドル タスクを無効にすることができます。
Windows 10では、このタスクはRunFullMemoryDiagnosticsと呼ばれます。Microsoft > Windows > メモリ診断 > RunFullMemoryDiagnostic。
この場合、CPU 使用率はWindows Server のData Deduplication
機能 ( ) から発生しているようです。dedup.sys!DdpPostCreate
このデモでは、CPU使用率はWIFIカードドライバによって発生しています。athrx.sys
これが表示される場合は、ドライバーの更新を検索してください。
次のデモでは、Citrix ドライバーが関係しています。
Citrix の問題を解決する方法については、IT 部門にお問い合わせください。
このデモでは、関数usbhub.sys!UsbhPortRecycle
によって CPU 使用率が上がります。
USB2.0ポートを1.1速度に変更するまたは、USB ドライブを他の USB 2.0 ポートに接続すると、一部のユーザーにとっては役に立ちます。
この場合、少量のシステム使用量は Acronis ドライバーによって発生しますtdrpm251.sys
。
このデモでは、CPU 使用率ntoskrnl.exe!KeAcquireSpinLockRaiseToDpc
とntoskrnl.exe!KeReleaseSpinLock
。
ドライバーはスピンロック非常に重いです。原因となるデバイスやドライバーが見つかるまで、いくつかのデバイスやドライバーを無効にしてください。
この場合、CPU使用率はドライバーによって発生しますL1C62x64.sys
これはドライバーですqualcomm atheros AR8171/8175 PCI-E gigabit Ethernet
。スタック内にこのドライバーが表示されている場合は、ドライバーを更新してください。
ここで、CPU 使用率はホスト ファイル (netbt.sys!DelayedScanLmHostFile) のスキャンから発生します。
この使用法を避けるには、hosts ファイルが大きすぎないことを確認してください。
この場合、CPU 使用率はSRTSP64.SYS
Symantec から発生します。
使用中のシマンテック製品を最新バージョンに更新します。
ここで、CPU使用率はAMD GPUドライバー(atikmdag.sys)から来ています。
これが表示された場合は、AMD サイトにアクセスして、AMD カードの最新ドライバーを入手してください。
ここで、ドライバー TMXPFlt.sys と VsapiNt.sys が CPU 使用率の上昇を引き起こします。
私が見たところ、これらのファイルは Trend Micro AV スイートの一部です。ツールを更新するか、削除してください。
この例では、CPU使用率は関数から来ていますntoskrnl.exe!MmGetPageFileInformation
この関数はページファイルに関する情報を取得します。
ルーチンの説明: このルーチンは、現在アクティブなページング ファイルに関する情報を返します。
ページファイルを無効にし、再起動して再度有効にして、問題が解決するかどうかを確認します。また、Intel サービス (例: Intel Content Protection HECI Service) を削除します。ユーザーにとっては修正されたようだ。
ここでは、ドライバーNetwtw04.sys
(Intel Wifi ドライバー) が関数を呼び出しflushCompleteAllPendingFlushRequests
、これにより CPU 使用率が高くなっていることがわかります。
デバッグ シンボルがロードされるため、Windows 受信トレイ ドライバーが使用されます。ここでのみ、関数名を含むコールスタックを表示するためのデバッグ シンボルを取得できますflushCompleteAllPendingFlushRequests
。
ここで、あなたはIntelの最新ドライバーをインストールするそれを修正します。
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 トピック、私はいくつかのアドバイスを挙げました:
- CPUファンのほこりによりCPUが過熱しないようにする
- (同じ)BIOS/UEFIを更新または再フラッシュする
- デフォルトのBIOS/UEFI設定をロードする
- バッテリーが損傷していないことを確認するには、ノートブックからバッテリーを取り外すか、デバイス マネージャーでバッテリーを無効にします。
- ジャンパーを変える HDDキャディDVD/ブルーレイドライブをキャディーに交換して、古いHDDの隣にSSDを設置した場合
- 一部のデバイスを無効にするこのユーザーのアドバイスに従って
- Intelチップセットを使用している場合は、インストールしてみてくださいインテル ラピッド ストレージ テクノロジー (RST)Windowsの標準AHCIドライバーを置き換える。これも助けになったようだ。
- ユーザーシェイナ わかった、使用してプロセスハッカー (管理者として開始)ACPI.sys の問題のスレッドを一時停止すると、彼の場合、問題が「解決」されます。したがって、他のすべての手順で問題が解決しない場合は、彼の回避策を試してください。
igdkmd64.sys
次のデモでは、 Intel HD 630 用のバージョン .4574 のIntel HD ドライバーが問題を引き起こしています。
解決策はドライバーのアップデートバージョンが少なくとも .4590 であること。
次の場合、SYSTEMプロセスのCPU使用率はドライバーによって発生します。stdriverx64.sys
これはオーディオストリーミングドライバーしたがって、WPA でこのエラーが表示される場合は、このソフトウェア/ドライバーを更新してください。
SYSTEMのコールスタックで呼び出されるドライバがrisdxc64.sys
CPU使用率の上昇の原因になっている場合は、リコー PCIe SDXC/MMC ホスト コントローラドライバーの更新で問題が解決しない場合は、ドライバーをインストールするか、デバイス マネージャーで SD カード リーダーを無効にします。
この SD カード リーダーは多くの Lenovo デバイスに組み込まれているようです。
ユーザー@stevemidgleyは、CPU使用率が高くなるという新たな問題を示しました。Wdf01000.sys!FxSystemWorkItem::_WorkItemThunk
ここで、原因となっているドライバー UDE.sys を確認できます。
シンボルハブ
これはモデム ドライバーに属しており、トレースの PNP データにはFibocom L850-GL
(LTE モデム) が可能なデバイスとして表示されていることがわかります。
解決策は、デバイス マネージャーでモデムと USB 複合デバイスを無効にすることです。
ユーザーファジャー次のケースを想定します。
ここではCPU使用量は小さいですが、DPC/ISR使用量にビューを変更すると
avgNetHub.sysドライバが大量のDPC使用を引き起こしていることがわかります
名前から、このドライバーは AVG ウイルス対策ソフトウェアの一部であることがわかります。したがって、トレースにこのドライバーが表示された場合は、ソフトウェアを更新するか、削除してください。
答え2
これは、システムによってロードされたドライバーやその他のモジュールの欠陥が原因である可能性があります。システムプロセスの内部を確認するには、次のようなツールを使用できます。プロセスエクスプローラー。
ダウンロードして実行し、システム プロセスを選択して右クリックし、[プロパティ] を選択します。
[スレッド] タブに切り替えます (シンボルを示すダイアログ ボックスは無視します)。
これにより、どのファイルが過剰な CPU 使用率を使用しているかが表示され、それに基づいて診断を試みることができます。
しかし、他の人がコメントで言っているように、プレビュー バージョンからできるだけ早く移行する必要があります。
答え3
追加するデバッグシンボルの読み込みに関する注意magicandre1981 の素晴らしい回答: Windowsパフォーマンスアナライザーでシンボルの読み込みが正しく機能する場合は、チェックマークを付けた後、トレース > シンボルの読み込み上部に進捗バーが表示され、シンボルの読み込みファイル名が横に表示され、完了するまでに数分かかります。また、診断コンソールに以下のような行が多数表示されます。
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
どちらも表示されない場合は、デバッグ シンボルの読み込みが機能していない可能性があり、トレースを正しく解釈できません。
私の場合、デバッグシンボルの初期ロードが機能しませんでした。次の方法で修正しました。これらの指示:
Windows パフォーマンス ツールキットの x86 バージョンまたは x64 バージョンのどちらを使用しているかを確認します。
これは、Windows の x86 ビルドでは簡単です。x64 ビルドでは、タスク マネージャーで *32 タグを確認できます。それがない場合は、x64 バージョンを実行しています。
WPT は、アーキテクチャに関係なく、常に Program Files (x86) にインストールされることに注意してください。
dbghelp.dll
およびsymsrv.dll
ファイルを適切なデバッガー ディレクトリから Windows Performance Toolkit ディレクトリにコピーします。私のシステムでは、関連するディレクトリは次のとおりです。
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
そしてC:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit
正しいバージョンの dbghelp.dll が選択されるように、Windows パフォーマンス アナライザーを再起動します。
答え4
答えによって追加フォローは、あらゆる問題を解決する鍵です。私のケースはそこに記載されていませんでしたが、The most complicated case of SYSTEM usage is ACPI.sys usage in the callstack:
セクションの下にあるスタックで同様の単語を見つけました。私のケースでは、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
アップデート:残念ながら、問題は再発しました。PCを再起動すると、しばらくは正常に動作しますが、その後、同じスタックで同じCPUリークが発生します。