PowerShell监控Windows服务报错需主动识别异常状态而非被动抓包，包括Start Pending、Stop Pending、Paused等非正常状态，结合Get-Service、系统事件日志（ID 7000/7001/7022/7023/7031）及服务自身日志定位根因，并用try/catch捕获详细错误、验证启动结果、记录完整上下文，同时区分可恢复与需人工介入的场景，避免误报。PowerShell 监控 Windows 服务报错，核心不是等错误发生后再“抓包”，而是主动识别异常状态、捕获启动/运行失败细节，并留下可追溯的操作痕迹。重点在于**提前定义什么是“报错”**——比如服务卡在 `Start Pending`、`Stop Pending`，或反复启停、启动后立即崩溃，又或者依赖项缺失导致无法启动。
明确哪些状态算“服务报错”
windows 服务的 status 属性不只有 running 和 stopped 两种。以下状态都属于需告警的异常：
- Start Pending：服务正在尝试启动，但超时未完成（常见于初始化慢、资源争抢）
- Stop Pending：服务正在关闭，但长时间未退出（可能卡死或有未释放句柄）
- Paused 或 Continue Pending：非预期暂停，尤其对设为自动启动的服务
- Stopped 且 StartMode 是 Automatic（自动）：说明本该自启却没起来
-
Get-Service 返回错误：如服务名不存在、无权限访问、WMI 响应超时（用
-ErrorAction SilentlyContinue捕获后判空）
用 Get-Service + 启动日志定位真实报错原因
单纯查 Status 只能看到“结果”，要看到“为什么报错”，得结合服务自身的启动日志和系统事件：
- 运行
Get-Service -Name YourSvc | Select-Object Name,Status,StartType,RequiredServices，确认它是否依赖其他已停止的服务 - 检查最近的系统事件：
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; ID=7000,7001,7022,7023,7031} -MaxEvents 20。这些 ID 对应服务启动失败、依赖失败、意外终止等关键错误 - 若服务有自己日志（如 .NET 服务写入 Application 日志），加查：
Get-WinEvent -LogName Application -ID 1000 -After (Get-Date).AddHours(-1)
脚本中加入启动失败的详细捕获逻辑
不要只写 Start-Service 就完事。失败时必须拿到具体错误信息，否则等于没监控：
- 用
try/catch包裹启动操作，$_.Exception.Message通常含 Win32 错误码（如 1053=服务未及时响应启动或控制请求） - 启动后立刻验证：
$svc = Get-Service YourSvc; if ($svc.Status -ne 'Running') { Write-Warning "启动完成但状态仍为 $($svc.Status)" } - 把完整上下文记入日志：时间、服务名、原始状态、启动命令、错误消息、依赖服务状态
避免误报：区分“可恢复”与“需人工介入”的报错
不是所有报错都适合自动重试。例如：
- SQL Server 停止 → 很可能是磁盘满、数据库损坏，自动重启会加重问题
- 某服务因注册表键丢失而无法启动 → 自动修复需额外脚本，不能只靠 Start-Service
- 服务被手动禁用（StartMode = Disabled）→ 此时 Status 是 Stopped，但不该触发告警或重启
建议在脚本开头加判断：if ((Get-Service YourSvc).StartMode -eq 'Disabled') { exit } ，并把这类情况单独归类记录。
