为什么我的 Windows 10 系统会有很多 SVCHOST 进程

        有不少网友反应自己 Windows 10 的系统中会运行很多 svchost.exe 进程,怀疑自己的系统有问题?!其实相对于现在来讲,这是一个正常的现象。

1

         因为微软自 Windows 10 1703 开始重新设计了 Windows 服务的运行机制。对于内存超过 3.5GB 的 Windows 10 系统,其运行的服务将以独立运行的方式通过 Svchost.exe 进程运行。如果你的内存少于 3.5GB,那么这些服务将会自动分配到共享的 Svchost.exe 进程中运行,这也是 1703 版本以前 Windows 服务默认的运行方式。

        分离 Svchost 运行服务所带来的好处是显而易见的:

  • 通过将关键网络服务与主机中的其他非网络服务的隔离,并在网络组件崩溃时添加无缝恢复网络连接的能力,提高了可靠性。
  • 通过消除与隔离共享主机中的行为不当服务相关的故障排除开销,降低了支持成本。
  • 通过提供额外的服务间隔离来提高安全性。
  • 通过允许每项服务设置和权限来提高扩展性。
  • 通过按服务CPU,I/O和内存管理改进资源管理,并增加清晰的诊断数据(报告每个服务的CPU,I/O和网络使用情况。)

        在过去,Windows 将服务与匹配的安全性要求相结合来确定共享的服务主机组。

  • 本地服务
  • 本地服务无网络
  • 本地服务网络受限制
  • 本地系统
  • 本地系统网络受限制
  • 网络服务

        下图是分离和共享服务主机(Svchost.exe)进程的运行对比。

23

        虽然分离机制已经在 1703 及之后版本的 Windows 10 上应用,但是某些服务仍将继续通过分组方式共享服务主机(Svchost.exe)进程。例如,Windows 防火墙(mpssvc - Windows Defender Firewall)和基本筛选引擎(BFE - Base Filtering Engine),远程过程调用(RpcSs - Remote Procedure Call)和 RPC 终结点映射器(RpcEptMapper - RPC Endpoint Mapper)。

        如果需要识别这些分离和继续分组的服务,除了可以通过任务管理器的进程选项卡来查看 Service Host(服务主机)信息意外,还可以通过详细信息选项卡查阅 svchost.exe 的命令行。

4

        此外微软也提供了通过注册表项检查的办法,打开注册表编辑器定位到“HKLM\SYSTEM\CurrentControlSet\Services”下,查看每个服务下“SvcHostSplitDisable”的值即可,当值为“1”时则表示服务禁止拆分。

troubleshooting

排查 Windows 必须关闭所有会话框才能关闭 MMC 的故障问题

        在 Windows 系统的日常操作中,我们经常会遇到这样一种故障问题,当要关闭基于 Microsoft 管理控制台(MMC)的程序时,会提示我们必须先关闭所有会话框,但实际上我们已经关闭了 MMC 下对应设置的属性对话框,当反复切换几次后,才能正常关闭 MMC。

hyper-v_mmc_error

        这种问题在 Hyper-V 管理器、服务管理器中尤为突出。那么造成这种问题出现的原因是什么呢?!使用何种工具能协助我们排查这类故障?!

        我们可以使用微软官方工具 Spy++ 来排查这类问题,Spy++隶属于 Visual Studio 的组件,它支持绿色方式运行,利用 Spy++ 可执行下列任务:

  • 显示系统对象之间关系的图形树,这些对象包括:进程、线程和窗口。
  • 搜索指定窗口、线程、进程或消息的属性。
  • 直接从视图中选择窗口、线程、进程或消息。
  • 使用查找程序工具,通过鼠标指针定位选择窗口。
  • 使用复杂消息日志选择参数设置消息选项。

        对于本案例要使用 Spy++ 排查原因,需要在故障重现时启动 Spy++,然后切换到线程视图,再点击工具栏上的“Find Window”图标,通过拖拽标靶图标到要监视的 Windows 对话框上来定位窗口。

FindWindow

        之后在弹出的 Property Inspector 对话框中单击 Synchronize 按钮,即可在 Spy++ 的线程列表视图中,同步定位到这个窗口。

