这种情况确实挺让人挠头的——明明路径、权限、运行条件完全一致，就因为参数不同，一个能正常跑，一个却在无人登录时触发“文件找不到”的错误。结合你描述的现象，我整理了几个可以跟进排查的方向：

• 检查计划任务的「起始目录」配置
  很多人容易忽略计划任务的「起始于（Start in）」字段，即便你写了程序的绝对路径，有些命令行工具还是会依赖当前工作目录的环境变量。Task1能成功执行，可能是因为-removedefinitions参数不依赖当前目录，但-SignatureUpdate可能需要读取当前目录下的依赖文件或者调用相对路径的组件。无人登录时，SYSTEM账号的默认工作目录通常是%systemroot%\system32，这就会导致程序找不到需要的文件。建议把两个任务的「起始于」都明确设置为C:\Program Files\Windows Defender\，不要留空。

• 验证Windows Defender及依赖服务的启动状态
  虽然Task1能正常运行，但删除签名和更新签名依赖的服务可能有差异。比如：

  • 确认WinDefend服务的启动类型是「自动」，而不是「自动（延迟启动）」——延迟启动可能导致无人登录时服务还未完全就绪；
  • 更新签名依赖Windows Update服务，检查该服务是否设置为自动启动，同时确认有没有组策略限制了无人登录时的Windows Update活动。

• 修改任务执行命令，强制切换工作目录
  如果调整「起始目录」没用，可以尝试在任务的操作命令里先切换到目标目录再执行程序，比如把原来的命令改成：

  cmd /c "cd /d C:\Program Files\Windows Defender\ && MpCmdRun.exe -SignatureUpdate"
  

  这样能强制在Windows Defender的安装目录下执行命令，避免环境变量或工作目录的影响。

• 检查组策略中Windows Defender签名更新的相关设置
  打开组策略编辑器，定位到计算机配置→管理模板→Windows组件→Windows Defender防病毒→签名更新，确认「允许在无人参与的情况下进行签名更新」选项是启用状态。如果这个设置被禁用，会直接阻止无人登录时的签名更新操作。

• 查看更详细的日志信息
  除了计划任务的历史日志，还可以去事件查看器里找Windows Defender的专属日志：应用程序和服务日志→Microsoft→Windows→Windows Defender，这里面会记录签名更新的具体失败原因——比如是不是SYSTEM账号没有访问某个更新文件的权限，或者无人登录时网络连接受限（比如企业网络需要用户认证，SYSTEM账号无法通过）。

备注：内容来源于stack exchange，提问作者The ITea Guy