I have identical scheduled tasks running in Windows XP Pro and Windows 7. The XP Pro one runs fine, the Windows 7 one always returns 0x2 (which means, "The system cannot find the file specified"; however, executing from the command line is no problem) in the Last Run Result column of the Task Scheduler UI.

The scheduled task executes a .bat file daily. The .bat file contains a call to execute a Perl script. As I stated in the previous paragraph, it executes under XP without any trouble but under Windows 7, no dice.

The task under Windows 7 is set to "run whether the user is logged on or not." In this case it is me, I am the only user of the system. It is also set to "Run with highest privileges." And it is not hidden. The .bat file executes perfectly well from the command line - it calls the Perl script as expected and the Perl script does its thing.

I have searched far and wide looking for an appropriate answer to this issue. So far I have found nothing. What the devil is going on with this Win7 scheduled task? I am ready to pull my hair out.

  • Does your script access anything over the network, e.g. shared folders, or does it run entirely locally? – Chris W. Rea Dec 3 '10 at 19:37
  • 2
    Did you target the file with an absolute name? Example: C:\Storage\batchfile.bat – Doltknuckle Dec 3 '10 at 19:44
  • 1
    Have you set the working/current directory correctly? When you say that it works from the command-line, what directory do you run it from? Does it work from any directory? – Synetech Aug 15 '11 at 4:23

I had this issue as well. 0x2 from task scheduler seemed to say it couldn't find the batch file. This was false - I added some pipe arrows (>>) to output my batch file to a logfile, then ran the scheduled task.

Despite getting a 0x2 in Task Scheduler, I found the batch file had actually run, but had encountered an error (which showed up in the logfile).

Another thing to try is running the task as SYSTEM or NETWORK SERVICE instead.


I just had this same issue and resolved it. In the Actions tab, under Program/Script: just put the name of your batch file. In the "Start In (optional):" section, put the path to your file with no quotes and no ending slash.

Example below for running a test.bat file out of a test folder on the root of C:

Program/Script: test.bat

Start In (optional): C:\Test

  • This solved my problem. – David Oct 19 '14 at 3:29

I was trying to sync a folder pair with SyncToy 2.1 across two Windows 7 SP1 workstations. Initially, I just browsed for the file and added the arguments for the task. It returned a code of 0x2. Microsoft TechNet recommends using the "Start In" field to ensure the file name is resolved to the correct location. I copied the SyncToy directory path with no quotes or a trailing slash into the "Start In" box, saved it and ran the task. The result was success, the code 0x0!


In my case I was using a mapped drive as a destination, but the drive wasn't mapped in the context of the script (user logged off), so I had to map the drive inside the script before I could use that mapping.


@echo off
net use Z: \\server\share /u:domain\username *password*
robocopy c:\folder Z:\backup /o /p /t /i /o /n /s
  • 1
    This answer identified the problem for me, but the better solution (in my case at least) is to use UNC paths instead of mapping a network drive. – Son of a Beach Mar 21 '18 at 21:24

Similarly to @Levi, I was using a mapped network drive. However, in my case, the simpler solution was to change it use UNC paths. Eg, instead of using this argument:


I now use this argument:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.