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

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!

share|improve this question
add comment

2 Answers 2

up vote 1 down vote accepted

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*

share|improve this answer
add comment

Sounds like an issue with rights of the scheduled task. Make sure the task is assigned the credentials needed to launch Windows Script Host. Within the task manager, there should be a place to define the account credentials that the task runs under.

share|improve this answer
    
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 :( –  Django Reinhardt May 31 '10 at 12:48
    
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. –  Jay May 31 '10 at 13:01
    
Yep, the credentials all work. It wouldn't let me save the changes unless they did. There are no permissions to alter :( –  Django Reinhardt May 31 '10 at 14:15
add comment

Your Answer

 
discard

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.