计划任务不运行通常因服务未启动、权限不足或环境不匹配；需用PowerShell检查Schedule服务状态、手动触发任务并分析LastTaskResult代码、筛选事件日志ID 100/101/201，以及验证脚本执行环境。
计划任务配置看起来没问题，但到点就是不运行，这类问题通常不是“写错了”，而是环境、权限或服务层面的隐性阻断。powershell 是最直接的排查工具——它能绕过图形界面干扰，快速验证服务状态、日志线索和执行上下文。
确认 Task Scheduler 服务是否真正就绪
服务没启动或启动失败，任务根本不会被调度，且不报错、不提示，纯静默失效。
- 以管理员身份打开 PowerShell，运行：
Get-Service Schedule | Select-Object Name, Status, StartType - 若 Status 不是 Running，立即启动：
Start-Service Schedule -PassThru - 若启动失败（如报错 1053），说明依赖服务异常，再查：
Get-Service Schedule | ForEach-Object { $_.DependentServices } | Select-Object Name, Status
用 PowerShell 快速验证任务是否被触发
避免在 GUI 中反复右键“运行”，直接用命令触发并捕获结果，可绕过界面缓存延迟。
- 手动触发任务（替换 YourTaskName 为实际名称，路径需完整）：
Start-ScheduledTask -TaskName "YourTaskName" -TaskPath "\" - 检查触发后状态：
Get-ScheduledTask -TaskName "YourTaskName" | Select-Object State, LastRunTime, LastTaskResult - LastTaskResult 是关键：0 表示成功；267009 表示“用户未登录”；2147942667 表示“拒绝访问”；2147746138 表示“系统资源不足”——这些数字比 GUI 的“上次运行结果”更准确。
提取并筛选任务计划程序事件日志
GUI 的“历史记录”选项卡有时只显示摘要，而 PowerShell 可精准过滤出失败瞬间的上下文。
- 获取最近 1 小时内所有与该任务相关的错误事件：
Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" -After (Get-Date).AddHours(-1) | Where-Object { $_.Id -eq 100 | $_.Id -eq 101 | $_.Id -eq 200 | $_.Id -eq 201 } | Format-List TimeCreated, Id, Message - 重点关注 ID 201（任务启动失败）、ID 101（任务因条件不满足跳过）、ID 100（任务已启动）——它们会明确告诉你：是没触发？触发了但卡住？还是被条件拦住了？
- 若日志为空，说明任务甚至没进入调度队列，大概率是服务未运行或任务被禁用（Get-ScheduledTask | Where-Object State -eq "Disabled"）。
验证脚本在任务环境下能否真实执行
很多脚本在桌面双击能跑，放进计划任务就失败——根源在于工作目录、权限令牌、环境变量三者缺失。
- 新建一个极简测试任务，操作设为：
cmd.exe /c "whoami > C: ask-test.log & echo %cd% >> C: ask-test.log & set >> C: ask-test.log" - 运行后检查 C: ask-test.log：第一行是否为你设定的运行账户？第二行是否是任务中设置的“起始位置”？第三行是否包含你预期的环境变量（如 PATH 是否含 PowerShell 目录）？
- 若 whoami 显示 SYSTEM 但你期望的是当前用户，说明“安全选项”中未正确填写密码；若 %cd% 是 C:WindowsSystem32，则“起始位置”为空——相对路径引用必然失败。
