Task scheduler- task completed "successfully" with exit code 0x8007001

0

I am running a daily task on Windows 10 Pro which is supposed to

  • wake the computer from hibernation
  • start cmd.exe, run a command script to copy a file to a network drive, create a log file
  • shutdown the computer

When starting the task manually from within the task scheduler, everything is executed as intended.

When leaving the computer in hibernation mode, the task scheduler wakes the computer at the specified time, but apparently the command file (.cmd) ist not executed at all. No log file ist created, no file is copied, and the computer is not shut down. The task is marked as "successfully completed with the return code 2147942401" which is hex 0x80070001. This error code seems to indicate an "illegal function", but I have no clue what that might be, especially since the task runs fine when started manually, as said.

Here's an overview of the task settings (translated from German, but it should be clear):

  • General: execute regardless of user login; don't store password; highest privileges; configured for Windows 10

  • Actions: start program cmd.exe; arguments: /c "path-to-cmd-script\script.cmd >> logfile.txt"; start in: empty

  • Conditions: reactivate computer

  • Settings: allow execution if needed; if execution fails restart every 10 minutes; end task if execution longer than 3 days; force ending of active task if not stopped on request; don't start new instance

I have another task doing a backup with exactly the same setting which is running fine (wakes up, runs a script, then shuts down computer).

Any hint highly appreciated, questions welcome.

windows-10
scheduled-tasks
asked on Super User Jan 28, 2017 by Steinspecht

2 Answers

1

Actually, no. However, I have used the simplest task scheduler settings and now it works.

General:

  • use only when user is logged in
  • use highest privileges
  • configure for Windows 10

Action:

Program/script: C:\Windows\System32\cmd.exe
Arguments: /c <your batch file with parameters>

Conditions:

  • re-activate computer

Settings:

  • allow execution if needed
  • execute as soon as possible if start was missed
  • if task fails, restart every 5 minutes
  • terminate task if execution exceeds 3 days
  • force termination if not stopped on request
  • stop current instance if task already running

Now it's running every day at the specified time for months.

answered on Super User Oct 17, 2017 by Steinspecht • edited Oct 17, 2017 by Kamil Maciorowski
0

For me, the task would sometimes work and sometimes wouldn't. According to the Scheduled Task History, when failing, it would appear as if it's been running for about 40 seconds, doing nothing, and completing action "C:\windows\SYSTEM32\cmd.exe" with return code 2147942401.

  • In this case, there was no point messing with the Group Policy settings because sometimes it would work, but not everytime (see https://stackoverflow.com/questions/48343993/batch-file-from-scheduled-task-returns-code-2147942401/).

  • Simplifying, recreating, reconfiguring my task did not fix the problem.

  • I did also consider butchering my batch file and getting rid of the standard output redirection, thus abandonning the logging capability (and becoming blind). Or simply running an actual .exe process, instead of using a batch file at all. This could have been a solution.

  • I also considered replacing the "on startup" scheduled task by a service, which would have been a fairly expensive experiment for such a trivial problem.

Ultimately, I considered adding a delay on the scheduled task and looked for configuring my task like a delayed service—services can either be "Automatic" or "Automatic (Delayed Start)". For "At startup" scheduled tasks, it's the trigger that have individual properties of its own, including the capability to add a delay:

Image depicting solution for delaying an on-startup scheduled task

I believe my scheduled task was sometimes being started a few milliseconds too early and some OS service or functionality was not yet available or allowed. Simply adding a small delay on the trigger fixed the problem.

answered on Super User Dec 16, 2020 by numdig • edited Dec 16, 2020 by numdig

User contributions licensed under CC BY-SA 3.0