☰

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

tag-icon • tag-icon windows windows-8 performance troubleshooting cpu-usage
解决“系统”进程 CPU 使用率过高的问题

我注意到有时我的系统会冻结，这可能是由于系统进程导致的 CPU 使用率过高造成的。

我正在运行的所有应用程序是 Skype、TeamSpeak 和 Chrome，所以它绝对不应该占用那么多 CPU。

您可以在下面的屏幕截图中看到问题本身和正在运行的进程：

在此处输入图片描述

有时 CPU 使用率会达到 90%，但平均使用率在 40-65% 左右。

我的电脑参数：

  • Windows 8（客户预览版）
  • 英特尔酷睿 i3 - 2350M
  • 8 GB 内存

我将非常感激任何帮助！问候。

- 更新 -

由于下面的用户发布了一个很好的答案，我注意到系统中消耗最多 CPU 的进程名为Arthurx.sys，简单的谷歌告诉它是 TPLink 驱动程序（一个 wifi 适配器，我大约 2 周前买的！）驱动程序已从 Windows MSDN 安装，但也尝试从附带的 CD 安装驱动程序，但这没有帮助。从系统启动开始，它只使用了 5% 的 CPU，但经过 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，请使用SDK/WPT 版本 15086。

在此处输入图片描述 （其他所有条目均可取消选择）

现在运行WPRUI.exe，选择First Level，在资源选择下CPU使用率并点击开始。

在此处输入图片描述

现在捕获 1 分钟的 CPU 使用率。1 分钟后，单击节省。

现在使用 Windows Performance Analyzer 分析生成的 ETL 文件通过将图形拖放CPU Usage (sampled)到analysis pane并按图中所示对列进行排序：

在此处输入图片描述

在 WPA 内部，加载调试符号并展开SYSTEM进程的Stack，本demo中CPU占用来源于nVIDIA驱动。

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

在此处输入图片描述

当您看到类似这样的呼叫时ntoskrnl.exe！六KeTrimWorkerThreadRoutine，ntoskrnl.exe！Mm验证者TrimMemory，ntoskrnl.exe！验证者离开关键区域，这意味着您已启用驱动程序验证程序。这也会严重损害性能并导致系统使用率过高。禁用驱动程序验证程序然后重新启动。

在此处输入图片描述

在这个演示中，驱动程序iai2ce.sys（Intel 串行 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驱动程序：

在此处输入图片描述

因此请联系您的 IT 部门以了解如何解决 Citrix 问题。

在这个演示中，该函数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)

在此处输入图片描述

确保您的主机文件不太大，以避免这种情况。

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

在此处输入图片描述

将您使用的赛门铁克产品更新至最新版本。

这里的 CPU 使用率来自 AMD GPU 驱动程序 (atikmdag.sys)

在此处输入图片描述

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

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

在此处输入图片描述

据我所知，这些文件是 Trend Micro AV 套件的一部分。更新该工具或将其删除。

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

在此处输入图片描述

该函数获取有关页面文件的信息。

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

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

在这里，您可以看到驱动程序Netwtw04.sys（Intel Wifi 驱动程序）调用该函数flushCompleteAllPendingFlushRequests，这会导致 CPU 使用率过高。

在此处输入图片描述

因为调试符号被加载，所以使用了 Windows 内置驱动程序。只有在这里我们才能获得调试符号来查看函数名称的调用堆栈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 主题，我列出了一些建议：

  • 确保 CPU 不会因 CPU 风扇中的灰尘而过热
  • 更新或重新刷新（相同） BIOS/UEFI
  • 加载默认 BIOS/UEFI 设置
  • 确保电池没有损坏，从笔记本电脑中取出电池或在设备管理器中禁用电池。
  • 更换跳线 在硬盘托架上如果你已经用 Caddy 替换了 DVD/蓝光驱动器，以便在旧 HDD 旁边安装 SSD

在此处输入图片描述

在以下演示中，igdkmd64.sysIntel HD 630 的 .4574 版 Intel HD 驱动程序导致了此问题：

在此处输入图片描述

解决办法是更新驱动程序版本至少为 .4590。

以下情况是由于驱动程序导致 SYSTEM 进程 CPU 占用过高stdriverx64.sys

在此处输入图片描述

这似乎是一个音频流驱动程序。因此，如果您在 WPA 中看到此信息，请更新此软件/驱动程序。

如果您看到risdxc64.sysSYSTEM 调用堆栈中调用的驱动程序导致 CPU 使用率过高，请更新Ricoh PCIe SDXC/MMC 主机控制器如果没有驱动程序更新可以修复此问题，请卸载驱动程序或在设备管理器中禁用 SD 卡读卡器。

在此处输入图片描述

这款 SD 卡读卡器似乎内置于许多联想设备中。

用户@stevemidgley 展示了一个新问题，即 CPU 使用率过高Wdf01000.sys!FxSystemWorkItem::_WorkItemThunk

在此处输入图片描述

在这里您可以看到导致该问题的驱动程序 UDE.sys。

在符号中心

在此处输入图片描述

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

在此处输入图片描述

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

用户@fajar假设以下情况：

在此处输入图片描述

这里的 CPU 使用率很小，但如果你将视图更改为 DPC/ISR 使用率

在此处输入图片描述

您可以看到 avgNetHub.sys 驱动程序导致大量 DPC 使用

在此处输入图片描述

该名称表明此驱动程序是 AVG 防病毒软件的一部分。因此，如果您在跟踪中看到此信息，请更新软件或将其删除。

答案2

这可能是由系统加载的驱动程序或其他模块故障引起的。要查看系统进程内部，您可以使用类似进程探索器。

下载并运行，然后选择系统进程，右键单击并选择属性：

在此处输入图片描述

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

在此处输入图片描述

这将显示哪个文件占用了过多的 CPU，然后您可以尝试对其进行诊断。

然而，正如其他人在评论中所说的那样，您确实需要尽快摆脱预览版本！

答案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

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

在我的情况下，最初加载调试符号不起作用。我通过以下方法修复了它这些说明：

  1. 确定您正在使用的 Windows 性能工具包是 x86 版本还是 x64 版本。

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

    请注意，无论架构如何，WPT 总是安装到 Program Files (x86)。

  2. 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

  3. 重新启动 Windows 性能分析器，以便获取正确版本的 dbghelp.dll。

答案4

回答添加者@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 泄漏和相同的堆栈

相关内容