Try to use quotes on paths with spaces on task schedule configuration or on scripts and batches. To avoid this try to state exit or close command on the end of the scripts or batches.
Even if the script or batch runs correctly sometimes return error code. To troubleshoot this you can run the script or batches manually using a pause statement at the end of it. To fix this you can add another command in the end in order to return an error status code 0. For example, add one line to write the current time. All the jobs created run. These jobs are setup to run every minute.
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. 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. 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. 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. It seems that CMD. Also, set the Scheduled Task to "Run with highest privileges".
General tab of the task properties. 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! 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.
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 In the Action section of the task, specify the script folder in Start in optional parameter. The job runs fine but I get 0x1 instead of 0x0.
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 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 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? 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 ".. After typing the directory name in the Start in field all works perfect.
If it's not a bug what is it??? Office Office Exchange Server. Not an IT pro? Windows Client. Sign in. United States English. Ask a question. Quick access. Search related threads. Remove From My Forums. Asked by:. Archived Forums. Sign in to vote. Monday, November 21, PM. Does the account you're running the task under have the "logon as batch" user right? Thanks for your response however! Proposed as answer by lazzas Friday, January 12, PM.
Tuesday, November 22, PM. Proposed as answer by Jeremy - Plus I. Friday, January 6, PM. I've tried running the WinSCP directly with the same results. This is very poor design and even worse documentation. Support by forum should be illegal. Steele at Sedgwick. Wednesday, July 11, PM. Proposed as answer by d6darren Tuesday, August 22, AM. Wednesday, August 22, PM. Wednesday, September 12, PM.
Thanks worked for me! Monday, October 8, PM. Thank you - this worked for me too! Monday, October 22, PM. Thursday, November 1, AM. Friday, December 14, PM. That worked for me too Thanks. Wednesday, March 20, AM. Thank you! Tuesday, June 11, AM. Thanks for tip, I got it to work finally! 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. The current batch file does not show me any errors or warnings.
I found that I have ticked "Run whether user is logged on or not" and it returns a silent failure. I've had the same problem. It is just a batch-file, working when manually started, but not working as a scheduled task. 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:. The problem was that the batch file WAS throwing a silent error. I found that the problem was to do with Powershell not being able to run scripts, if that's the case for you, here is the solution.
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:. 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. 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. 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. INI file. Here is a sample log from a batch file session run manually :. I was having problems getting Task Sched to run my batch file, too.
I'm using Windows Server R2. I had to do two things: 1.
0コメント