为什么我的 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”时则表示服务禁止拆分。

HOWTO: 使用 DISM 配合脚本批量删除驱动程序

        利用 DISM 或 Pnputil 我们已经能够实现脱机或在线模式批量安装硬件的驱动程序,那么如何能够实现批量卸载已经集成到映像中的驱动程序呢?!

        假设我们的映像编制人员为 Surface 设备创建了定制化的系统映像,并集成了 Surface 的设备驱动程序,现在我们希望编制好的映像可以作为通用映像部署在其他计算机上,这时我们就需要清理已经集成在映像内的驱动程序。

        要卸载映像内集成的第三方驱动程序,我们首先需要列表出来它们,所以为此我们执行如下命令行。

dism /image:c:\ /get-drivers

get-drivers

        利用上述的参考命令我们可以检索到当前映像中已经安装的硬件驱动程序,其中“已发布的名称:oemX.inf”是我们需要记录的数据。接下来使用下例命令行就可以从映像中卸载驱动。

dism /image:c:\ /remove-dirver:oemX.inf[code]

        细心和已经在使用该命令管理的驱动的朋友会注意到,由于映像中第三方驱动可能会很多,有时多大近70个,那么我们就需要一次一次执行上面的卸载驱动命令,将 oemX.inf 从映像中删除,这将是一件令人崩溃的任务。有些朋友可能会利用 Excel 批量转换和生成指令,其实我们完全可以利用批处理命令“For ... Do ...”来实现。

        实现逻辑就是利用 DISM 的 Get-Drivers 参数获取驱动列表,并查找其中的唯一特征,例如下图所示我们能看到所有被列出的第三方驱动程序都不是“内置驱动程序”,那么可以用它来作为检索关键词。

[code]dism /image:c:\ /get-drivers /format:table

get-drivers_table

        我们有了用于检索的关键词,就可以使用“find”来获得准确的驱动列表,可创建变量以生成动态驱动列表,便可以实现动态批量卸载驱动,参考脚本如下:

for /f %%a in ('dism /image:c:\ /get-drivers /format:table ^|find \"|否\"') do (dism /image:c:\ /remove-driver:%%a)

        以上脚本可以从 gOxiA 的 Github 获取。https://github.com/goxia/ITSM/blob/master/remove_driver.bat

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

分页: 61/478 第一页 上页 56 57 58 59 60 61 62 63 64 65 下页 最后页 [ 显示模式: 摘要 | 列表 ]