windows服务崩溃后不会自动恢复，除非明确配置恢复选项；默认仅“停止”而不干预，且仅运行中崩溃触发策略，启动失败需依赖声明或延迟启动来规避。
windows 系统服务崩溃后不会自动恢复，除非你明确配置了恢复选项。默认情况下，服务意外退出只是“停止”，系统不会干预——这正是多数自研服务或第三方后台进程持续离线的根源。关键在于区分「启动失败」和「运行中崩溃」：只有后者才会触发恢复策略，而前者需靠依赖声明、延迟启动或健康检查前置来规避。
服务属性界面快速启用自动重启
这是最直观、适合单个服务调试的方式：
- 打开 services.msc，找到目标服务（如 MyAppService），右键 → “属性” → 切换到“恢复”选项卡
- 三项失败动作均设为“重新启动此服务”——注意 GUI 只暴露前两阶，第三阶实际生效需配合 sc failure 或注册表补全
- “重置失败计数”建议填 1（小时），避免短时异常累积导致后续动作被跳过
- 勾选“如果服务无法启动，运行以下程序”，可填日志记录命令：
C:\Windows\System32\eventcreate.exe /t ERROR /id 999 /l APPLICATION /d "MyAppService failed to start"
sc failure 命令精准控制三阶恢复行为
图形界面无法完整配置所有阶段，真正可靠的配置必须用 sc failure 命令，它支持毫秒级延迟与混合动作：
- 格式为：sc failure "服务名" reset=86400 actions= restart/60000/restart/120000/run/300000
- 其中 reset=86400 表示 24 小时后清零失败计数，否则第三阶永远不触发
- 每个 restart/xxx 表示延迟 xxx 毫秒后重启；run/xxx 表示延迟后执行指定程序（脚本路径需绝对且有执行权限）
- 配置完成后必须执行 sc stop && sc start 才能加载新策略，仅修改不重启服务无效
预防启动失败比处理崩溃更重要
很多服务“起不来”根本不是崩溃，而是启动阶段就失败（比如数据库未就绪、端口被占、配置文件缺失），这时恢复选项完全不生效：
- 用 sc config "MyAppService" depend= "MSSQLSERVER" 显式声明依赖项，让 SCM 等待依赖服务就绪后再启动
- 设置启动延迟：sc config "MyAppService" start= delayed-auto，避开系统初始化高峰
- 在服务自身逻辑中加入就绪检查（如监听端口成功、连接 DB 成功）再上报 SCM 启动完成，避免“假启动”
- 若服务需桌面交互或访问用户配置，确认其登录账户具备相应权限，否则即使显示“正在运行”也可能静默退出
验证与日常监控建议
配完不验证等于没配。建议建立最小闭环验证机制：
- 手动停止服务：sc stop "MyAppService"，观察几秒内是否自动重启（状态栏变“正在启动”）
- 查看事件查看器 → Windows 日志 → 系统，筛选事件 ID 7036（服务状态变更）和 7031（服务意外终止）
- 对关键服务添加简单心跳检测：每分钟用 PowerShell 调用 Get-Service MyAppService | ? Status -eq Running，失败则发邮件或写入自定义日志
- 避免把“重启计算机”设为后续动作——除非是极少数核心基础设施服务，否则可能引发连锁故障
