Windows 服务

定义

Windows 服务是 Windows NT 体系中专供后台长期运行的进程形式，其程序必须遵循服务控制管理器规定的接口约定，才能被系统纳入管理^[1]。按微软技术文档的界定，凡是受 SCM 执行与控制的程序都属于这一范畴，因此它们早期也被称作 NT 服务^[2]。在概念上，这类程序与 Unix 家族中的守护进程相近^[1]。

同一个服务往往并存三个名字：记录配置的注册表内部名称、用于命令行操作的短名称，以及在图形管理工具中显示的友善名称^[2]。一个可执行文件既可以只承载自身，也可以通过共享宿主进程同时容纳多个服务^[3]。从实现角度看，所谓服务程序本质上只是调用了若干特定系统函数的可执行映像，借助这些函数完成登记、上报状态和响应控制指令^[4]。

从内核驱动到用户态进程都可以注册为服务条目，区别只在注册表中的类型取值不同^[5]。例如打印后台处理、事件日志、任务计划以及各类网络组件，都是以服务形态存在的操作系统部件^[4]。

原理

服务的生命周期由服务控制管理器集中掌管。该组件运行在名为 services.exe 的系统进程中，由系统初始化阶段的 wininit 进程拉起，其主函数会读取注册表两处位置来建立内部数据库：一处列出服务组的先后次序，另一处保存所有服务与驱动的实际配置^[5]。SCM 的核心职责包括维护已安装服务的数据库、在开机或按需时启动服务、枚举服务、报告运行状态、转发控制请求以及锁定服务数据库^[6]。

交互过程遵循一套固定的回调约定。服务程序的入口是 main 之类的普通入口函数，启动后必须尽快调用 StartServiceCtrlDispatcher 向 SCM 报到，该调用在进程内所有服务停止之前不会返回^[7]。真正的业务代码写在 ServiceMain 里，它需要先用 RegisterServiceCtrlHandlerEx 注册控制处理函数，再通过 SetServiceStatus 上报启动中、运行中、停止中、已停止等状态^[6]。SCM 与具体服务进程之间通过命名管道传递控制请求，分发线程负责在收到请求时创建线程或调用对应的处理函数^[7]。若启动阶段处理不当，ServiceMain 大约只有 80 秒时间完成第一次状态上报，超时会被判为启动失败^[8]。

启动顺序由组与依赖关系共同约束。SCM 读取每个服务的分组取值和 DependOnGroup、DependOnService 项，据此排定先后；某服务被停用时，依赖它的服务也无法启动^[3][9]。共享进程机制则用于压低资源开销：以 svchost.exe 为例，首次以某个组参数启动时它会从注册表读出该组包含的服务名列表并告知 SCM，之后再要启动同组服务，SCM 不再新建进程，而是向已有进程发送启动命令，由后者加载对应的 ServiceDll^[10]。据微软 2003 年给出的数据，共享宿主中单个服务的最小工作集约 150 KB，独立进程则约需 800 KB^[10]。

SCM 还承担失败处置。为服务配置恢复动作后，进程异常终止时 SCM 可按预设间隔重启服务或重启系统，重启动作又由两段计时参数约束：恢复间隔决定失败后等待多久再动手，重置周期决定连续成功运行多久后把失败计数清零^[11]。自 Windows Vista 起，服务即使没有崩溃，也能在发现严重内存泄漏等非致命错误时主动通知 SCM 触发恢复动作^[11]。

发展历程

服务机制随 NT 内核一同问世。Windows NT 3.1 于 1993 年 7 月 27 日发布，是这一系列的第一个版本，服务支持只存在于 NT 血统的系统中，基于 MS-DOS 的 Windows 95、98 等家用版本并不具备^[12][2]。共享服务进程的底层能力自 NT 3.1 起就已具备，而负责承载共享服务的 svchost.exe 进程则到 Windows 2000 才正式出现^[10]。

Windows Vista 是服务安全模型的分水岭。此前所有服务与首个登录用户同处 0 号会话，服务窗口可被其他进程用窗口消息操作，存在被利用提升权限的空间；Vista 起 0 号会话被改为非交互，只留系统进程和服务，首个用户改在 1 号会话登录，后续用户依次使用 2、3 号会话^[13]。为兼顾沿用旧写法的程序，系统同时引入交互服务侦测服务 UI0Detect，在 0 号会话弹出对话框时提醒用户切换查看^[13]。同期还增加了为每个服务分配安全标识符、按配置文件只授予必要权限等加固手段^[14]。

