We have a winbatch executable that has been running as a scheduled task on windows server 2003 forever. Weââ,¬â,,¢re moving it to windows server 2008 R2. It runs fine when we run it interactively. It opens a window and I can see it moving and unzipping files.
When we run it as a scheduled task, it starts and I can see it move a file. However, it stops and doesnââ,¬â,,¢t run gunzip. It doesnââ,¬â,,¢t bring up a window or anything.
Weââ,¬â,,¢re running it as my user which is an administrator on the box and itââ,¬â,,¢s running with highest privileges. Have you heard of something like this before? Have any ideas what else we could check? Iââ,¬â,,¢ve checked just about everything I can think of.
Thank you in advance for your assistance.
Could be any number of things. It could be caused by a file redirection problem or it could be some UAC issue (even if you think it is running with 'highest privilege'.) It might even be the result of something simple like not having the correct current working directory or not having the "Run only when user is logged on" setting checked so the task will not run hidden.
Neglected to mention that the Task Scheduler does maintain an event log for tasks. You might find some useful information there. And you can always add a DebugTrace to your script. The trace file may tell you exactly where and why your script is hanging.
We have DebugTrace turned on and can see all of the steps until is seems to hang. We follow execution to a call to a function that is defined in an include file. The trace just hangs at that point. The task doesn't stop and we don't get any more lines to the trace file. This is very perplexing.
If we run the task directly from windows, it runs fine. If we run the task as a scheduled task in 2003 compatibility mode, it runs fine. It's only when it's in 2008 R2 compatibility mode. Unfortunately, we would really like to run it in 2008 mode.
You never stated if you have the 'Run only when user is logged on' setting enabled for your task. Also don't recall you providing WinBatch version information.
You also need to add a d DebugTrace call to each UDF in order to produce trace out inside each called UDF.