task scheduler returns (0x1) code when 'Run whehter user is logged on or not' options selected
Question
Monday, November 21, 2011 10:17 PM | 2 votes
I have setup a task using Task Scheduler that I would like to use to launch a batch file at a certain time each day. The batch file works correctly when launched manually and the task also works correctly when the option 'Run only when user is logged on'. However, as soon as I mark 'Run whether user is logged on or not' using the Administrator login, the task returns a Last Run Result of (0x1). This happens when trying to launch the file on demand or when it is scheduled at it's daily time to run.
From some research I have done, I don't believe I should see the actions of the batch file and the program that it launches when this option is marked, but I know it is not running correctly in the background due to the fact the log files are not generated from the task it is to complete. I have marked 'Run with highest privileges' and also entered information in the Start in field under Edit Action with no quotes. The history logs show that the task successfully finished, despite the lack of the Last Run Result code and no log files being generated. I have also verified the user being added to the Log on as a batch job option and that there are full permissions to the files (all on the local machine).
Does anyone have any insight to what I could be missing? If helpful, i could post the history logs as well.
Thanks!
All replies (80)
Monday, November 21, 2011 11:18 PM | 1 vote
Does the account you're running the task under have the "logon as batch" user right?[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
Tuesday, November 22, 2011 5:00 PM
Thanks for the reply - yes, we have set this user up with this user right, but unfortunately to no avail. I'm starting to think that it may be related to the program that is trying to launch and the process it is trying to run instead of the Task Scheduler after testing some more, so I'm planning to do some more research on that.
Thanks for your response however!
Friday, January 6, 2012 7:03 PM | 14 votes
I had a similar issue today when I enabled "Run whether user is logged in or not" on a task that runs overnight. The task was configured to run a batch file with a simple copy command in it. After I enabled "Run with highest privileges", the task ran successfully.
Also remember that the user account you are using for the task has the privileges necessary for the programs in the batch file to complete successfully; i.e. if a command to copy something to a server is ran with a user account that exists on the local machine, but not on the server you are copying to, the task will fail silently and may or may not report a result. The same will happen if the username on the local machine and the server is the same, but the password is not.
Wednesday, July 11, 2012 5:36 PM | 7 votes
Is Microsoft ever going to a) publish a fix for this; or b) give a comprehensive solution for it? They seem to ignore it. I have done everything in every forum thread I've found to fix this and nothing works. It's a simple batch job that works with my personal account but no other. It accesses local files and a WinSCP upload. The user is in local administrators. It has batch logon privileges.
I've tried running the WinSCP directly with the same results. 0x1.
Could MS at least explain what return code 1 is? Is that the really useful "unexpected error?" If it's a permissions issue, shouldn't it state that instead of claiming to have finished? Now I have to update this job every time I change my password and I have no idea what will happen if I should leave the firm.
This is very poor design and even worse documentation. Support by forum should be illegal.
G. Steele at Sedgwick
Wednesday, August 22, 2012 12:25 PM
Check your relative paths in the batchfile. If you are using drive letters that points to a network drive. (drive that the is assigned to the user when logged on) then you wont be able to run the task with "Run whether user is logged in or not".
To use "Run whether user is logged in or not" you need to use UNC paths or point to the physical disk (if local drive).
Depending on the program executed in the batch file, it is however not always possible to use UNC paths.
Agrree that MS has total F..... up the task scheduler. The log feature is just not usable with error codes like 0x1 or 0xFF. There are better 3. part alternatives....
Wednesday, September 12, 2012 11:29 PM | 48 votes
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find it doesn't work, so you see I didn't put them in. Check out the screenie ..
Monday, October 8, 2012 8:02 PM | 8 votes
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find it doesn't work, so you see I didn't put them in. Check out the screenie ..
Thanks worked for me!
Monday, October 22, 2012 3:38 PM
Thank you - this worked for me too! :D
Thursday, November 1, 2012 7:31 AM
But did not worked for me...
Алексей.
Friday, December 14, 2012 9:28 PM
thanks - adding the directories as shown, run with priv's, changed to only run when user is logged on all worked for me.
Wednesday, March 20, 2013 8:43 AM
That worked for me too
Thanks
Wednesday, March 20, 2013 10:25 AM
Another thing often forgotten, is to grant explicit directory rights for the execution account. Typically this becomes a problem, if the batch job needs to create a log file or in any other way modify contents of the target folder.
Tuesday, June 11, 2013 7:46 AM
Thank you!
Wednesday, July 31, 2013 9:03 PM
Thanks for tip, I got it to work finally!
My variation - just put the file name under 'Program/Script', no quotes and the directory under 'Start in' as described, again no quotes.
Wednesday, August 7, 2013 4:32 PM
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find it doesn't work, so you see I didn't put them in. Check out the screenie ..
Thanks worked for me!
This one also has worked for me. Putting the directory name (without quotes) in the 'Start in' fixed the error.
Sunday, August 18, 2013 8:53 AM
Thanks,
This solved my problem.
Problem.
OS: win 7 starter.
One Batch file with a copy command. This file didn’t work with scheduler but it works manually.
One Batch file with a ftp command. This file works fine with the scheduler and manually.
Solution.
In the scheduler of the copy bath file: filed in the directory in the start in field.
Thursday, September 19, 2013 5:39 PM
I had this same exact issue.
I later found out that the script I was using to create the scheduled task didn't copy the file that the scheduled task referenced. I felt rather silly.
Wednesday, October 30, 2013 2:46 AM | 1 vote
I had this issue too but the above techniques didn't work for me. I then worked out that the file name of the script was too long, so once I shortened it - it worked :)
Hope this helps!
Cheers
Steve
Monday, December 9, 2013 7:32 AM
Thank you, Worked like a bomb!
Friday, January 10, 2014 11:30 AM
Life saver! Add the directory in "Start in (optional)" fixed my problem!
Saturday, January 18, 2014 8:54 AM
In my case, I configured a web server to email me an alert via Task Scheduler when a tester attempted to log in. I was seeing (0x1) appear in the Task Scheduler results pane.
On investigation, Exchange 2010 was treating email from this server as spam.
In the Exchange 2010 Management Console -> Organisation Configuration -> Hub Transport -> Anti-spam -> Content Filtering -> Custom Words -> Allow messages containing these words or phrases:
...I added the title of the email being blocked as a phrase.
Click "OK"
Retest from source server. ...all then worked for me.
Thursday, March 6, 2014 9:02 PM
GMSteel... Did you ever get a resolution to this? I have tried (I think) every supposed answer/solution in this forum and still my task fails with the same (0x1) result.
Bradford W Brown
Sunday, March 9, 2014 8:30 PM
I have the same issue where I have a Task which runs the Powershell script to Compress a whole bunch of bak & trn files from a local drive to create a RAR file using the locally installed WinRAR application. This process with RAR commandline also ensures deletion of all the files added to the archive.
Another task scheduled at a later stage picks the created .RAR file and transfers(MOVE - CUT PASTE) across to another server with UNC path reference.
When I run the script manually as Admin with Powershell, it works fine in both cases, but when attached to the Task Scheduler task, it comes up with the 0x1 error.
All these options:
- Run whether user is logged on or not
- Run with highest privileges
- Actions -> Edit -> Program/Script : I invoke Powershell and pass the ps1 file as the argument
- Start in : C:\Windows\System32\WindowsPowerShell\v1.0\
- task which is for the copying of the file on to the remote folder is run as this user which has Local Admin rights on both the machine it is running on and the remote server as well.
Any help would be deeply appreciated.
Kind Regards, Anils
Sunday, March 9, 2014 9:41 PM
...even added .\scriptfilename>.ps1 in the additional arguments, and tried to run and the result is still the same 0x1 error!
Kind Regards, Anils
Wednesday, April 9, 2014 10:27 AM
Very useful thread, solved my issues, thanks all.
Tuesday, April 22, 2014 5:38 PM
Verify that you are allowed to run PowerShell scripts - Get-ExecutionPolicy, default is Restricted which doesn't allow custom scripts to run
Monday, May 26, 2014 4:18 PM
of all things - When I went back and put a few REM statements in the .bat script for documentation, now the task reports "completed successfully" instead of (0x1) - guess this is just Microsofts hint to document well - go figure -
Wednesday, May 28, 2014 4:06 PM
It worked for me, Gracias!
Wednesday, May 28, 2014 4:57 PM
Just FYI, cant explain it. Don't know why, but I re-wrote my scripts that were failing, from scratch... The problem went away.
Initially the batch files would run manually no problem but would consistently fail through the task scheduler. Out of frustration, I deleted them and re-wrote... suddenly no problem! Go Figure...
I deleted the old ones so I can not go back and compare. Obviously something was wrong but I could never find it.
Bradford W Brown
Monday, June 30, 2014 10:16 AM
Hii,
Thanks it's work for me
Tuesday, July 8, 2014 1:23 PM
Hi,
I m facing the same problem in Windows 8.1 task schedular i have tried all the proposed solution mention above but nothing is working for my case.
In my case i m invoking the task from System account where the folder where the batch script resides has full control of System account.
The same scenarion i have checked in Windows 7 but it was working fine in that.
Please advice how to proceed for Windows 8.1.
-Lisham
Friday, August 29, 2014 5:28 AM
In the task scheduler, edit the properties of the action and check you have the correct "start in" folder as that is likely to be an issue, even if the folder is specified in the Program/script field
Friday, December 5, 2014 8:59 PM | 1 vote
I used the UNC path in my script to where I was moving the file, and everything is now fixed. I had mapped the path to my Y: drive but that was not working. When I did \machinename\sharepath\ in my script to move the file, it now moves it correctly.
Thursday, December 11, 2014 6:43 PM | 2 votes
On the General tab, Check the last drop down and make sure it is pointing to correct OS. In my case , it was default set to Windows Vista ,Windows 2008 and my server was windows 2008R2. Once i changed it to Windows 2008R2 , it just worked fine with whether or not user logged in option. Hope that helps!
Monday, January 12, 2015 3:56 PM
There are three important options to make sure your task will run: 1 - Create your task using the "Create Task" option instead of the "Create Basic Task" (this gives you more options for the server type, usually the default server will work - Windows Server 2003, Windows XP, or Windows 2000). 2 - Use only UNC paths in your batch files and in the "Actions" Tab. You can map drives on your computer, but you must use the UNC paths throughout your task. 3 - On the "General" Tab, select the "Change User or Group" and add the correct credentials even if you are already signed into the account with the correct credentials. These options should work if you select to run the task when the user is logged on or not. Place a pause at the end of your batch file so you can see any errors and test run the job.
NOTE: if you are trying to connect to an AS400 network folder, open an AS400 session. You do not have to sign in, just start the session.
Thursday, February 19, 2015 3:38 PM | 1 vote
I tried everything that everyone suggested, but the only thing that I got to work was to put a command in the batch file to output a directory listing.
DIR C:\ > DIRECT.TXT
This makes absolutely no sense at all; however, it was the only way that I could get the batch file to run without any problems.
BTW, my batch file was running an FTP script to download files from IBM AS/400.
Tuesday, March 10, 2015 9:46 AM
This was the one that worked for me (thanks You Rocke!)
My bat file would run fine when executed manually, just the task wouldn't run it!
Creating a 'New Task' rather than a 'Basic Task' gives you a Windows 7 option in the server type (which is what I needed in my case)
I also put the path (without quotes) into the 'Start In' box and ticked the 'Run with Highest Privileges' box.
Thanks all
Mark...
Wednesday, March 11, 2015 1:17 PM
Glad I could help out, Mark.
Tuesday, May 12, 2015 3:55 PM
This was the fix for me: Add start in directory and put only the batch file name. Thanks!
Tuesday, May 26, 2015 3:32 PM
I must say it was rather nice to figure out that (0x1) could mean that the batch file couldn't be found. The batch file I was trying to run had an amperstand (&) in the file name which evidently caused Task Scheduler problems when trying to run it. Meanwhile, I was able to run the batch file outside of TS without any problems.
Tip: If TS isn't running the batch file as schedule, try running it via the 'Run' command within TS, either via the right click menu or the option on the right hand side panel.
David H
Wednesday, May 27, 2015 1:18 PM | 1 vote
Running WinSCP exe file script and keep getting 0X1 return code. Finally SHORTENED the name of the exe file and it worked without the return code. (Upload_HR_File_To_Offsite.exe -> HR_To_Offsite.exe) Worked.
Wednesday, June 10, 2015 3:50 PM
Thanks, this did worked for me...
Wednesday, July 1, 2015 7:03 PM
Hi,
Try Changing Server in Configure Box on General Tab of Task. I changed it from Windows vista to windows xp which worked for me :)
Wednesday, July 29, 2015 10:09 AM
I had this issue. How I resolved it was to explicitly state all paths used in the .bat file.
e.g. the code in runTest.bat
call test.bat > test.log
became
call "C:\test.bat" > "C:\test.log"
This worked like a charm.
Friday, September 4, 2015 11:48 PM
Thank you man! you saved my life
Monday, September 28, 2015 2:47 PM
Thanks, this solution worked perfectly for me
Tuesday, September 29, 2015 3:28 PM
I know this issue could be very old but I have had this problem for years using WinSCP and everything I tried I still got the error until I realized just now that this was because there was an error in the script file that is used to run WinSCP. so the task was not being shut down properly so windows would not consider it a success.
At the end of the script I had the following:
Disconnect
Close
The correct syntax should be
Close
exit
See and example of the script below.
Sunday, November 1, 2015 12:19 PM
Most of the 0x1 error cases that I found are from the path errors. So always use a full path in your .bat file
(ex. cscript "test.vbs" to cscript "c:\test\test.vbs")
One more important note is you'll need to add your path of the .bat file in "Start in (optional):" - if you don't, it won't just run when you logged off. See this tutorial video:
https://www.youtube.com/watch?v=VrysmzdF4Vc
Thursday, November 5, 2015 8:31 PM
Thank you sir, this worked for me too!
Wednesday, December 2, 2015 1:00 AM | 2 votes
I've had the 0x1 error appearing when attempting to run a PowerShell script via Task Scheduler.
Originally, I had set-up the actions via this link:
I noticed another PowerShell script which another Admin had set-up successfully. Once I set mine up the same way, it worked:
Action: Start a Program
Program/Script: PowerShell.exe
Argument: -File "<<local path to PowerShell script including script name>>"
Start In: <<blank>>
Friday, December 18, 2015 6:42 PM
My issue was resolved when also using UNC paths in the batch file.
Wednesday, February 3, 2016 11:54 PM
For me it was a bad character from copy/paste. The path originally came from another machine running a similar scheduled task. Kept getting 0x1 on the new machine.
I pasted the problematic task string into powershell, and there was a funky extended ascii/utf character in there instead of a an actual space. So I just re-typed the space character in the dialog box and it worked fine. So if all else fails, re-type the path/start directories in your "Edit Action" dialog box because they may "look" ok to you but are actually bad chars.
Thursday, April 21, 2016 8:44 AM
Try running the script manually - I've just had the same problem and it ended up being due to a missing } that I overlooked after editing the script for added functionality
It was only when I ran the script manually in a powershell session that the error was revealed
Or log the script activity to a log file
-=A=-
Friday, June 24, 2016 2:35 AM | 2 votes
Action: Start a Program
Program/Script: PowerShell.exe
Argument: -File "<<local path to PowerShell script including script name>>"
Start In: <<blank>>
this worked for me. thank you so much.
Friday, July 22, 2016 10:23 PM
I have a problem that has not been reported by anyone so far.
I have setup task scheduler jobs on a server where my login belong to administrators group on the server. All the jobs created run .bat scripts. These jobs are setup to run every minute. the .bat scripts run fine when I double click them.
I get 0x1 error when I set it up to run under my login but runs fine when I set it up to run under Administrators group, as long as only I am logged in or no one from Administrators group are logged in. The Administrators group includes many other users. The trouble starts if anyone from Administrators group logs in because all task scheduler jobs starts running under their logins and fail because of the privileges.
I have tested every possible solution suggested above and nothing has worked. Would appreciate if any one knows a solution to this.
Tuesday, October 18, 2016 3:33 PM
This seems to have worked for me. The message did not refresh in the Task Scheduler even after I changed the settings and reran the job manually a few times.
It looks like the Last Run Result field was cached in some strange way.
Thursday, November 17, 2016 11:11 AM
When executing a Powershell script through Task Manager (or running a task with sqlps which is essentially the same thing), I've discovered that in order to prevent the task from ending with 0x1 return code, once needs to add -querytimeout 0 to the task action arguments.
It has to do with Task Scheduler and tasks that are taking a longer time to execute (for example a minute or more).
Monday, November 28, 2016 5:57 PM
THANK YOU SIR! I know this is old, but you are my new hero.
Tuesday, December 27, 2016 8:17 AM
Excellent, perfect solution !
Souvik Banerjee. MSBI Lead, Zensar Technologies
Thursday, December 29, 2016 6:48 PM
Thanks!! That worked for us.
Wednesday, January 11, 2017 12:09 AM
Thank you so much. This was my answer.
Wednesday, February 1, 2017 2:37 PM
This fixed my issue. I was on a server migrated from Server 2003 to Server 2008 and all the scheduled tasks were defaulted to use the Windows Server 2003, Windows XP, or Windows 2000 configuration. Switching it to the Windows Vista or Windows Server 2008 configuration fixed the issue for me.
Wednesday, May 24, 2017 8:20 PM
We are both trying to do the same thing with WinSCP. The problem that I found was that the Administrator accounts, both Domain and Local, are not allowed to be the "Run As" account in Scheduled Tasks anymore. Need to create a Service Account, give the account "Log on as batch job" and "Log on as a service" in Local Security Policy>Local Policies>User Rights Assignment, create a service that runs as the user to create a local profile in \Users\ServiceAcctName profile folder. You have to run/Start the service once for the local profile to be created. It seems that CMD.exe requires \appdata folder for the user that the batch file is running as.
Also, set the Scheduled Task to "Run with highest privileges". General tab of the task properties.
For the Action properties of the Task, put the full path to the batch file in Program/script: box including the batch file name. In the "Start in (optional):" box, make sure the local path (or full UNC path if not local) for the folder containing your batch file is entered there. It's not optional! NO QUOTATION MARKS! If your path has spaces in folder names, you will have to change the folder names or move the batch file because the "Start in (optional):" box can NOT have quotations. If your batch file has spaces in the name of it, then the "Program/script:" box will have to have the whole path surrounded by quotes.
Also, make sure that the path to the batch file has Security Rights setup for the Service account that you create. Then consider the action of your task... if it is moving a file, then does it have rights to do that at the source location and at the destination location?
Monday, August 14, 2017 5:01 AM
Below are the steps to be taken to solve it:
1. Change the Security Policy to Run whether user is logged on or not, it would be even better if the user account is changed to SYSTEM.
2. Check whether Run with highest privileges is checked or not.
3. In the Action section of the task, specify the script folder in Start in (optional) parameter.
4. Check the execution policy, it should be Unrestricted.
Friday, August 18, 2017 7:56 AM
Thanks this worked for me.
Friday, September 8, 2017 3:09 PM
I found that if I am trying to call a batch file whose name includes any non-alphanumeric characters, e.g. my_batchfile.cmd, I got the 0x1 error. Simply renaming it to mybatchfile.cmd resolved the issue. Crazy, huh?
Wednesday, November 15, 2017 3:47 PM
I think I tried them all:
- checked "run with highest privileges"
- used only letters in the CMD name (the job simply calls a CMD file)
- filled the "Start in" optional field
- added -querytimeout 0 to the task action arguments.
- used full paths in the CMD file's lines
The job runs fine but I get 0x1 instead of 0x0.
Friday, January 26, 2018 1:32 AM
my task match all criteria but i still face same issue
Task Scheduler successfully completed task "\VolSpace DSI" , instance "{1a574aed-7fe7-4fd8-8d5d-926151dfa59a}" , action "C:\Windows\SYSTEM32\cmd.exe" with return code 1.
The only different i notice, if using domain account, it is working but return code 1 for SYSTEM account.
Please advise.
Tuesday, January 30, 2018 3:20 PM
Great, this worked OK!
Tuesday, February 13, 2018 1:20 AM
First I verified the permissions to execute script from powershell, using the command:
Get-ExecutionPolicy
Then, I used the following command on the path that hosted the script:
unrestricted set-executionpolicy
I managed to correct the error by changing it to a shorter name:
Remove_Profiles_Seralcli _ & _ Tiemvent.bat -> Remove_Profiles.bat
The latter also worked to execute tasks with type * .bat or * .cmd scripts
Wednesday, February 28, 2018 5:09 PM
Fixed my issue :)
Friday, March 2, 2018 10:00 PM
This worked for me!
Friday, April 6, 2018 10:03 PM
I had a PowerShell script setup to update godaddy dns when my ip changed on a windows 10 machine. Worked fine, then I decided it would be better to run that on the mailserver itself since it was always going to be on, and was the machine that really needed dns to be correct. I exported the two tasks, and imported them into the mailserver. I edited the task to update paths and got "incorrect function" error or 0x1 depending on its mood apparently.
I tried creating the task from scratch, same error. Specifically used PowerShell to avoid any batch file issues, and running the script from PowerShell worked as expected. Tried changing user, logged in or not, and finally gave up and went back to Windows 10.
Took another look at it today and tried all the stuff here, the fix was to remove the Start-in entry and prepend it to the Add Arguments field. That fixed it. Apparently Windows 10 doesn't mind if you use the Start-in box, Windows Server 2012 does care. To me it makes more sense to actually support the option "Start-in" if you are going to show it. Why can't they keep things consistent across operating systems? I would think it would be easier for all involved, or am I missing something?
Thanks for the fix.
Tuesday, June 12, 2018 6:23 PM
Thanks - this fixed my issue with my .BAT not running!
Friday, July 20, 2018 7:05 AM
It is now July 2018, and we have windows 10. This same optional (?!?!?!?!?) "Start in" option is still somehow obligatory. The error codes are still of the cryptic form 0x1 and we still have to rely on answers given 6 whole years ago, for a different and older version of the operating system. This post fixed my issue, but I couldn't agree more that this is very poor design and even worse documentation as GMSteele stated 6 years ago. Thank you all !
Friday, September 7, 2018 8:29 AM
It worked for me! Thank you very much ^^
Monday, March 11, 2019 2:01 PM
I've been using Task Schedular on one of the servers for running scripts for many years and have never filled in the Start In field- the tasks were working fine. Today I've added one more task which differs from others by 1) task name 2) the script name (the script itself is exactly the same as many others - it just has other wording in the smtp Subject and smtp Body section.
The result: OK when run manually and "..completed - 0x1" when run by the Task Schedular.
After typing the directory name in the Start in field all works perfect. If it's not a bug what is it???
Regards,
Michael
Friday, March 22, 2019 7:56 PM
In my case the problem was related to the fact that the batch program that I called in my script was printing output information about the processing it was doing. Originally, I did not specify anything in the action arguments and I was getting the 0x1 exit code. Once I added a redirection to a log file in the action arguments, e.g. > C:\myLogs\log.txt the task exits with code 0x0.
Monday, April 8, 2019 3:13 PM
After searching for a long time, that was the only option that worked for me. Thanks.
Monday, February 3, 2020 6:58 AM
don't forget the backslash at the end