Task Scheduler not able to execute .vbs scripts successfully

Question

Apologies if this has a really obvious answer!

We have several daily tasks we run via a .vbs script on our server (through the Task Scheduler), and for months it has been fine, but recently we've hit a problem. The .vbs scripts stopped successfully executing (always timing out)... but could still be executed manually with no problems(!).

Not knowing any good reason why the Task Scheduler should start having problems, we thought we'd try a little "creative thinking", and run the .vbs another way: Via a .bat file executed by the Task Scheduler. Again we hit weird issues, but with a little more debugging information, this time around.

The .bat file run by Task Scheduler is nothing more than...

CScript "C:\location\script.vbs" > Log.txt

But after an attempt to run it, the Task Scheduler fails with the following error:

0x1: An incorrect function was called or an unknown function was called.

The Log.txt (as output from the .bat file above) says:

CScript Error: Initialization of the Windows Script Host failed. (Not enough storage is available to process this command. )

But get this: The .bat file executes perfectly (vbs script and all) if it's executed with a double click! There's only a problem when it's run by Task Scheduler. What the hell?

We're running Windows Server 2008 R2 (x64) and yes, the Task Sheduler's results are the same whether the user is logged in or not. Also, the user that can run the scripts successfully manually, is also the same user that runs the scripts in Task Scheduler.

Thanks for any help for this weird problem!

Solution

It was actually lack of memory, as it turns out. Restarting the server and freeing up 16Gb again, allowed it to be run after all. No issues with user permissions. No issues with user credentials. It was just a weird memory problem (I noticed something was up when I couldn't start SQL Configuration Manager or successfully install any Updates through Windows Update).

I'm guessing that Task Scheduler didn't have permission to take back RAM, whereas the admin user running the .bat by hand, did.

Can of worms: Opened. *sob*

Comments

[Mack]

Yes, I thought this too, but it still doesn't add up: The user is an Administrator. The tasks are set to run whether the user is physically logged in or not. And finally I even tried to ticking "Run with highest privileges". All to no avail :(

[Abuzar Manzoor]

Still, try manually setting the permissions and password in the scheduled task. There are times I've thought "this should work" only to find it doesn't. I had a similar issues with tasks when I changed the system password on a server and found that the tasks weren't running... because their original credentials didn't match the new authentication.

[Mack]

Yep, the credentials all work. It wouldn't let me save the changes unless they did. There are no permissions to alter :(