69

I have a scheduled task on a Windows 2008 R2 server. The task includes a Start In directory entry. The task runs, and the batch file it runs does what it is supposed to do. When I run the batch file from a command prompt, I see no errors. The problem is that the "Last run result" is 0x1 (incorrect function call).

I did get this at one time with an incorrect DOS statement IF EXISTS file.txt DO (Copy file.txt file1.txt) that was corrected by dropping the DO statement. The current batch file does not show me any errors or warnings.

Why am I getting a 0x1 result?

Batch file that is run:

PUSHD \\JUKEBOX4\Archives\CallRecording
REM only move csv and wma together.  wma should be created last.
IF NOT EXIST C:\CallRecording (MKDIR C:\CallRecording)
FOR /f %%f IN ('DIR /b *.wma') DO (
    IF EXIST %%~nf.csv (MOVE /Y %%~nf.* C:\CallRecording\)
)
POPD
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload"
CollybusUpload.exe
POPD

Info on scheduled task setup:

  • Program to run: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload\CallRecordingUploadFromH.cmd
  • Start in: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload
  • Run whether user is logged on or not, highest privileges.

History screen, task completed entry

"Task Scheduler successfully completed task "\Call recording upload to portal from NH" , instance "{1449ad42-2210-427a-bd69-2c15e35340e6}" , action "C:\Windows\SYSTEM32\cmd.exe" with return code 1."

First screen of Task Scheduler shows "Run Result" of "Success"

TylerH
  • 20,799
  • 66
  • 75
  • 101
