6

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.

Improve this question
3
  • Does your script access anything over the network, e.g. shared folders, or does it run entirely locally?
    – Chris W. Rea
    Commented Dec 3, 2010 at 19:37
  • 2
    Did you target the file with an absolute name? Example: C:\Storage\batchfile.bat
    – Doltknuckle
    Commented Dec 3, 2010 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
    Commented Aug 15, 2011 at 4:23

5 Answers 5

Reset to default
8

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.

Improve this answer
3

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

Improve this answer
1
  • This solved my problem.
    – David
    Commented Oct 19, 2014 at 3:29
1

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!

Improve this answer
1

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.

Example:

@echo off
net use Z: \\server\share /u:domain\username *password*
robocopy c:\folder Z:\backup /o /p /t /i /o /n /s
Improve this answer
1
  • 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
    Commented Mar 21, 2018 at 21:24
0

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:

"W:\blah\script.py"

I now use this argument:

"\\file-server-02\path\blah\script.py"
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .