服务器上运行的服务自动停止，碰到这种情况会耗费不少精力处理。尤其是半夜收到告警，登录服务器看到服务状态显示已停止，手动启动，过一段时间再次停止，反复排查找不到根源。Windows Server中服务自动停止，诱因集中在几类，顺着顺序排查，大多可以定位根本问题。
最先查看事件查看器，而不是服务管理器。服务意外崩溃，服务控制管理器会在系统日志留下记录。事件ID7031、7034是关键线索，7031代表服务意外终止，7034代表服务无响应。查看这条事件之前的系统日志，确认服务停止前有没有其他服务报错、应用崩溃、磁盘内存告警信息。微软排障文档提到一处容易忽略的情况，服务配置触发器启动，恢复操作重置期限设置为0，服务崩溃后SCM会持续反复尝试重启，恢复任务持续占用关键资源，登录阶段直接造成系统卡死。遇到这类情况，打开事件查看器查找事件ID1000，定位发生崩溃的具体服务。
服务依赖关系是另一类高频故障点。服务本身没有故障，但依赖的上游服务停止或者被禁用，自身无法启动。管理员权限打开命令提示符，执行sc qc 服务名，查看该服务依赖列表。Netlogon举例，依赖LanmanServer和LanmanWorkstation，任意一项设置手动或者禁用，Netlogon启动报错1068，提示依赖服务或组无法启动。排查时逐个检查依赖服务，确认启动类型为自动，运行状态正常。如果某个依赖服务同样停止，继续追溯它的依赖项，找到故障源头。
服务恢复策略配置不当，小故障会持续扩大。Windows服务默认崩溃之后不会自动重启，SCM只记录错误日志。半夜收到告警，就是因为服务崩溃之后没有自动拉起。右键对应服务，打开属性，切换恢复选项卡，第一次失败、第二次失败、后续失败全部设置重新启动服务，重置失败计数设置一天，也就是86400秒。这个配置含义，服务崩溃SCM自动尝试重启，一天之内多次崩溃，失败计数不会重置，恢复策略按阶梯执行。有一处坑需要注意，重置失败计数填0，失败计数永远不会清零，服务反复崩溃，SCM持续执行恢复动作，部分触发器启动服务会造成系统卡死，这个参数不要填0，设置一天比较稳妥。
ServerManager管理工具出现停止闪退，和普通服务停止不是同一类问题。打开服务器管理器，短暂加载之后闪退，弹出“ServerManager.exe - This application could not be started”提示，根源大多是底层组件异常。最常见原因是Server Manager用户配置缓存损坏，路径%localappdata%Microsoft_Corporation，文件夹名称以ServerManager.exe_StrongName_开头，删除这个文件夹，下次打开服务器管理器，系统自动重建干净配置。该操作不会改动服务器角色和功能，仅清理界面缓存。
删除缓存无法解决问题，就要排查系统组件。服务器管理器依托MMC、.NET Framework和WMI运行。WinRM服务未启动，服务器管理器初始化阶段卡死报错。管理员权限执行winrm quickconfig，自动修复监听器配置并启动服务，提示已启动，执行Restart-Service WinRM刷新状态。WMI服务禁用或者启动失败，服务器管理器读取不到系统数据，同样会崩溃。检查Windows Management Instrumentation服务，启动类型自动并且正常运行。WMI无法启动，需要重建WMI存储库，命令winmgmt /salvagerepository或者winmgmt /resetrepository，这项操作存在风险，执行前建议对系统盘创建快照。
系统文件损坏属于更深层故障。管理员权限打开CMD，执行sfc /scannow，扫描并修复受保护系统文件，耗时十到十五分钟。扫描提示找到损坏文件无法修复，继续执行DISM /Online /Cleanup-Image /RestoreHealth修复系统镜像，完成后再次执行sfc /scannow确认修复。两条命令配合，基本可以处理系统文件缺失损坏引发的服务启动失败。
还有容易忽略的服务登录账户权限问题。部分服务使用域账户或者本地特定账户运行，账户密码修改、过期、被禁用，服务启动失败，事件日志一般会记录登录失败相关信息。打开服务属性，切换登录选项卡，查看运行账户。密码近期修改，重新录入密码，或者切换为Local System账户测试。安全软件、组策略也会限制服务启动权限，域环境服务器重点检查近期推送策略是否存在相关限制。
以上排查全部做完，服务依旧频繁停止，可以部署监控脚本兜底。编写简单PowerShell脚本，每五分钟检测关键服务状态，状态非Running就执行Start-Service启动。脚本逻辑简单，Get-Service -Name 服务名读取状态，判断服务停止就启动。脚本加入任务计划程序，设置定时运行，权限选择不管用户是否登录都运行。这个办法只能临时维持业务，无法根除故障，但业务不会因为服务停止中断。脚本增加日志记录，每次重启写入时间戳和服务名称，积累日志，方便后续分析停止频率规律，定位根源。
服务自动停止排查流程固定，优先查看事件日志定位崩溃服务，检查依赖关系确认上游服务正常，核对恢复策略保证崩溃自动重启。如果故障对象是ServerManager，清理缓存、修复组件、扫描系统文件依次排查。大部分情况排查到第三步就能定位问题，剩下按照步骤修复即可。