PropertyInspector

        接下来便可审查这个进程中的子线程,看看是否存在可疑项。本例中发现的可疑线程是必应输入法,当尝试切换输入法后,故障消失,可正常关闭 MMC。

Trouble

        而对于大多数安装了第三方输入法,尤其是使用搜狗输入法的朋友,相信这类问题更为常见,所以可切换关闭搜狗输入法,该问题便会消失。此外,如果你尝试使用 Spy++ 进行排错,需要注意它区分 32 和 64 位版本。有关 Spy++ 的详细信息可参考微软官方资料。

https://docs.microsoft.com/en-us/visualstudio/debugger/spy-increment-help?view=vs-2017

在 Azure 中创建 Upgrade Readiness 以管理 Windows 10 升级

        Windows 7 EOS 的日子所剩无几,更多的企业开始着手将更多的设备升级到 Windows 10,但是 IT 人员心里都非常清楚升级到新操作系统是一项非常具有挑战性的工作,已交付的众多应用程序和驱动是否兼容新的 Windows 10,是否具有潜在的兼容性问题,它们成为 IT 不能不面对的问题。

        有不少同行朋友向 gOxiA 咨询微软是否提供有一种工具,可以帮助评估企业 IT 化境下的 Windows 设备,是否具体升级到 Windows 10 的能力,并且只需投入很少的精力和成本,最好基于云来实现?!

        Windows 10 的 Upgrade Readiness 工具便可满足这些用户的需求,其利用 Windows 诊断数据功能,收集系统、应用程序和驱动数据以供分析,以便帮助 IT 人员确定可能阻止升级的兼容性问题。

        Upgrade Readiness 提供了一种可视化的工作流程,以及丰富的计算机和应用程序库,为用户提供有关应用程序和驱动兼容性相关问题的指导和见解,以及建议的修复。并允许将收集的数据导出到常用的软件部署工具中,如SCCM。

        通过下图我们来了解一下 Upgrade Readinesss 在典型场景中的工作方式。

升级准备架构

        在用户计算机上启用 Windows 诊断数据后,用户计算机通过微软数据管理服务将计算机、应用程序和驱动诊断数据发送到 Azure,在 Upgrade Readiness 就绪后,其会将分析诊断数据推送到 OMS 工作区,然后我们便可以使用 Upgrade Readiness solution 来规划和管理 Windows 10 升级。

        接下来 gOxiA 将演示如何在 Azure 中创建 Upgrade Readiness,首先登录到 Azue ortal 创建资源,通过搜索框找到“Upgrade Readiness”,并创建该资源。

0

        随后跟随向导创建OMS 工作区,如下图所示。

1

2

        等待片刻待 Upgrade Readiness 创建完毕后,便可进入 Upgrade Readiness solution 面板,在 Upgrade Readiness Settings 中我们能够获取到“商用 ID 键”,复制它到后面的 Upgrade Readiness 部署脚本中,即可在客户端计算机上执行以收集相关数据。此外,我们还可以根据需要选择 Windows 10 的版本,如当前最新的为 1809,待客户端上执行脚本后,便可以执行“生成报告”。

4

        Upgrade Readiness 部署脚本可从微软下载中心获取到,其下载地址是:

https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409

        下载到 Upgrade Readiness 部署脚本后,解压缩对于较小规模的环境,可以选择使用 Pilot 版本的脚本,并需要编辑 RunConfig.bat 将前面提到的商业ID 填写到“set commerciallDValue”中。

5

        最后在一台准备升级到 Windows 10 的 Windows 7 设备上执行 Pilot 版本的脚本,如果运行成功,则回到 Azure Portal 的 Upgrade Readiness Settings 页面下,点击生成报告。(PS:通常需要等待一段时间报表才会生成数据。)

3

        如下图所示便是 Upgrade Readiness 生成的分析报表,我们可以基于它管理我们的 Windows 10 升级过程。

6

分页: 28/148 第一页 上页 23 24 25 26 27 28 29 30 31 32 下页 最后页 [ 显示模式: 摘要 | 列表 ]