Windows 服务无法启动：依赖、账号与恢复动作检查
本文适用于 Windows Server 2022、2025 的常规 Windows 服务。服务启动失败，既可能发生在系统尚未成功创建进程时，也可能是应用启动后自行退出。应先保存错误提示和故障时间，确认服务是否承载生产业务，再决定是否重试或修改配置。
用服务名称确认检查对象
“服务”管理界面中的显示名称与服务名称可能不同。命令查询通常使用服务名称，因此先在属性页核对。下面以实际环境中尚需替换的 DemoService 为示例：
# 服务器：只读检查，替换示例服务名称
Get-CimInstance Win32_Service -Filter "Name='DemoService'" |
Select-Object Name, DisplayName, State, StartMode,
StartName, PathName, ExitCode
sc.exe qc DemoService
sc.exe qfailure DemoService
显式写 sc.exe，可避免 Windows PowerShell 中同名别名造成误解。返回字段能帮助确认启动方式、运行身份与程序路径，但某些退出状态仍要结合事件日志和应用日志解释。Win32_Service 文档说明了这些属性的含义。
如果对象查不到，先核查名称、所在机器与安装状态。不要据此立即重新安装服务，以免覆盖原有参数或产生第二个服务实例。
根据失败阶段检查依赖与配置
查看服务的依赖项，确认它们是否已启动以及业务所需的网络、数据库和存储是否可用。系统声明的服务依赖不一定覆盖所有应用级依赖：数据库服务运行，也可能仍处于恢复或初始化阶段。
若服务启动后立即退出，查看应用自己的日志、配置校验结果以及最近的发布记录。配置语法、端口冲突、缺失文件和证书权限都可能导致这种表现。若系统连程序都无法启动，则重点检查程序路径、文件是否存在、执行权限与运行账号。
不要随意添加依赖项、改成延迟启动或让服务循环重试来遮盖错误。先识别真实条件，再决定是否需要调整应用的就绪检测和启动顺序。系统事件的读取方法可结合 Windows 事件查看器进行，应用错误仍应回到对应日志核实。
运行账号需要必要权限
在“登录”页确认服务使用本地账号、域账号还是系统内置身份。账号密码变更、被锁定、登录权限被策略覆盖，或者域连接异常，都可能影响启动。查看故障当时的登录相关记录，并让有权限的管理员核对账号状态。
应用目录可读不等于数据目录可写。逐一检查实际需要的配置、日志、临时文件和网络共享权限。交互用户能打开共享，也不代表服务账号能够访问；映射盘符通常不适合作为后台服务的稳定路径，应使用明确的 UNC 路径并配置对应权限。
不要通过改成 LocalSystem 或给整个磁盘完全控制来验证一切。更合理的方式是列出应用所需资源，授予特定账号最少的访问权限，验证后记录理由和范围。修改身份前先保存原配置，确认依赖该身份的文件及密钥也有恢复方案。
恢复动作应配合故障类型
恢复页可以设置失败后的重启服务等动作，但“服务崩溃”和“以错误状态停止”是否触发动作，受相关配置影响。不能仅凭应用日志出现错误就假定系统一定会自动重启它。
优先选择有等待时间、次数有限并能产生告警的策略，避免短时间反复重启造成数据库重连风暴或日志堆积。对可能重复执行任务的服务，还要确认业务具有幂等或去重机制。不要把“重新启动计算机”设成缺乏论证的通用恢复动作。
变更前保存原有失败次数规则、重置周期和动作设置；命令参数与延迟单位可查阅 sc failure 官方说明。这份命令参考保留在较早版本文档中，实际操作前还应在当前系统运行 sc.exe failure /? 核对帮助。
恢复后检验真实业务
重新启动服务会影响依赖它的会话和任务，应安排在已确认的窗口。验证内容至少包括进程稳定运行、核心接口能够完成一次真实请求，以及日志中没有持续重试。观察时间应覆盖它原先发生故障的周期，而不是只看启动后几秒钟的绿色状态。
如果修改无效，按记录恢复服务配置、账号或权限，再继续定位，避免叠加未知改动。涉及程序升级或数据迁移时，应使用完整的备份与恢复方案，因为恢复服务参数本身无法撤销已经发生的数据变化。