如何解决 Windows 计划任务未运行的问题?

发布于 2024-07-19 05:03:38 字数 469 浏览 6 评论 0原文

在部署 .net 应用程序的过程中,我在服务器上设置了大约 20 个计划任务,所有这些任务基本上都执行相同的操作:调用一个小型 .net 控制台应用程序,该应用程序从 SQL 数据库中提取数据并将其发布到网络服务。 每个任务都会调用应用程序的一个单独副本,每个副本在其配置文件中都有不同的查找 ID 值。

除两项任务外,所有这些任务每晚都可靠运行。 其中两个任务似乎偶尔会停止运行,目前其原因仍是个谜。 当它们停止运行时,计划任务界面会正确显示其上次运行日期,该日期比在计划时间继续运行的其他任务晚一天或更长时间。 停止运行的任务不会再次自行运行,尽管被指示按计划每晚运行。 事件日志或计划任务界面本身中没有记录任何错误。 这对我们来说是最奇怪的部分:如果我手动启动计划任务,它会正常运行,它会调用 .net 控制台应用程序,并且一切都会顺利完成。 然后它继续在预定的时间正常运行,一次持续数天或数周,但最终似乎出乎意料地失败了。 看来这两项任务总是在同一个晚上开始失败。

In the process of deploying our .net app, I've got about 20 scheduled tasks set up on a server, all of which basically do the same thing: invoke a small .net console app that pulls data from a SQL db and posts it to a web service. Each task invokes a separate copy of the app, each copy having a different lookup ID value in its config file.

All but two of these tasks run reliably every night. Two of the tasks seem to sporadically stop running from time to time, and it's currently a mystery as to why. When they stop running, the scheduled task interface correctly shows their last run date, which is a day or more behind the other tasks, which have continued to run at the scheduled time. The tasks which stopped running do not run again on their own, despite being indicated as scheduled to run every night. There are no errors recorded in the event log or in the scheduled task interface itself. And here's the strangest part to us: If I manually kick off the scheduled task, it runs fine, it invokes the .net console app and everything finishes without anomaly. And then it continues to run fine at its scheduled time, for days or weeks at a time, only to eventually fail, seemingly out of the blue. It appears both tasks always start to fail on the same night.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(10

此刻的回忆 2024-07-26 05:03:38

有一个“最后结果”列应该为您提供与任务本身运行相关的代码(它不会有任何类型的异常数据)。 0 表示任务已完成且没有错误。 您可以查找其他内容并了解任务无法启动的原因。 如果任务似乎仍然没有运行,但您仍然看到“最后结果”为 0,则意味着您的代码中存在某些问题,但它正在正常退出。

There's a "Last Result" column that should give you a code related to the task itself running (it's not going to have any kind of exception data). 0 means the task completed without errors. Anything else you can look up and see why the task won't start. If the task still seems to not be running, but you still see a 0 for the Last Result, that means there's something broken in your code, but it's exiting gracefully.

送君千里 2024-07-26 05:03:38

您是否设置了“开始于”属性?

如果这些 .NET 控制台应用程序需要 app.config 或位于其路径中的某些文件,则必须将“Start in”属性设置为“c:\your\app\path\”,否则它们将像在系统目录中一样启动,并且他们找不到所需的文件!

Did you set "Start in" property?

If these .NET console apps need app.config or some files located into their path, you have to set "Start in" property to "c:\your\app\path\, otherwise they start as if they are in the system directory, and they cannot find files they need!

梦忆晨望 2024-07-26 05:03:38

任务调度程序假定在 64 位系统上应用程序是 64 位的。
如果是 32 位,请从 32 位命令行启动它,即如果您想运行 c:\program files (x86)\Myprogram\Program.exe,请告诉taskscheduler 启动:

  • %systemroot%\Syswow64\cmd.exe / C "c:\program files (x86)\Myprogram\Program.exe"

这会强制它从 32 位命令提示符启动,因此使用 32 位模拟。

Taskscheduler assumes on 64 bits systems that the applicaiton is 64 bit.
If it is 32 bit launch it from the 32 bit command line, i.e. if you want to run c:\program files (x86)\Myprogram\Program.exe, tell taskscheduler to launch:

  • %systemroot%\Syswow64\cmd.exe /C "c:\program files (x86)\Myprogram\Program.exe"

This forces it to launch from the 32 bit command-prompt and hence with 32 bit emulation.

独留℉清风醉 2024-07-26 05:03:38

我发现这个超级有用的链接https://windowsreport .com/windows-scheduled-tasks-not-running/ 用于许多用例的彻底调试步骤。

在我的例子中,配置运行计划程序的用户帐户被锁定,停止了计划任务的执行,没有任何日志或报告问题。

输入图片此处描述

I found this super helpful link :https://windowsreport.com/windows-scheduled-tasks-not-running/ for thorough debugging steps for many use cases.

In my case user account with which scheduler was configured to run was locked that stopped execution of scheduled tasks without any logs or reporting problem.

enter image description here

笛声青案梦长安 2024-07-26 05:03:38

