Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

The Case of the Disabled Script Engines

Posted by William Diaz on January 4, 2012

Recently, users began reporting problems with certain functionality in Internet Explorer not working, including problems with the native Windows XP Search fields missing. In all cases, this was resolved by registering Jscript. At the same time, there were other reports of Windows Script Host errors when trying to process logon scripts: “Windows Script Host. Can’t find script engine ‘VBScript’ for ‘C:\path\Filename.”
This was also fixed by registering VBScript.

VBScript and JScript are both part of the MS Windows Script Engine, so it was likely that the symptom for both DLLs not being properly registered was the result of the same cause. To establish why either of the DLLs had a failed registration, I needed to look at their working entries in the registry and compare to one of the problem workstations. The keys for both DLLs in the Windows XP* OS can be found in:

  • For JScript – HKCR\CLSID\{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}
  • For VBScript – HKCR\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}

Each contains a subfolder called InprocServer32 which contains a default value that points to the location of the script module, which normally is C:\Windows\System32:
On the problem workstations, InprocServer32 actually points to the path of our AV program folder and a corresponding ScriptSn.datetimecreated.dll:
A little research reveals that the ScriptSn.dll files are created by the McAfee ScriptScan feature. Think of McAfee Script Scan like a script proxy:
The reports of these issues coincided with a recent upgrade of one of the AV components. In cases where either JScript or VBScript were not working, it was because the ScriptSn DLLs no longer existed in the McAfee program folder. Likely, what happened during the upgrade on some workstations, was the ScriptSn files were deleted but not correctly unregistered and/or the new scriptsn modules not registered for whatever reason. Further research points to this McAfee discussion: and recommendation to apply Patch 1 for VSE 8.8 to correct. As a workaround, you could also simply unregister ScriptSn.dll, which would restore the registry to the default locations for both VBScript and JScript. Eventually, the Script Scan module should reapply correctly at some point afterwards with a new ScriptSn.dll.

*In Vista and Windows 7, the CLSID for VBScript is the same but the path different for the 32 bit module:

  • VBScript
    • 64 bit – HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
    • 32 bit – HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}

The Jscript module for Vista and Windows 7 is different, however, and the name for scripting module is also different depending on which version Internet Explorer is installed:

  • JScript (IE 8 – jscript.dll | IE 9 – jscript9.dll)
    • 64 bit – HKEY_CLASSES_ROOT\CLSID\{16d51579-a30b-4c8b-a276-0ff4dc41e755}
    • 32 bit – HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{16d51579-a30b-4c8b-a276-0ff4dc41e755}

4 Responses to “The Case of the Disabled Script Engines”

  1. […] The Case of the Disabled Script Engines […]

  2. […] The Case of the Disabled Script Engines […]

  3. […] To fix this, you need to get back the VBScript and JScript registry entries. I haven’t had to do this myself, but I think this page gives a good explanation of the problem and what to do: […]

  4. […] The Case of the Disabled Script Engines […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: