Solved

cscript.exe and wscript.exe don't execute

Posted on 2007-04-05
20
1,139 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
ID: 18861297
Have you tried to upgrade to the latest WSH? Latest is 5.6......
0
 

Author Comment

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

Expert Comment

by:advapp
ID: 18861557
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
ID: 18861680
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
ID: 18861800
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
ID: 18861876
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
ID: 18864912
>> 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
ID: 18865326
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
ID: 18865378
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
New My Cloud Pro Series - organize everything!

With space to keep virtually everything, the My Cloud Pro Series offers your team the network storage to edit, save and share production files from anywhere with an internet connection. Compatible with both Mac and PC, you're able to protect your content regardless of OS.

 

Author Comment

by:woutervw
ID: 18866820
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
ID: 18867332
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
ID: 18867756
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
ID: 18868755
Go to command prompt and type "set"
copy and post the output please.
0
 

Author Comment

by:woutervw
ID: 18877414
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
ID: 18893537
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
ID: 18893559
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
ID: 18977153
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
ID: 18978339
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
ID: 19389253
PAQed with points refunded (125)

AnnieMod
Cleanup Admin
0

Featured Post

3 Use Cases for Connected Systems

Our Dev teams are like yours. They’re continually cranking out code for new features/bugs fixes, testing, deploying, testing some more, responding to production monitoring events and more. It’s complex. So, we thought you’d like to see what’s working for us.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

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...
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…
This is used to tweak the memory usage for your computer, it is used for servers more so than workstations but just be careful editing registry settings as it may cause irreversible results. I hold no responsibility for anything you do to the regist…

895 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

21 Experts available now in Live!

Get 1:1 Help Now