user241099
  • 818
  • 2
  • 7
  • 7
  • did you resolve your problem? I set up to run a python 3 task in with everything you said but only when user is logged in. The task is successful and I see it execute. I just get a (0x1) error for some reason too. – user3553260 May 21 '19 at 22:23
  • Yes, I resolved it. The issue was the use of commands in the batch file. I had a final command of POPD that had no work to do as there was no preceding PUSHD. – user241099 Jul 04 '19 at 21:07
  • Does this answer your question? [Why does my Task Scheduler task fail with error 2147942667?](https://stackoverflow.com/questions/13618945/why-does-my-task-scheduler-task-fail-with-error-2147942667) – TylerH Jun 08 '22 at 13:37

16 Answers16

73

It seems many users are having issues with this. Here are some fixes:

  • Right click on your task > "Properties" > "Actions" > "Edit" | Put ONLY the file name under 'Program/Script', no quotes and ONLY the directory under 'Start in' as described, again no quotes.

  • Right click on your task > "Properties" > "General" | Test with any/all of the following:

    1. "Run with highest privileges" (test both options)
    2. "Run wheter user is logged on or not" (test both options)
    3. Check that "Configure for" is set to your machine's OS version
    4. Make sure the user account running the program has the right permissions
full_prog_full
  • 1,139
  • 10
  • 17
  • This answer definitely saved the day for me - for others, my instance of Windows 2008 server had both options for Windows 2008 and Windows 2008 R2. I think this makes a difference. – Darth Jon May 16 '16 at 17:01
  • 9
    Your first bullet point about "start in" parameter fixed this issue for me. Thanks a ton. – VHS Aug 27 '17 at 17:09
  • 1
    thanks, it works. btw: windows is totally sick platform, it's forcing the user to work against the built in tools (brows script to run and then manually remove quotes and split full path to filename and directory). – andrej Mar 23 '18 at 11:06
  • First bullet fixed it for me, after I added `.\ ` in front of the filename. – Jacktose Jul 06 '18 at 22:04
  • 1
    I think the executable goes in the program/script area. – user3553260 May 21 '19 at 22:21
  • Nice! for Windows 2016 the bullet is the key. Just the name with the extension in `Program/Script` and the location path in `Start in`. Zenkiú! – Chuck Aguilar Mar 06 '20 at 10:11
  • Using `Browse` button, it takes full path with the file name for `Program/script:` column, which may cause issue for many. Putting only file name there, and path in `Start in (optional)` works. Thanks for pointing it out. – viking Mar 19 '21 at 13:56
  • To whom it may concern: in my case, there was a typo in the ps1 file. `-` was encrypted when copying the script from another server. Check your script for errors as well. The Task scheduler will not point you there – Moslem Ben Dhaou Mar 02 '22 at 23:48
  • The script runs fine, just as the OP says, so why add work by trying these things? In my case I would not like to even try the first bullet point, as the fields are automatically filled by an R package. I tried the other options you listed and they did not work. – its.me.adam Feb 01 '23 at 19:37
  • The key solution for my case is the "OS configure for". It was a task exported from old server 2008 and setup on the Win server 2019. It was still pointing to old OS config. Changing that to current version eventually solved the problem. – Ak777 Aug 20 '23 at 19:20
10

I found that when I have ticked:

Run whether user is logged on or not

it returns a silent failure.

But, when I changed to:

Run only when user is logged on

it works for me.

J. Scott Elblein
  • 4,013
  • 15
  • 58
  • 94
lsheng
  • 3,539
  • 10
  • 33
  • 43
  • This proved of use as when set this way the pop up will show, I played a game of trying to hit print screen when the error was occuring before the screen disappeared again. I was able to see that my filepath was wrong. – user3520245 Jun 21 '19 at 06:35
7

I've had the same problem. It is just a batch-file, working when manually started, but not working as a scheduled task.

there were drive-letters in the batch-file like this:

put z:\folder\file.ext

seems like you should not use drive-letters, they are bound to the user, who created them - for me this little change made it work again:

put \\server\folder\file.ext
roeb
  • 467
  • 8
  • 19
  • This is not an issue if you are careful to run the batch file under a user that also has the same drive letters, but it is good practice regardless to use UNC shares instead of mapped drive letters. Just also make sure that the user you are running the process under has permissions to access UNC paths as well. – TylerH Jun 02 '22 at 20:35
5

For Powershell scripts

I have seen this problem multiple times while scheduling Powershell scripts with parameters on multiple Windows servers. The solution has always been to use the -File parameter:

  1. Under "Actions" --> "Program / Script" Type: "Powershell"
  2. Under "Add arguments", instead of just typeing "C:/script/test.ps1" use -File "C:/script/test.ps1"

Happy scheduling!

enter image description here

Andreas
  • 775
  • 2
  • 11
  • 20
3

Windows Task scheduler (Windows server 2008r2)

Same error for me (last run result: 0x1)

Tabs

  1. Action: remove quotes/double-quotes in

program/script

and

start in

even if there is spaces in the path name...

  1. General:

Run with highest privileges

and

configure for your OS...

Now it work!

last run result: The operation completed successfully

navya
  • 45
  • 5
2

Probably not the cause of the OP's problem; for me the problem was caused by the fact that my program called a SQL function, and the service account the windows task was set up with did not have the required SQL permissions. That also gives a 0x1

opperman.eric
  • 314
  • 1
  • 14
  • How can I set an SQL permission for a specific user in these case – Gabriel J May 09 '23 at 02:42
  • 1
    Access your SQL server with Management Studio. Right click on security and add new login. Use the domain name too, for the windows account running you scheduled task, like ```SomeDomain\SomeUser```. Before hitton OK to create the login, select "User Mapping" on the left and give this new login the required databases. – opperman.eric May 10 '23 at 03:15
1

This answer was originally edited into the question by the asker.


The problem was that the batch file WAS throwing a silent error. The final POPD was doing no work and was incorrectly called with no opening PUSHD.

Broken code:

CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD

Correct code:

PUSHD "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
HPierce
  • 7,249
  • 7
  • 33
  • 49
1

I was running a PowerShell script into the task scheduller but i forgot to enable the execution-policy to unrestricted, in an elevated PowerShell console:

Set-ExecutionPolicy Unrestricted

After that, the error disappeared (0x1).

Willi Mentzel
  • 27,862
  • 20
  • 113
  • 121
Jose Ortega
  • 1,002
  • 13
  • 23
1

In my case it was an encoding issue. We wanted to start en existing batch file, and it resulted in "return code 1", and the desired action wasn't performed. I've accidentally found that the batch file was shown in Notepad as one with UTF-8 encoding (actually without any reason, as we have no special characters in the text). I saved it as ANSI, and it solved the problem for us. Might be, that it was a kind of encoding corruption in the file that prohibited Task Scheduler and cmd.exe to open the file, although it was displayed correctly in Notepad.

pholpar
  • 1,725
  • 2
  • 14
  • 23
0

On our servers it was a problem with the system path. After upgrading PHP runtime (using installation directory whose name includes version number) and updating the path in system variable PATH we were getting status 0x1. System restart corrected the issue. Restarting Task Manager service might have done it, too.

Franc Drobnič
  • 985
  • 10
  • 14
0

Just had the same problem here. In my case, the bat files had space " " After getting rid of spaces from filename and change into underscore, bat file worked

sample before it wont start

"x:\Update & pull.bat"

after rename

"x:\Update_and_pull.bat"

tryingToLearn
  • 10,691
  • 12
  • 80
  • 114
Ardi
  • 65
  • 7
0

For me the problem was the PowerShell script being ran had #Requires -RunAsAdministrator at the top, meaning it needs to run in an elevated command prompt as an Admin, but the user the Scheduled Task was set to run as wasn't an admin on the local computer. So even though Run with highest privileges was checked in the scheduled task, I still had to make the user an Administrator on the computer. Once I did that, the script ran as expected.

deadlydog
  • 22,611
  • 14
  • 112
  • 118
0

Since there is always more than one reason this could happen I thought I'd share some troubleshooting tips that helped me diagnose my issue.

  1. Always adding a "start in" parameter first since thats an easy fix, even just adding the drive letter can help, e.g. C:\
  2. If you're running "whether user is logged on or not" and it is failing it might be an issue with your user and/or user environment.
    • Switch the task to run only when user is logged in temporarily for troubleshooting purposes.
    • Make sure you're actually logged in AS the user you're telling the task to run as. (PATH and other environment variables are different by user and if you see the task running on one user successfully that doesn't necessarily mean it will run successfully for another user even if they're in the same security group.)
    • Add pauses or some other type of debugging to your script to give you time to see any errors that may pop up.
    • Perform a manual run from the task scheduler window.
    • Fix any errors you see from your debugging statements. Rinse and repeat.
    • If it runs successfully switch back to run "whether user is logged on or not" and try another manual run. If it works now you're all set.
  3. If nothing has helped so far you might need to dig in deeper to your user and file privileges. My troubleshooting tips assume that you have been able to get a past task running using a specific user login already. They don't cover building a scheduled task from a fresh install necessarily. Luckily I haven't had to do that.
Rob Carpenter
  • 602
  • 7
  • 16
0

What solved it for me was that I was using a local administrator account instead of the domain account so I changed the "Run as" to the domain account.

Nick Green
  • 101
  • 1
  • 9
0

I had the same issue, tried all the answers listed here, and couldn't resolve it. Here's what finally did it.

My scheduled task was calling a PowerShell script and providing a parameter. The script was expecting a different parameter. Once I fixed the parameter names, the error magically went away.

In other words, in the Actions tab of the task, "Add arguments" had

"C:\Temp\myscript.ps1" -Parameter1 XYZ123

Where as the script itself was expecting

Param(
[Parameter][string]$Parameter2)

Once I fixed the script to match the task, the job ran perfectly.

James Brown
  • 327
  • 2
  • 11
  • 21
-1

It turns out that a FTP download call using winscp as last thing to do in the batch caused the problem. After inserting the echo command it works fine. Guess the problems source could be the winscp.exe which do not correctly report the end of the current task to the OS.

del "C:\_ftpcrawler\Account Export.csv" /S /Q

"C:\Program Files (x86)\WinSCP\WinSCP.exe" /console /script="C:\_isource\scripte\data.txt"

echo Download ausgeführt am %date%%time% >> C:\_isource\scripte\data.log
Willi Mentzel
  • 27,862
  • 20
  • 113
  • 121
SimonR
  • 1
  • 1
    If WinSCP reported error (non zero exit code), it did that for a reason. You are just hiding the problem away by adding a dummy command. – Martin Prikryl Sep 19 '17 at 06:59