解决“系统”进程的高CPU使用率

#1 楼

简介

“系统”进程的CPU使用率过高通常可能是由硬件驱动程序问题（错误，旧版本，不兼容性等）引起的。

系统进程从要求更高级别内存访问权限的不同供应商处加载（或托管）多个硬件驱动程序。这就是诊断特定罪魁祸首可能需要进行一些侦探工作的原因，如下所述。

诊断问题

要诊断CPU使用率问题，应使用Windows事件跟踪（ETW）捕获CPU采样数据/配置文件。

要捕获数据，请安装Windows Performance Toolkit，它是Windows SDK的一部分。

Windows 10 WPT可以在Windows 8 / Server 2012，Windows 8.1 / Server 2012R2和Windows 10 / Server 2016上使用。如果仍然使用Windows 7，则将SDK / WPT与Build 15086一起使用。


（其他所有条目都可以取消选择）

现在运行WPRUI.exe，选择First Level，在“资源”下，选择“ CPU使用率”，然后单击“开始”。



现在捕获1分钟的CPU使用率。 1分钟后，单击“保存”。

现在通过将CPU Usage (sampled)图形拖放到analysis pane并排序如图中所示的列，使用Windows Performance Analyzer分析生成的ETL文件。 />


在WPA内，加载调试符号并展开SYSTEM进程的Stack。在此演示中，CPU使用率来自nVIDIA驱动程序。


在以下演示中，CPU使用率来自Realtek NIC驱动程序：




当您看到诸如ntoskrnl.exe！ViKeTrimWorkerThreadRoutine，ntoskrnl.exe！MmVerifierTrimMemory，ntoskrnl.exe！VerifierKeLeaveCriticalRegion之类的调用时，这意味着您已启用驱动程序验证程序。这也极大地损害了性能并导致高系统使用率。禁用驱动程序验证程序并重新启动。




在此演示中，驱动程序iai2ce.sys（英特尔串行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中，该任务在Microsoft> Windows> MemoryDiagnostic> RunFullMemoryDiagnostic下被称为RunFullMemoryDiagnostics。




在这种情况下，CPU使用率似乎来自Windows Server的Data Deduplication功能（dedup.sys!DdpPostCreate）：




在此演示中，CPU使用率是由WIFI卡驱动程序引起的。athrx.sys



如果发现此驱动程序，请搜索驱动程序更新。


在以下演示中，涉及一个citrix驱动程序：



因此，请与您的IT部门联系以解决Citrix问题。问题。


在此演示中，功能usbhub.sys!UsbhPortRecycle导致CPU使用率：



将USB2.0端口更改为1.1速度或将USB驱动器连接到其他USB 2.0端口对于某些用户有所帮助。


在这种情况下，少量的SYSTEM使用来自Acronis驱动程序tdrpm251.sys：




在此演示中，CPU使用率分别为ntoskrnl.exe!KeAcquireSpinLockRaiseToDpc和ntoskrnl.exe!KeReleaseSpinLock。



，因此驱动程序非常频繁地使用SpinLocks。禁用某些设备/驱动程序，直到看到引起该问题的设备/驱动程序。


在这种情况下，CPU使用率由驱动程序L1C62x64.sys



这是qualcomm atheros AR8171/8175 PCI-E gigabit Ethernet驱动程序。因此，如果您在堆栈中看到驱动程序，请进行更新。


这里，CPU使用率来自扫描主机文件（netbt.sys！DelayedScanLmHostFile）



确保您的主机文件不要太大以避免这种使用。


在这种情况下，CPU使用率来自symantec的SRTSP64.SYS。



将使用过的symantec产品更新到最新版本。


这里，CPU使用率来自AMD GPU驱动程序（atikmdag .sys）



如果看到此消息，请访问AMD网站并获取适用于您的AMD卡的最新驱动程序。


在这里，驱动程序TMXPFlt.sys和VsapiNt.sys导致CPU使用率很高。



从我的看来，这些文件是趋势科技AV套件的一部分。更新该工具或将其删除。


在此示例中，CPU使用率来自功能ntoskrnl.exe!MmGetPageFileInformation



此功能获取有关页面文件的信息。


例程说明：
此例程返回有关当前活动的分页文件的信息。


/>禁用页面文件，重新启动并再次启用它，看看是否可以解决。另外，删除英特尔服务（例如英特尔内容保护HECI服务）似乎已为用户修复了该问题。


在这里，您可以看到驱动程序Netwtw04.sys（英特尔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芯片组，请尝试安装Intel Rapid Storage Technology（RST）来替换Windows中的标准AHCI驱动程序。这似乎也有所帮助。
用户Shayna知道，使用Process Hacker（以admin身份启动）来挂起ACPI.sys线程的问题为他“解决”了问题。因此，如果其他所有步骤都无法解决您的问题，请尝试解决此问题。