Vista 同时引入延迟启动选项，让部分服务在系统启动完成稍后再运行，以缩短到达桌面的等待时间，不过并非所有服务都支持这一方式^[1]。共享宿主的策略后来又发生反转：从 Windows 10 1903 版开始，在内存大于 3.5 GB 的客户端系统上，服务不再合并进共享宿主进程，而是各自独立运行，隔离性与可调试性提高，代价是内存开销有所增加^[10]。

应用

在系统层面，大量基础功能由服务承载。打印后台处理服务负责打印任务，停用后各类软件的打印功能都会失效；基本筛选引擎为防火墙提供数据过滤能力；DHCP 客户端负责自动获取 IP 地址，关闭后机器将因缺少正确地址而无法上网^[15]。后台智能传输服务为系统更新等场景提供后台下载，并能自行调节速率以减少对正常使用的影响^[15]。

在服务器与开发场景中，服务是常驻程序的默认形态。需要长期监听套接字或命名管道、要求秒级响应、并希望在崩溃后自动恢复的业务，通常做成服务而不是计划任务或登录时启动的常驻程序，后者在用户注销后即消失^[16]。以 .NET 为例，官方做法是采用 Worker Service 模板并调用 AddWindowsService，使同一份代码既能作为控制台程序调试，也能以服务身份安装运行^[16]。原生开发则可用 Visual Studio、Delphi 等工具编写，只要程序正确处理 SCM 发来的启动、停止与暂停消息即可^[1]。

日常管理有三条路径：管理工具中的服务扩展可查看列表并启停、修改启动类型、指定运行账户、配置失败恢复与依赖关系；命令行工具 sc.exe 覆盖同样范围，自 Windows Server 2003 起还可安装和卸载服务；PowerShell 则提供 Get-Service、New-Service、Restart-Service 等命令完成同类操作^[1]。net 命令与任务管理器也能完成部分启停与查看工作^[1]。

局限

最直观的限制是无法与用户交互。自 Vista 起服务一律在隔离的 0 号会话中运行，既不能直接弹出窗口，也访问不到任何登录用户的桌面，依赖窗口消息与用户程序通信的旧服务会失灵^[17]。服务在 0 号会话中创建的命名对象默认落在这个会话的私有命名空间里，用户程序按常规前缀往往打不开，需要改用全局前缀命名^[13]。较新版本的 Windows 已移除切换到 0 号会话查看界面的入口，进一步压缩了旧式交互服务的生存空间^[18]。

共享进程带来资源节约，也带来故障连带。多个服务挤在同一进程内，只要其中一个出现未处理异常，整个进程连同其承载的其他服务会一起退出^[10]。对使用者而言，从进程层面也难以分清究竟是哪个服务在占用 CPU、磁盘或网络，资源监视器大多只统计到进程粒度^[10]。此外，服务之间还存在启动顺序耦合：被依赖的服务若设成禁用，依赖方就根本起不来^[9]。

配置与运维上的风险同样不可忽略。创建服务时若不加指定，运行账户默认为权限最高的本地系统账户，一旦服务本身存在缺陷，影响面会被放大^[16]。停止处理若未妥善设计，服务可能对停止指令长期不响应，只能强制结束进程^[16]。而服务通常在用户登录前就已启动，调试器无法像普通程序那样直接拉起它，通常要把自动启动改为手动，或为程序加入以控制台模式运行的分支^[8]。

参见

• 服务控制管理器 —— 负责登记、启动、停止 Windows 服务并转发控制指令的系统组件。

• svchost.exe —— 可同时承载多个服务、用于实现共享服务进程的宿主程序。

• Windows 注册表 —— 存放服务配置、启动类型与依赖关系的数据库。

• 守护进程 —— Unix 类系统中与服务概念相对应的后台程序。

• 设备驱动程序 —— 在 Windows 中以服务条目注册、由 SCM 或即插即用机制加载的一类特殊组件。

• Windows 任务管理器 —— 可查看已安装服务并执行启停操作的图形工具。