Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We develop a web application that can be deployed on Windows or Linux. The Linux implementation uses cron, and the Windows one uses scheduled tasks to run a single PHP script that processes all scheduled tasks for our system.

The task is scheduled using schtasks during the install process, like:

This has always worked both under W2003 and W2008. A week ago a customer reported that scheduled tasks were not running. He is running on Windows 2008. We checked over and over and finally solved the issue by entering the folder that contains the .vbs script as the "start in" folder for the scheduled task.

This said, there is no way to set up the "start in..." value from schtasks without using an XML definition of the tasks. XML definitions don't work in Windows 2003, so I would have to add windows version detection to the installer, additional testing, etc (I'd like to avoid this if at all possible).

The only atypical thing I noticed about the install is that the system is installed in D:\ as opposed to the default C:\Program Files (x86)\, but I don't see how this would matter. All the paths are absolute in all the scripts.

Can anyone suggest a reasonable solution for this?

share|improve this question
I finally traced this to a buggy PHP encoding module (SourceGuardian). Although there were no relative paths whatsoever on the scripts, encoded scripts failed to run without "start in" set if they were installed below drive letter other than C:. I ended up wrapping the call in a batch script that did "cd <DRIVE>" before the call and everything worked. –  GomoX May 28 '13 at 15:14

3 Answers 3

The "start in" is mainly to make sure that if you have relative paths in the task to run it understands which directory to run the script in.

That said, this link might help you: http://stackoverflow.com/questions/1020023/specifying-start-in-directory-in-schtasks-command-in-windows

share|improve this answer
In theory yes, but in practice not really. My script has absolute paths all over and can be run from cmd starting in C:\ or anywhere else without problems. It's just the scheduler that chokes on it. –  GomoX Feb 22 '13 at 12:33
Is the scheduler choking on it if you run it manually as that same logged in user that you can run it anywhere? You should delve into why it "has always worked" and suddenly doesn't. –  TheCleaner Feb 22 '13 at 14:20
The task is run as system, so I can't really reproduce the environment myself, can I? It's not that it has "always worked", I'm thinking it may have never worked but this only happens on specific setups. It works fine on our testing environments, but I have seen a number of customer servers where it doesn't without the "start in" setting. Maybe it has to do with UAC or a security policy? –  GomoX Feb 22 '13 at 14:30
And maybe you missed one of those hard-coded paths somewhere? –  Michael Hampton Feb 22 '13 at 14:46
@GomoX - you said in your first comment here: "can be run from cmd starting in C:\ or anywhere else without problems". But then say you can't reproduce it. Which is it? It doesn't really matter if you can run it from cmd on your dev environment...testing with the customer is what will be required in a real world environment. Or you can call it a day and just say "add the start in" in your install docs. –  TheCleaner Feb 22 '13 at 14:51

Solution to what, exactly?

The start in value is exactly what it sounds like, the directory in which the application/program/script starts. This matters for when it calls other resources. If it calls somecustom.exe that's not in that start in directory, it won't be found, and your application/program/script will error out. If you call absolutely everything by path, it shouldn't matter, but the behavior you're describing would seem to indicate it's not actually doing that, so you could try to correct that behavior, or a quick workaround (if ugly and kind of crappy solution to actually getting the code right) would be adding the directory to the %PATH% variable, so Windows will always check the directory when an executable file is called without a referenced path.

If you're working in Windows 2008/7/Vista, you can also use a switch set the start in directory with schtasks /v1, so long as you're not trying to run the tasks under the SYSTEM account. I think I'd prefer to make the developer debug his code, but YMMV.

share|improve this answer
I'm the developer, and everything is set with an absolute path. The same command works fine under Windows 2003. So there shouldn't be any need for the "start in" setting. Still, no dice on some installs. –  GomoX Feb 22 '13 at 12:32

I got problem when running the script in D drive. example: The file was not moved to backup folder even it is clearly specified the directory drive. However when I specified parameter in Start In as D:\ script work well.

share|improve this answer
Welcome to Server Fault! Please do not post Answers unless they actually answer the Question. ServerFault is a Q&A platform and not a forum. If you have new Question, please ask it by clicking the Ask Question button from the menu at the top of this page. Welcome to ServerFault and thank you. –  HBruijn Jun 25 at 6:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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