当将计划任务与无密码的 Windows 用户帐户关联时,会出现计划任务不运行的原因之一:默认情况下,使用空白密码会阻止计划任务运行。 如果您想从没有密码的帐户运行计划任务,您必须禁用系统变量:

  • 转至:开始 > 管理工具> 本地安全策略> 安全设置> 地方政策> 安全选项
  • 选择:“帐户:限制本地帐户仅使用空白密码进行控制台登录”
  • 禁用此变量

免责声明:不建议使用没有密码的帐户。

One reason for Scheduled Tasks not running occurs when associating them with a password-less Windows user account: by default Scheduled Tasks are prevented from running with a blank password. If you want to run a Scheduled Task from an account with no password you have to disable a system variable:

  • Go to: Start > Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options
  • Select: "Accounts: Limit local account use of blank passwords to console logon only"
  • Disable this variable

Disclaimer: It´s not recommended to have accounts with no password.

人生百味 2024-07-26 05:03:38

下面这个问题的答案也可能与阅读这个问题的人高度相关(但是,注意,它只描述了计划任务的一个可能的具体问题,我相信这些问题都不是重复的另一个):

为什么我的计划任务正确更新其“上次运行时间”,并给出“上次运行结果”为“(0x0) ',但仍然没有实际工作?

对另一个问题的回答摘要是 Windows 2012 计划任务看不到正确的环境变量,包括任务设置为运行的帐户的 PATH 。

就更一般的计划任务故障排除(如本问题中所述)而言,您可以测试此特定问题(例如,按照该答案中的建议,在任务中运行 SET > test.txt) ,一旦您看到它发生,如果它影响到您,您就可以解决它。

The answer to the below SO question may also be highly relevant to people reading this question (but, NB, it describes only one possible specific problem with Scheduled Tasks and I believe neither of these questions is a duplicate of the other):

Why is my Scheduled Task updating its 'Last Run Time' correctly, and giving a 'Last Run Result' of '(0x0)', but still not actually working?

The summary of the answer given to that other question is that Windows 2012 Scheduled Tasks do not see the correct environment variables, including PATH, for the account which the task is set to run as.

In terms of more general Scheduled Task troubleshooting (as asked about in this question), you can test for this particular issue (e.g. running SET > test.txt in the task, as suggested in that answer), and once you can see it happening, you can work around it if it is affecting you.

离旧人 2024-07-26 05:03:38

就我而言,即使它说上次运行成功(0),计划的任务也不会运行。 事实证明,运行作业的 Windows 用户帐户已被锁定。 我只是意识到这一点,因为我尝试编辑现有的计划任务,将用户帐户设置为相同的帐户,然后单击“确定”,它给了我一个关于帐户被锁定的错误。

In my case, the scheduled task wouldn't run even though it said last run was successful (0). It turned out to be that the windows user account that was running the jobs had become locked out. I only realized this because I tried editing the existing scheduled task, set the user account to the same one, then hit OK and it gave me an error about the account being locked out.

不可一世的女人 2024-07-26 05:03:38

也许他们挂着,但仍在奔跑?

您可以单击附加菜单并选择菜单项来查看日志,然后记事本将从任务计划器中打开日志文件

Maybe they hung and were still running?

You can click on the extras-menu and choose the menu entry to view the log, then notepad will open a log file from the task planner

_失温 2024-07-26 05:03:38

当我尝试对行为不当的计划任务进行故障排除时,我发现此页面很有帮助:
http://support.microsoft.com/kb/308558

选择“查看”->“详细信息”以显示附加信息,例如上次运行时间和状态,此页面为我提供了状态/错误代码的含义:
http://msdn.microsoft。 com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

I found this page helpful when I was trying to trouble-shoot a misbehaving Scheduled Task:

http://support.microsoft.com/kb/308558

Select View->Details to show the additional information, like Last Run Time, and Status, and this page gave me the meaning of the status/error code:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx

冷弦 2024-07-26 05:03:38

我于 2023 年 2 月 23 日发现了类似的问题,但我的日志显示它始于 2023 年 1 月中旬。

我的任务已经运行了好几个月,没有出现任何问题。 我开始看到同样的错误:系统找不到指定的文件。 经过一整天的测试和搜索,我发现 2023 年 1 月 10 日的 Windows 更新改变了处理空白的方式。 以前只需要一组报价。 命令行帮助说明:

C:\> schtasks /创建/?

==> 文件路径中的空格可以通过使用两组引号来使用,一组是
设置为 CMD.EXE,设置为 SchTasks.exe。 CMD 的外部引号
需要用双引号; 内引号可以是单引号或
转义双引号:

SCHTASKS /Create

/tr "'c:\program files\internet explorer\iexplorer.exe' \"c:\log data\today.xml\""

I discovered a similar issue February 23 2023 but my logs reveal it started mid January 2023.

My tasks had been working for many months without issue. The I began seeing the same error: The system cannot find the file specified. After all day testing and searching I found that a Windows update on Jan 10 2023 changed the way white space is handled. Formerly only needed one set of quotes. The command line help explains:

C:\> schtasks /create /?

==> Spaces in file paths can be used by using two sets of quotes, one
set for CMD.EXE and one for SchTasks.exe. The outer quotes for CMD
need to be double quotes; the inner quotes can be single quotes or
escaped double quotes:

SCHTASKS /Create

/tr "'c:\program files\internet explorer\iexplorer.exe' \"c:\log data\today.xml\""

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文