Scheduled task not running

[dirtdart]

I have a Windows 2000 server using ActivePerl 5.8.8. I have written a small script to back some files up and am attempting to run it as a scheduled task. I have tested the script from a command prompt and everything works exactly as I expect it to. However, when I try to run the same script as a scheduled task, it exits immediately. I have tried it both with and without the shebang and have tried several different variations on the command line.

C:\backup\backup.pl - gives an exit code of 1
C:\perl\bin\perl.exe C:\backup\backup.pl - gives an exit code of 1
C:\perl\bin\wperl.exe C:\backup\backup.pl - gives an exit code of 9

Just to eliminate any possibility of permissions issues while debugging, I'm using my logon account as the account that the scheduled task is running under. I've also tried converting the script to a batch file using pl2bat, but I get the same results. I'm not even sure where to start with this, so any help will be greatly appreciated.

[grinder]

I wrap the perl script in a .cmd file (this allows you to control precisely what the environment looks like when the script hits the road), and also save the output:

c:
cd \backup
echo run backup.pl >backup.out
perl backup.pl >>backup.out 2>backup.err

And then you can check the timestamps of backup.out and backup.err to ensure that the script was actually run and not merely that the scheduler ignored it (or the scheduler service was stopped -- this happens too).

Since you're redirecting STDOUT, feel free to go crazy with print traces. It'll help you track down what went wrong.

Depending on your infrastructure, you might want to drop a use Win32::EventLog::Carp at the top of the program, and then any warn or die messages will be logged in the Event Viewer.

[jczeus]

Doesn't the script give any output - error messages, warnings? The exit code alone is not very descriptive. My guess is that the script tries to access files specified by a relative path (which works if you run the script from C:\backup, but fails if you start it from a different working directory), or it tries to use modules that are not in @INC.