Greets, I have a task scheduled that calls a script; the script creates a COM object and calls a method that may or may not succeed. When the method returns failure, the script calls WScript.Quit(255). When it fails the Last Run Result column for the task correctly indicates "(0xFF)", as opposed to "The operation completed successfully (0x0)", but history shows "task completed". Bottom line, for purposes of the "If task fails, restart every..." setting, the scheduler doesn't consider ERRORLEVEL == 255 to be a "failure", it treats it as if it was successful, the task does not get restarted. I also tried setting the script timeout to 60 seconds and then making it sleep for 65535 ms on failure, no love. If I manually end the task, it sees *that* as failure and the task is queued for a restart -- but that's hardly a solution, it rather defeats the purpose of scheduled tasks... Hmm, check that, it attempted to execute the task immediately after I manually ended it, status was "Queued" for a little longer than the retry interval I specified, then status changed to "Ready"... nice... So is this entire feature broken, rendering my question moot, or what? TIA, MM

On a hunch, try returning 2 or 4 instead of 0xFF. This is just a wild guess, but in the golden days of yesteryear in DOS an ERRORLEVEL of 2 was "error" and 4 was "severe error". It couldn't still be looking for those values, could it? :) -Noel

On a hunch, try returning 2 or 4 instead of 0xFF. This is just a wild guess, but in the golden days of yesteryear in DOS an ERRORLEVEL of 2 was "error" and 4 was "severe error". It couldn't still be looking for those values, could it? :) -Noel Thanks for the suggestion, I tried it, but no love. Here is what the history log had to say about it: Task Category: Action completed Level: Information Description: Task Scheduler successfully completed task "\testtask" , instance "{dc574df1-93ba-4468-bc2c-9d85000c087c}" , action "c:\windows\syswow64\cscript.exe" with return code 4. Apparently ERRORLEVEL is not considered. To test a fatal error I created a task with action set to run an .exe (rather than a batch or script), then renamed the .exe. This time the history did indeed indicate failure, but again it restarted the task only one time, imediately after failing, status changed to Queued, then nothing until the next time it was scheduled. Perhaps if it actually waited one minute between retries (as it is configured to) I could restore the name of the .exe, but I doubt even that would work, a successfully executed task generates 7 log entries, failure generates six, ending with "task restarted". I'm forced to conclude that the task restart functionality is broken, and even if it wasn't, the failure dection mechanism is under-engineered to the degree that its potential to be useful has been cut to the bone. -MM

The Task Scheduler cannot read the result and the return code of the script. It can only get the task status which is that whether the task has run or not. If the task has run, whatever the result of the task, Task Scheduler will consider that the task is successful. You need to add the re-run script if it was failure commands inside the script. For detail information regarding the script, I suggest you discuss in our Script Center forum. The Official Scripting Guys Forum! http://social.technet.microsoft.com/Forums/en/ITCG/threads/Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Have you tried explicitly throwing an error from within the script as the last thing in the error-exit cases? -Noel

Have you tried explicitly throwing an error from within the script as the last thing in the error-exit cases? -Noel That sounded like a great idea, but in practice it was less effective than setting ERRORLEVEL with WScript.Quit; the task scheduler indicates success even when the script explicitly throws an exception.. Thanks, MM

>> The Task Scheduler cannot read the result and the return code of the script. << Actually that's not entirely true, it can and does read the return code (returned by the script engine process, as specified by the script,), it displays that value in history and last-run task status. It merely doesn't evaluate that value, in terms of success or failure. Seems like a design oversite to me, but that's just my opinion. >> If the task has run, whatever the result of the task, Task Scheduler will consider that the task is successful. << A rather shallow assumption, wouldn't you have to think? >> You need to add the re-run script if it was failure commands inside the script. << Eeesh, that's so much less functional. If I went that route I may as well roll my own scheduling and logging scheme; implementing that would not be a challenge, but almost all the benefit of the task scheduler would be lost. I thought about adding my adding a new, one-time task to the schudler (I'm assuming there's a published API) on failure, but it hasn't been important enough for me to pursue that angle, yet. Thanks, MM

Dang, I had high hopes for throwing an exception. Sorry that didn't work out. -Noel

So did I! I dropped what I was doing to try it when I got notice of your post (wondering why I didn't think of it -- I did try raising an error inside the COM object, but the default handler generated UI that hung the call.) Apparently CScript only dumps a message to the console for uncaught errors. Return code was 0x0. The task settings provide a way to specify that the task should be killed if it runs longer than [duration], minimum setting is 1 hour. I could make either the script or the COM twist in the wind for that long... but without any reason at all to expect the retry functionality to perform in a way that is even remotely usable, it seems like throwing good after bad. (The same logic would've applied to your idea as well, but it seemed like such a good one, I got caught-up in the moment.) :-) -MM

The Task Scheduler cannot read the result and the return code of the script. It can only get the task status which is that whether the task has run or not. If the task has run, whatever the result of the task, Task Scheduler will consider that the task is successful. You need to add the re-run script if it was failure commands inside the script. For detail information regarding the script, I suggest you discuss in our Script Center forum. The Official Scripting Guys Forum! http://social.technet.microsoft.com/Forums/en/ITCG/threads/ Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ” This might be petty but I have issues with flagging the response quoted above as the "Answer". For one thing, it contains an obvious, glaring inaccuracy (the Task Scheduler is most definitely able to read the return code, it displays it in its UI.) More, though the work-around it suggests is technically feasible, it leaves many things to be desired, it forces the user to either re-implement some important task scheduler features that do function, or get by without them. A solution, it is not. The actual answer is that the Task Scheduler is both underdesigned (it would be much more functional if it used return value conditionally) and broken (re-run on failure functionality is inconsistent with description and associated settings, and is effectively useless.) In a perfect world this issue would become an action item for the service pack team. (In this world my expectations are decidedly quite low.) -MM

The Task Scheduler cannot read the result and the return code of the script. Works as mis-designed. Shame on MS for that.