Solved

cscript.exe and wscript.exe don't execute

Posted on 2007-04-05
20
1,134 Views
Last Modified: 2013-12-04
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
0
Comment
Question by:woutervw
20 Comments
 
LVL 66

Expert Comment

by:johnb6767
Comment Utility
Have you tried to upgrade to the latest WSH? Latest is 5.6......
0
 

Author Comment

by:woutervw
Comment Utility
Yes, downloaded directly from Microsoft, installed and no success.
0
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 

Author Comment

by:woutervw
Comment Utility
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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 
LVL 5

Expert Comment

by:drtoto82
Comment Utility
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
 

Author Comment

by:woutervw
Comment Utility
>> 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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Author Comment

by:woutervw
Comment Utility
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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 

Author Comment

by:woutervw
Comment Utility
Thanks. I'll work on that next week. There's some systems maintenance I need to take care of this weekend.
0
 
LVL 25

Expert Comment

by:Ron M
Comment Utility
Go to command prompt and type "set"
copy and post the output please.
0
 

Author Comment

by:woutervw
Comment Utility
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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 

Author Comment

by:woutervw
Comment Utility
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
 
LVL 1

Expert Comment

by:advapp
Comment Utility
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
 

Accepted Solution

by:
AnnieMod earned 0 total points
Comment Utility
PAQed with points refunded (125)

AnnieMod
Cleanup Admin
0

Featured Post

Why spend so long doing email signature updates?

Do you spend loads of your time carrying out email signature updates? Not very interesting are they? Don’t let signature updates get you down. Let Exclaimer Cloud - Signatures for Office 365 make managing email signatures a breeze.

Join & Write a Comment

NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
Sometimes drives fill up and we don't know why.  If you don't understand the best way to use the tools available, you may end up being stumped as to why your drive says it's not full when you have no space left!  Here's how you can find out...
The viewer will learn how to successfully create a multiboot device using the SARDU utility on Windows 7. Start the SARDU utility: Change the image directory to wherever you store your ISOs, this will prevent you from having 2 copies of an ISO wit…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now