在下面的演示中，.Intel HD 630的.4574版本的Intel HD驱动程序igdkmd64.sys导致了问题。 ：



解决方案是将驱动程序更新为至少.4590的版本。


在以下情况下，SYSTEM进程的CPU使用率是由驱动程序stdriverx64.sys引起的。这似乎是音频流驱动程序。因此，如果在WPA中看到此软件/驱动程序，请进行更新。


如果在SYSTEM的调用堆栈中看到名为risdxc64.sys的驱动程序，导致CPU使用率较高，请更新Ricoh PCIe SDXC / MMC主机控制器驱动程序，或者如果没有驱动程序更新对其进行修复，请在设备管理器中禁用SD卡读取器。



此SD卡读取器似乎内置于许多Lenovo设备中。


@stevemidgley用户通过Wdf01000.sys!FxSystemWorkItem::_WorkItemThunk显示了一个更高的CPU使用率新问题



在这里您可以看到驱动程序UDE.sys导致它。

在符号中心



我可以看到它属于调制解调器驱动程序，并且跟踪的PNP数据显示Fibocom L850-GL （LTE调制解调器）作为可能的设备：



解决方案是在设备管理器中禁用调制解调器和USB复合设备。

#2 楼

这可能是由驱动程序或系统加载的其他模块故障引起的。要查看系统进程，可以使用诸如Process Explorer之类的工具。

下载并运行它，然后选择System进程，右键单击并选择Properties：



切换到“线程”选项卡（忽略提到符号的对话框）：



这将显示哪个文件使用了过多的文件。

但是正如其他人在评论中所述，您确实确实需要尽快脱离Preview版本！

#3 楼

关于加载调试符号以增加magicandre1981最佳答案的说明：如果在Windows Performance Analyzer中正确加载符号，请选中​​“跟踪”>“加载符号”后，您将在顶部看到一个进度条，其中包含“加载符号”，其中显示了文件名，并带有几分钟即可完成。此外，您还应该在诊断控制台中看到许多类似以下内容的行：

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

如果您看不到其中任何一条，则可能无法加载调试符号，并且您将无法正确解释您的跟踪。

在我的情况下，最初加载调试符号无效。我已按照以下说明进行了修复：




弄清楚是使用x86还是x64版本的Windows Performance Toolkit。

在Windows的x86版本上，这很容易。在x64版本上，您可以检查任务管理器中的* 32标签。如果不存在，则说明您正在运行x64版本。

请注意，无论
是哪种体系结构，WPT始终安装到程序文件（x86）。


将正确的调试器目录中的dbghelp.dll和symsrv.dll文件复制到Windows Performance Toolkit目录中。在我的系统上，相关目录为：

C:\Program Files (x86)\Windows Kits\Debuggers\x64和
C:\Program Files (x86)\Windows Kits\Windows Performance Toolkit

重新启动Windows Performance Analyzer，以使dbghelp.dll的正确版本为拿起。

#4 楼

我的问题是下载任何内容时（高达4 GHz），CPU使用率高得离谱。我有一个带有Killer WiFi卡的捕食者Helios 300，所以预先安装了Killer驱动程序。我使用Process Explorer进入System的属性→Threads选项卡，发现“ kfeco10x64.sys”导致CPU使用率很高。由于“ kfeco10x64.sys”是杀手级网络服务的一部分，因此我通过运行msconfig并取消选中“铆钉网络”中的每个服务来禁用它。

重新启动后，问题对我来说消失了。最重要的是，下载时似乎没有任何速度降低。我希望这可以帮助面临相同问题的任何人。

#5 楼

@ magicandre1981添加的答案是解决任何问题的关键。
这里没有列出我的案件，但我在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泄漏

#6 楼

我遇到了同样的问题，当我卸下一个RAM模块时，它消失了。似乎有问题。
运行Windows 7（32位）。

#7 楼

首先，所提供的评论和信息非常有用，但是您通常可以以更少的情报来解决问题！我只是使用MSCOFIG.EXE和二进制搜索来隔离有问题的服务。我发现大多数类似问题都是由英特尔软件引起的。我首先禁用任何没有公司名称的服务。然后，我开始介绍英特尔服务。然后进行完整的二进制搜索。通常最多需要一个小时才能在某人的PC上解决该问题。
英特尔从来不是一家优秀的计算机公司，他们的软件证明了这一点。让我们面对现实吧，奔腾架构在发布时已经有十年的历史了。在VAX时代，谁会建立具有分页内存的计算机体系结构？好吧，我不会对您的历史感到厌烦。并不是说我是AMD还是Microsoft的粉丝。也许有一天我们会再次回到构建真实的计算机。