已停止的Windows服务自动启动的触发原因有哪些

目前已明确的两类触发场景如下：

• 服务启动类型设置为「自动」时，服务器重启后SCM（服务控制管理器）会按加载顺序同步启动对应服务
• 管理人员通过服务面板、命令行、管理工具等手动强制启动服务

除上述场景外，以下情况也会触发已停止的Windows服务自动启动：

• 服务恢复策略触发：打开服务属性面板的「恢复」选项卡，如果服务失败（异常退出、崩溃、被非预期终止，包括手动在任务管理器结束服务进程的场景）的响应规则被配置为「重新启动服务」，系统会按照配置的延迟时间自动拉起服务；部分配置还会指定失败后运行指定脚本/程序，间接完成服务启动。
• 触发式启动（Trigger Start）规则命中：从Windows 7/Server 2008 R2开始，系统支持服务触发启动机制，大量内置服务默认配置为「手动（触发启动）」类型（服务管理器中启动类型列会显示为「手动」，括号备注触发启动，很容易被误判为不会自动运行），你手动停止服务后，只要命中预设触发条件——比如特定设备插入、网络连通、域环境就绪、特定系统事件写入日志、防火墙规则变更——SCM就会自动启动对应服务。
• 依赖服务联动拉起：如果其他运行中/正在启动的服务配置了对当前停止服务的依赖关系，SCM会按照依赖顺序，自动先启动所有处于停止状态的依赖服务，再启动上层服务。比如手动启动IIS的W3SVC服务时，若依赖的Windows Process Activation Service处于停止状态，系统会自动启动该服务，无需人工干预。
• 计划任务触发：系统内置、第三方软件或管理员创建的计划任务，若配置了在特定时间、特定事件（用户登录、网络连接建立、磁盘空闲、系统日志产生指定事件）触发时执行服务启动命令（常见命令为net start 服务名、sc start 服务名），条件满足时就会自动拉起对应停止的服务。不少第三方软件会在安装时静默创建这类计划任务做服务保活，不会在服务自身配置中暴露相关逻辑。
• 软件/驱动自带的守护进程拉起：杀毒软件、EDR终端管理软件、数据库、业务中间件等程序通常会自带独立的守护进程/内核驱动，持续轮询关联服务的运行状态，一旦检测到服务被停止，会立即执行启动操作。这类守护逻辑优先级通常高于系统自带的服务恢复配置，哪怕你把服务恢复规则改成无操作，也会被拉起；部分系统核心服务也有类似的系统级守护逻辑。
• 组策略（本地/域）强制启动：若配置了本地组策略或域组策略指定某服务必须处于运行状态，组策略周期性刷新（默认90分钟为周期，存在随机偏移，执行gpupdate /force会立即触发刷新）时，一旦检测到对应服务处于停止状态，会自动将其启动。域环境下这类策略通常由域管理员统一推送，本地修改的服务状态会被策略强制覆盖。
• 系统更新、功能配置变更触发：Windows安装系统更新、启用/关闭系统功能（比如安装IIS组件、开启Hyper-V、配置远程桌面服务）时，相关的系统组件、更新安装程序会自动启动关联服务，不受之前服务停止状态的影响。
• COM组件激活触发：部分服务配置了COM激活规则，当有本地/远程程序调用该服务对应的COM组件接口时，系统会自动启动对应的服务响应请求，最典型的比如Distributed Transaction Coordinator（DTC）服务，手动停止后只要有程序调用对应的DTC接口，就会被自动拉起，这类逻辑常见于RPC类、远程管理类系统服务。

内容的提问来源于stack exchange，提问作者CM05