事实证明,这与Internet连接共享(ICS)有关。
在下文中,我想描述我如何得出这个结论,希望它可以帮助其他有类似问题的人。
第一步是识别引起问题的服务。尽管Windows自己的任务管理器最近也已经学会了这样做,但是我使用了Process Hacker,它也可以编辑服务的配置。
双击有问题的svchost.exe
实例,然后选择“ 服务”选项卡,显示该进程中正在运行的服务:
svchost.exe
可以同时托管许多Windows服务,因此很难确定哪个服务引起了问题。尽管有足够的RAM可用时,Windows 10的最新版本通常会隔离服务,但某些服务仍共享一个进程。
在这种情况下,找出导致问题的服务的最简单方法是将它们分开。
Process Hacker可以做到这一点。在其主窗口的“ 服务”选项卡中,我们可以配置服务是否可以共享流程:
需要将三个可疑服务中的至少两个配置为“ 自己的进程”,以确保将来将它们分开。
显然,Windows Defender不喜欢用户干预其服务的配置,因此要成功更改此设置,我需要
- 授予管理员组对该服务的完全访问权限,
- 禁用服务,
- 重新启动,以便服务停止(无法单独停止),
- 将服务类型更改为Own Process并重新启用服务(将其设置为Auto Start),然后
- 最后一次重新启动以应用这些更改。
在那之后,违规行为svchost.exe
仅托管一项服务,因此我们确实有一个疑问:
为了分析防火墙服务中发生的事情,我们将使用Windows ADK中的Windows Performance Recorder和Windows Performance Analyzer工具。
我们将从记录一些数据开始。当嫌疑人svchost.exe
在后台移动时,下载此文件,将其添加为配置文件,像这样设置Windows Performance Recorder并开始录制:
让录音运行30秒钟左右,然后保存录音。保存后,单击“ 在WPA中打开”立即将其打开以进行分析。
这是事情开始变得棘手的地方。就我而言,我需要来自@ magicandre1981的提示,以便在系统活动 → 通用事件下找到正确的位置。那里,RPC事件的数量看起来很高:
下钻时,Windows Defender的防火墙的svchost.exe
是展示了大量的服务器的侧面win:Start
和win:Stop
事件:
下一步是找出谁发送了这些RPC调用。通过查看客户端,另一个svchost.exe
实例看起来可疑:
确实,Process Hacker无法检测到在该进程中运行的服务,这也一直导致CPU负载:
在这种情况下,Windows的任务管理器成功识别了该服务:
确实,服务停留在启动状态。我已禁用它,因为我不需要它,并且下次重启后CPU负载已恢复正常。
我想对@HelpingHand和@ magicandre1981表示感谢,他们的评论使之成为可能。
正如后来在TenForums帖子中发现的那样,重置Windows Defender防火墙可以解决此问题。
Sc config BFE type= own
Sc config MpsSvc type= own