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

我注意到一段时间以来，我的系统死机了，这可能是由于系统进程导致的CPU使用率过高引起的。

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

您可以在下面的屏幕快照中查看问题本身和正在运行的进程：

有时，CPU使用率达到90％，但平均使用率约为40-65％。

我的电脑参数：

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

我将不胜感激！问候。

-更新-

当下面的用户发布了一个很好的答案时，我注意到该进程Arthurx.sys占用了系统中最多的CPU ，简单的Google告诉它这是TPLink驱动程序（一个wifi适配器，我已经在2周前购买了！）驱动程序已从Windows MSDN安装了Windows XP，但也尝试从附带的CD安装驱动程序，但这无济于事。从系统开始，它仅使用5％的CPU，但是经过2-4个小时的工作后，它逐渐增长并达到40-60％的CPU使用率。

设备名称： TPLink WN722N

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

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

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

这将显示哪个文件正在使用过多的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的呼叫时！Vi KeTrimWorkerThreadRoutine，ntoskrnl.exe！MM 验证程序 TrimMemory，ntoskrnl.exe！验证程序 KeLeaveCriticalRegion，这意味着您已启用驱动程序验证程序。这也极大地损害了性能并导致高系统使用率。禁用驱动程序验证程序并重新启动。

在此演示中，驱动程序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使用率来自SRTSP64.SYSsymantec。

将您使用的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。

在这里，您应该安装英特尔提供的最新驱动程序以进行修复。

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 / Blue-Ray Drive，则在HDD caddy上更改跳线，以便在旧HDD旁边安装SSD

• 禁用此用户建议的某些设备
• 如果您使用英特尔芯片组，请尝试安装英特尔快速存储技术（RST）来替换Windows中的标准AHCI驱动程序。这似乎也有所帮助。
• 用户Shayna 发现，使用Process Hacker（以admin身份启动）来挂起ACPI.sys的线程会为他“解决”该问题。因此，如果所有其他步骤都无法解决您的问题，请尝试他的解决方法。

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

解决方案是使用至少.4590的版本更新到驱动程序。

在以下情况下，SYSTEM进程的CPU使用率是由驱动程序引起的 stdriverx64.sys

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

如果您risdxc64.sys在SYSTEM的调用堆栈中看到一个导致CPU使用率很高的驱动程序，请更新Ricoh PCIe SDXC / MMC主机控制器驱动程序，或者在设备管理器中禁用SD卡读取器（如果没有驱动程序更新可以解决问题）。

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

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

在这里，您可以看到引起它的驱动程序UDE.sys。

在符号中心

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

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

关于加载调试符号以增加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 Performance Toolkit的x86还是x64版本。

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

   请注意，无论采用哪种体系结构，WPT始终都安装到程序文件（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 Performance Analyzer，以获取正确版本的dbghelp.dll。

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

我有同样的问题，当我卸下一个RAM模块时，它消失了。看来是有毛病。运行Windows 7（32位）。