计划任务配好了却一次都没跑成功，或者跑了但什么也没做，状态栏里的「上次运行结果」显示0x1。这个码看着像任务计划程序报错，其实是被启动的那个程序自己返回的退出码，排查方向完全不同。先把返回码分清楚属于哪一层，再按「有没有被触发、启动了没有、跑完没有」三步往下查，十几分钟一般就能定位。
1、返回码分三类，看清是哪一层出的问题
状态栏那个十六进制值有三类来源。小数值0x1、0x2、0x3这类，是脚本或程序自己的退出码，跟任务计划程序没关系，去查脚本；0x41300到0x41306这一串是任务计划程序自身的状态码，表示的是任务处在生命周期的哪个阶段，并不算错误；0x8007xxxx这种长码才是Windows的错误码，指向任务配置本身。
0x0 正常结束 0x1 程序自己的退出码，最常见的那个 0x2 程序退出码，命令行场景多为路径问题 0x41300 等待下次触发 0x41301 正在运行 0x41302 已禁用 0x41303 从没运行过 0x41306 被用户终止或被执行时间限制终止 0x8004131F 已有实例在跑，规则是不启动新的 0x80070002 找不到文件，检查操作里的程序路径 0x8007010B 目录名无效，检查「起始位置」 0x80070005 拒绝访问，账户权限或运行级别 0x800704DD 账户未登录，任务需要交互式会话 0x8007052E 登录失败，多半是保存的密码过期了 0x80070569 账户没有「作为批处理作业登录」的权限
遇到过一个备份脚本一直显示0x1，查了半天权限，最后发现脚本里调robocopy，而robocopy的退出码0到7都表示成功，复制完文件返回1。判据写错了，任务其实跑得好好的。
2、先把历史记录打开，否则什么都看不到
任务计划程序的「历史记录」选项卡默认是关的，关着的时候状态栏只有结果码，没有任何过程信息。在任务计划程序库上点「启用所有任务历史记录」，或者直接从命令行导日志：
wevtutil qe Microsoft-Windows-TaskScheduler/Operational /rd:true /f:text /c:50 wevtutil epl Microsoft-Windows-TaskScheduler/Operational C:\temp\ts.evtx
事件查看器里的路径是「应用程序和服务日志 → Microsoft → Windows → TaskScheduler → Operational」。日志有大小上限，满了会覆盖旧记录，排查期间可以临时把上限调大一点。
3、看事件ID判断卡在哪一步
Operational日志里几个ID很有用：100表示任务已启动，102表示任务已完成，103表示操作启动失败并且会带上它尝试执行的那个完整路径，201表示操作完成并带上返回码，101是任务启动失败，332是因为没有用户登录而跳过。看到103直接读它给的路径，八成是路径写错了或者文件不存在；看到201就读返回码，再回到第1步判断是哪一层。
4、起始位置和相对路径
「起始位置（可选）」这一栏是0x8007010B的高发区。填了带引号的路径，比如"C:\scripts"，任务计划程序会把引号当成路径的一部分，直接报目录名无效。填不带引号的C:\scripts就行。
不填更麻烦：任务启动时的工作目录默认是C:\Windows\System32，脚本里任何相对路径都会以那里为基准解析。之前接手过一台机器，脚本在命令行里跑得好好的，做成任务就找不到配置文件，就是这个原因。要么在起始位置里写全，要么脚本内一律用绝对路径，涉及网络位置就用UNC，别用映射盘符——非交互式会话里盘符根本不存在。
5、PowerShell脚本的参数写法
操作里直接填脚本文件名不行，必须显式调用解释器，并带上几个参数：
powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File C:\scripts\rpt.ps1
-NoProfile避免加载会卡住的用户配置文件，-NonInteractive保证不弹任何提示框，-ExecutionPolicy Bypass绕开执行策略。脚本里依赖的模块要显式Import-Module，别指望自动加载。32位上下文里要调64位的解释器，路径是%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe。
本机装的PowerShell 5.1、7.4、7.5，三者共存时任务里写powershell.exe默认走5.1，要用7.x得写全路径pwsh.exe。
6、账户、密码与登录权限
选了「不管用户是否登录都要运行」之后，任务会用保存的凭据做一次非交互式登录。密码改过而任务里没更新，就报0x8007052E；账户没有被授予「作为批处理作业登录」（SeBatchLogonRight），就报0x80070569。域环境里可以考虑用gMSA，免掉密码过期这个坑。
验证办法是临时改成「只在用户登录时运行」跑一次。改完就正常，说明问题在非交互式会话或凭据上，跟脚本内容无关；改完还是失败，再去查脚本本身。
另外「使用最高权限运行」这个复选框对应的是令牌提升，不开的话即使账户是管理员组成员，任务拿到的也是标准令牌，写系统目录、改服务这类操作会被拒绝访问。
7、条件和设置里的默认值
条件选项卡默认勾着「只有在计算机使用交流电源时才启动此任务」。用笔记本做验证机的时候，就会出现插着电正常、拔了电不跑这种看着像玄学的问题。夜间跑批的机器还要考虑两件事：勾上「唤醒计算机运行此任务」，以及勾上「如果错过了计划启动时间，立即启动任务」，否则关机期间错过的那次会被直接跳过，要等下一个周期。
设置选项卡里还有两个容易忽略的：执行时间限制默认72小时，跑不完会被终止，返回0x41306；「如果此任务已经运行，以下规则适用」默认是「不启动新实例」，上一轮没结束的话这一轮会被静默丢弃，返回0x8004131F。跑批任务建议改成并行运行新实例，或者在脚本开头自己加锁。
8、命令行与图形界面两套查法
服务器上不想开图形界面，用schtasks足够：
schtasks /query /fo list /v | findstr /i "TaskName Last Result Status" schtasks /query /tn "\Backup\Nightly" /fo list /v schtasks /run /tn "\Backup\Nightly" schtasks /change /tn "\Backup\Nightly" /ru DOMAIN\svc-bak /rp *
手动触发一次是最快的验证手段：schtasks /run之后等几秒再看状态，比等下一个触发周期省事得多。任务定义本身是XML文件，放在C:\Windows\System32\Tasks目录下，子目录对应任务计划程序里的文件夹结构，可以直接读，也可以用Export-ScheduledTask导出一份完整的XML来看。
9、对照表似的排查顺序
实际排查时按这个顺序走比较省事：手动跑一次脚本（用runas切到任务的运行账户）确认脚本本身没问题；看状态栏返回码属于哪一类；打开历史记录找103和201两个事件；检查起始位置有没有多引号；确认账户密码和批处理登录权限；最后看电源条件和错过启动的策略。这几步走完还没线索，就把脚本的输出重定向到日志文件，看它到底停在哪一行。
Windows Server 2016、2019、2022到2025，任务计划程序的这套机制和返回码基本一致，build 10.0.14393、10.0.17763、10.0.20348与10.0.26100，上面这些命令和路径都能用。数据截至2026年10月。