cscript.exe and wscript.exe don't execute

Hi,

On some machines cscript.exe and wscript.exe stopped executing. When run from the command line, they just immediately come back without the normal copyright and usage messages. Even when I invoke cscript from another machine through a shared drive, the same thing happens. I've found a Windows 2000 server (SP4) and a couple of XP machines (SP2, Prof) that show this behaviour. Nothing in the event logs that show that anything might be wrong.
I tried without the virus protection with no effect. Reinstalling WSH doesn't help either.

It seems to me that something is intercepting the request to have the scripting host started. When I start it from a URL on another machine (ie: \\somepc\c$\winnt\system32\cscript.exe), the command prompt comes back immediately, even if the 'somepc' is behind a slow link.

Any ideas how to troubleshoot this?

Kindest regards,

Wouter
woutervwAsked:
Who is Participating?
 
AnnieModConnect With a Mentor Commented:
PAQed with points refunded (125)

AnnieMod
Cleanup Admin
0
 
johnb6767Commented:
Have you tried to upgrade to the latest WSH? Latest is 5.6......
0
 
woutervwAuthor Commented:
Yes, downloaded directly from Microsoft, installed and no success.
0
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

 
advappCommented:
Are you getting any additional messages?
This registry setting can limit the conditions under which scripts run.
      Key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings
      Value: TrustPolicy
      Data: "0" = all, "1" = prompt, "2" = only trusted

Since it is specific systems exhibiting this, I'd look into the policies on those systems: Administrative Tools -> Local Security Policy or there may be domain policies in place, too.
0
 
woutervwAuthor Commented:
No messages at all. The prompt comes back so fast I'm doubting the executable is even accessed.

TrustPolicy=0. I checked the other setting ("enabled") too on the affected machines and the setting doesn't exist (which means it's enabled).

I just looked at the local policy and the Group Policy Results for a specific user/PC that has this problem. Nothing that jumps out, and no changes were made to them recently.
0
 
advappCommented:
Ok, let's start with the basics.  You may have already done some of this...

At the command-line, If you enter just "CScript" with no arguments, do you even get the banner and help?  Likewise, "WScript": do you get the dialog?

Are the properties of csript.exe and wscript.exe different in any way with those on the working systems -- size, version, manufacturer, etc.

0
 
drtoto82Commented:
something may be far off the minds.
Do you have a group policy configured on your network that prohibits executing batches ?
Make sure of that.
0
 
woutervwAuthor Commented:
>> At the command-line, If you enter just "CScript" with no arguments, do you even get
>> the banner and help?

No. That was my first clue that something was seriously amiss. Neither with cscript, nor with wscript. Even trying to execute them from a different machine through a share doesn't change the behaviour.

>> Are the properties of csript.exe and wscript.exe different in any way

No.

>> Do you have a group policy configured on your network that prohibits executing batches ?

No.
0
 
advappCommented:
Here's what I would do next:
 * copy the exe to a new name (e.g., xcsript.exe) to see if the differntly-named copy behaves any differently.
 * copying an exe from a working system to a non-working system.
 * run a process monitor (e.g.,Task Manager, SysInternals ProcessExplorer) and see if they even show up -- however briefly -- in the task list when I execute them.
0
 
advappCommented:
Some additional thoughts:
 * McAfee (maybe other VS scanners) has a script blocking feature.  I think it doesn't do anything visible but log an event in the agent log.
 * I'd check the activity logs for any related events -- especially around the time when your script is supposed to run.  Not always fruitful but worth a try.
0
 
woutervwAuthor Commented:
I tried copying it to a new name and that didn't help. Neither did copying it from a working machine. Nothing shows up in the event logs that indicate anything. With or without the virus scanner (F-Secure), the results are the same.

I ran procmon on one of the machines and it seems that cscript.exe is running for a little while. The information of procmon didn't give me any clues, but then again, I'm not too knowledgeable in that field (that's why I'm here). I uploaded the logfile to http://www.chs-wa.org/Logfile.zip if anyone needs that information.
0
 
advappCommented:
One of my contacts said he had encountered a similar circumstance once before.  He said the only thing that fixed it was reinstalling the scripting engine. :-(

Looking at your procmon log -- and though I couldn't tell what was just script and what was part of a script -- it has given me some ideas.  I ran procmon and captured just the event of cscript.exe being run with no parameters and think comparing that between working/non-working systems might be illuminating.

Try this:  Using procmon on the non-working system:
 * Set it to filter only to cscript.exe: (Filter -> Process Name - is - cscript.exe; click [Add], then [Ok])
 * Clear the display (if not already clear)
 * At the command line, execute cscript.exe
 * Save that output
Repeat the steps on a working system.  There may be some differences but I would expect them to be essentially the same except for where it is failing.  As a control, you could do this on several of the working systems just to identify any other areas that might vary between working systems.
If you'd like, you can post a link for me to grab that log and I can compare it against mine, too, and give you some additional feedback.
0
 
woutervwAuthor Commented:
Thanks. I'll work on that next week. There's some systems maintenance I need to take care of this weekend.
0
 
Ron MalmsteadInformation Services ManagerCommented:
Go to command prompt and type "set"
copy and post the output please.
0
 
woutervwAuthor Commented:
Here is the comparison of procmon on two identical PCs. One is working, the other isn't. No significant differences in installed software between the two PCs.

http://www.chs-wa.org/CSCRIPT-PROCMON.zip

The environment of the non-working PC:

http://www.chs-wa.org/non-working.set.txt
0
 
advappCommented:
The path statements on the two systems appear to be significantly different. (I wasn't able to open either proc log; both caused the program to abort.  Weird.  Good thing you included the CSVs.)  Take a look and verify the path statements on the two systems.
0
 
advappCommented:
Actually, I just looked at the set output you provided.  The path on the non-working is pretty short.  So that appears to be a side-track.
0
 
woutervwAuthor Commented:
Problem solved. The computers that didn't run cscript.exe or wscript.exe had a wshenu.dll file in the system32 directory. Once this file was removed, the scripting engine worked fine again. No idea why these DLLs were there. They don't need to be there as far as I can tell from information on microsoft.com.
0
 
advappCommented:
Very interesting.  Well, glad you were able to resolve it.  I will definitely remember this one.  One would assume the wshenu stands for "Windows Scripting Host English" but what it does?  Hmmm....
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.