WScript.Shell causes Catastrophic Failure 1

[AntiEarnie]

Not quite sure what else to try on this one. I have dug around google for a while with no luck. When I use CreateObject("WScript.Shell") on one of my servers it crashes out with:
Catastrophic Failure
code: 8000FFFF
source (null).

Every script I have that uses this object fails out with this same error. Even the example code from the Windows scripting guide fails. The server is running Win2k Adv SP4. I have also tried reinstaling a fresh copy of WSH 5.6.

Has anyone come accross this before?

 

[tsuji]

Hello AntiEarnie,

Inspect the registry at this location, what do you have as value for "IExplorer.exe":
[tt]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_LocalMachine_Lockdown]
[/tt]
If it is dword:00000001, change it to dword:00000000 see if it takes out the local machine lockdown on shell. (Security impact at your own risk. Change it back if you want restore default.)

regards - tsuji

 

[AntiEarnie]

tsuji -
I am not having any luck finding FeatureControl in Main. I tried both browsing to it and running a find in regestry for iexplorer.exe and featurecontrol. Sure this is a setting in win2k server?

 

[tsuji]

AntiEarnie,

You're right. It would not be. I was hyper-sensitive when I read win-something with sp-something. I thought without reading it's winxp sp2!... due to some pre-occupation. No, the key is for winxp sp2. My bad!

I would suggest check out the registry whether it has the WScript.Shell key as expected in HKLM\Software\Classes branch? Also use the identified CLSID trace its setting in the HKCR\CLSID\{xxxx...} branch to see if there is something wrong with the InProcServer32 setting which should be default to WSHOM.OCX.

- tsuji

 

[AntiEarnie]

Wow, Yeah it looks like this sever is short a few entries in HKCL. The class is missing InProcServer32, Programmable,TypeLib, VersionIndependentProgID, and Implemented Categories. This is compaired to two of my other servers.

Any suggestion besides manualy adding in the various key values? If memory serves thats what I had to do last time a Object was short some entries.

 

[tsuji]

AntiEarnie,

[1] Try run the ie repair on the server.
[2] After that, if the problem persists, register it manually. (Supply the exact path if necessary.)
[tt] regsvr32 wshom.ocx[/tt]

- tsuji

 

[AntiEarnie]

Tsuji -
Running repair on IE didn't do anything noticable.
After using regsvr32 wscript is now showing correctly in regestry.


Annoying thing is that I Still get catastrophic failure errors on the following:

fud.vbs

set oFud = CreateObject("WScript.Shell")

Even with nothing but that line the script fails on this trouble box.

As a side note I have gone and checked over Component Services and was unable to find anything that did not match up with our other servers. Also regestry entries now match with working servers for this object.

 

[AntiEarnie]

Joy. I've started getting event log errors after reregestering:
Source COM+
EventID 4266

I have:
unregestered it and reregestered it - same error
unregestered it and reinstalled wsh 5.6 - same error
unregestered it and REPLACED wshom.ocx with one from a working server then reregestered - no change

As a side note the trouble box had version 5.6.06626 wshom I tried replacing it with 5.6.08515. Not sure how I got different versions unless a previous patch did not apply all the way. Still no errors coming up on component servies.

I give. Is there a way to just remove WSH so that I can fully replace it? We had problems with the FileSystemObject not too long ago also but at least got that one fixed.

 

[tsuji]

AntiEarnie,

My understanding is that you can just install wsh latest version (NT for NT, 9x for 9x). Components would be overwritten and by so updated... I am curious!

- tsuji

 

[AntiEarnie]

tsuji -
So far that has not worked. Reinstaling WSH 5.6 from both the microsoft site and from the disk that came with my windows scripting book caused no change in the errors. I uninstalled IE 6 yesterday and I'm going to try to reinstall it today to see if it makes a change.

If reinstall of IE6 over IE5.5 does not work then I fear I am down to using one of our calls to microsoft. When we had something like this with the FileSystemObject last year they worked on it for a good week and did not solve it. I am not hopeful that I will find a solution there but I am ready to get this little bug off my long list of minor things to do.

 

[tsuji]

AntiEarnie,

How about running this command line to make sure the sanity of wsh as a whole?
wscript -regserver

- tsuji

 

[AntiEarnie]

tsuji -
Reregestering the wscript.exe did not cause any changes in the errors. Still get catastrophic failure and the com+ error in the event log. I'm starting to get curious just how many other objects might be broken in wsh. I might try putting together something to sep through the objects and record failures.

 

[tsuji]

AntiEarnie,

Run a little .js script to test if the jscript engine survive.
[tt]
var WshShell=new ActiveXObject("WScript.Shell");
WScript.Echo("WinDir is " + WshShell.ExpandEnvironmentStrings("%WinDir%"));
WshShell=null;
[/tt]
As the second further diagnostic, run your vbs with wscript native engine like this.
[tt]
set wshshell=wscript.createobject("wscript.shell")
[/tt]
see if it fails as well.

- tsuji

 

[AntiEarnie]

tsuji -
The JScript throws the standard Catastrophic failure message.

The vbs script throws "Could not create object named "wscript.shell". Dropping the wscript off the create object gives the same message as I have been getting.

 

[AntiEarnie]

Ok. This bug is just plain strange.

I decided to try removing/reloading the component from component services. I dug around until I found wscript.shell.1 and got a popup box with the error from the event log, no suprise there. Did a right-click on the wscript.shell.1 and delted it. What is strange is when I went went to add the component back I browsed over to wshom.ocx and everything was already found... Double checked, and yes, wscript.shell.1 was indeed gone. Out of curiousity I tried running the problem scripts again and they work now...

The only thing that seems to make sense is that there might be another copy of the component that was conflicting. It is just strange that I have not found any differences so far between the trouble server and the failover server.