none
Vista IE 7 unable to run VBS Scripts RRS feed

  • Question

  •  
        All of my VBS scripts are now failing on Vista Ultimate x86 SP2 with IE 7.  I have tried these troubleshooting steps:
     
    • attempt to run script from both cscript.exe and wscript.exe, error message identical: "Can't find script engine "VBScript" for script..."
    • registered these DLL files (all registered correctly without errors) from an elevated cmd prompt
    Regsvr32 %SystemRoot%\System32\jscript.dll
    Regsvr32 %SystemRoot%\System32\scrobj.dll
    Regsvr32 %SystemRoot%\System32\scrrun.dll
    Regsvr32 %SystemRoot%\System32\vbscript.dll
    Regsvr32 %SystemRoot%\System32\wshext.dll
    Regsvr32 %SystemRoot%\System32\wshom.ocx
    • Submitted files to virustotal to see if they were infected, all were clean
    • run "wscript -regserver" from an elevated cmd prompt, nothing displayed
    • ran antivirus scan, no infections found
    • disabled script scanning from antivirus
      •    Disabling antivirus and Windows Defender did not solve problem
    • uninstalled Powershell (via Programs and Features, Turn Windows features on or off), rebooted, installed Powershell 2.0 via WU
      •     According to Windows Features, Powershell is not selected (unchecked), Windows Powershell listed 2nd time is enabled (checked), and Windows PowerShell Intergrated Scripting Environment is also enabled (checked)
    • Verified file associations
      c:\Windows\System32>assoc .vbs
      .vbs=VBSFile
      C:\Windows\System32>ftype VBSFile
      VBSFile="%SystemRoot%\System32\WScript.exe" "%1" %*
    • I am not prepared to install IE 8 just to see if it will install a new script engine and fix this issue
    • Ran Processor Monitor v 2.94 while attempting to start a VBS file, results were too verbose and no hints found (traces saved for future reference)
    Friday, January 21, 2011 9:20 PM

Answers

  • Hi,

    I found a similar case by comparing the corresponding registry key:

    Non problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\system32\\vbscript.dll"
    "ThreadingModel"="Both"

    Problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\McAfee\\Managed VirusScan\\VScan\\ScriptSn.20100412064520.dll"
    "ThreadingModel"="Both"

    If you have enabled your security software, please also check this.

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, January 27, 2011 9:01 AM
    Moderator
  • Thanks Magon Liu, your suggestion to look at that registry key was the answer!  McAfee VirusScan Enterprise 8.7i Update 4 broke this setting.  Uninstalling VirusScan DID NOT change the key back to the default value.
     
    Incorrect / broken key:

    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\McAfee\\VirusScan Enterprise\\scriptcl.dll"
    "ThreadingModel"="Both"
     
    Fixed key, please note I had to change permission on key to Full Control for Administrators in order to write the change, then revert back to Allow read when done:

    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\System32\\vbscript.dll"
    "ThreadingModel"="Both"
     
    "Magon Liu" wrote in message news:9e0d77c3-58a2-4536-8489-085c68d9a709...

    Hi,

    I found a similar case by comparing the corresponding registry key:

    Non problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\system32\\vbscript.dll"
    "ThreadingModel"="Both"

    Problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\McAfee\\Managed VirusScan\\VScan\\ScriptSn.20100412064520.dll"
    "ThreadingModel"="Both"

    If you have enabled your security software, please also check this.

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, January 27, 2011 6:45 PM

All replies

  • run "wscript -regserver" from an elevated cmd prompt, nothing displayed


    I had to use DependencyWalker's Profiler to see that it even did something and then ran ProcMon to try to see what what it accomplished.   Not much IMO--a total of 6 RegSetValue events?

    I found a support article which advocated this and various instances of it being tried but where is the syntax explained?

    I suspect your ProcMon trace is going to be the best resource for figuring out the cause of your problem.   Just learn to use the filters and highlighting and it won't seem so overwhelming.   ; )

    However, I don't understand the relevance of IE for this incident.  E.g. I think you might find more informed help on a forum which specializes in scripting.   Also the mention of PowerShell makes me wonder about converting WSH scripts to PS.   <eg>


    Good luck

    Robert Aldwinckle
    ---

    Saturday, January 22, 2011 6:06 AM
  • Thanks for the suggestions, I posted in this forum rather than a scripting forum since WSH is supported by the IE team.  I had no luck so I upgraded to IE 8, problems still exist, including the problem of not being able to run VBScript within Internet Explorer.  I found the Dependency Walker program and ran it when attempting to run a VBS file, only lead which looks to be a dead end is the inability to find/load WSHEN.DLL or WSHENU.DLL.  The postings at http://forum.sysinternals.com/topic5696.html indicate these DLL's are not needed, however I now wonder if this could be a DLL preloading attack vulnerability or if perhaps my path has be modified and an older DLL is loading that doesn't work on Vista.  Could you suggest a list of the current Vista SP2 SHA-1 checksums for the DLL files I attempted to re-register so I can ensure they are all the correct files?
     
     
    "Robert Aldwinckle on forums" wrote in message news:338ed453-476d-4181-be37-30a84da9a54f...
    run "wscript -regserver" from an elevated cmd prompt, nothing displayed


    I had to use DependencyWalker's Profiler to see that it even did something and then ran ProcMon to try to see what what it accomplished.   Not much IMO--a total of 6 RegSetValue events?

    I found a support article which advocated this and various instances of it being tried but where is the syntax explained?

    I suspect your ProcMon trace is going to be the best resource for figuring out the cause of your problem.   Just learn to use the filters and highlighting and it won't seem so overwhelming.   ; )

    However, I don't understand the relevance of IE for this incident.  E.g. I think you might find more informed help on a forum which specializes in scripting.   Also the mention of PowerShell makes me wonder about converting WSH scripts to PS.   <eg>


    Good luck

    Robert Aldwinckle
    ---

    Monday, January 24, 2011 7:12 PM
  • I had no luck so I upgraded to IE 8, problems still exist, including the problem of not being able to run VBScript within Internet Explorer. 

    My guess is that this is yet another example of security/obscurity, so upgrading to IE8 would only make that possibility worse.    As I indicated ProcMon would be your best bet for untangling that kind of symptom.

    I found the Dependency Walker program and ran it when attempting to run a VBS file, only lead which looks to be a dead end is the inability to find/load WSHEN.DLL or WSHENU.DLL.


    Unless the missing modules are really causing a problem my guess would be that they are just undocumented stubs, similar to the ones that always caused IE6 users concern when they listed  IE File Versions  with XP's  msinfo32.exe  /category IEFileVersions  command.   ; )


    Good luck

    Robert
    ---

    Tuesday, January 25, 2011 6:07 PM
  • Hi,

    I found a similar case by comparing the corresponding registry key:

    Non problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\system32\\vbscript.dll"
    "ThreadingModel"="Both"

    Problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\McAfee\\Managed VirusScan\\VScan\\ScriptSn.20100412064520.dll"
    "ThreadingModel"="Both"

    If you have enabled your security software, please also check this.

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, January 27, 2011 9:01 AM
    Moderator
  • Thanks Magon Liu, your suggestion to look at that registry key was the answer!  McAfee VirusScan Enterprise 8.7i Update 4 broke this setting.  Uninstalling VirusScan DID NOT change the key back to the default value.
     
    Incorrect / broken key:

    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\McAfee\\VirusScan Enterprise\\scriptcl.dll"
    "ThreadingModel"="Both"
     
    Fixed key, please note I had to change permission on key to Full Control for Administrators in order to write the change, then revert back to Allow read when done:

    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\System32\\vbscript.dll"
    "ThreadingModel"="Both"
     
    "Magon Liu" wrote in message news:9e0d77c3-58a2-4536-8489-085c68d9a709...

    Hi,

    I found a similar case by comparing the corresponding registry key:

    Non problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\system32\\vbscript.dll"
    "ThreadingModel"="Both"

    Problem machine:
    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\McAfee\\Managed VirusScan\\VScan\\ScriptSn.20100412064520.dll"
    "ThreadingModel"="Both"

    If you have enabled your security software, please also check this.

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, January 27, 2011 6:45 PM
  • Thank you for your feedback. I am glad we figure it out!

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Friday, January 28, 2011 6:53 AM
    Moderator
  • I was having a similar problem running VB scripts in IE and your answer solved my problem also.  I have a desktop PC running Vista Home Premium 64-bit with IE 9 installed and a laptop running Vista Home Premium 32-bit with IE-9.  I have the MSN service included in my Verizon FIOS service and until recently had the McAfee security software that is provided free with MSN installed on both of these machines.  After I uninstalled McAfee on both of these machines, some interactive content on web pages no longer worked.  Using the Developer Tools (F12) in IE 9, I could see from error messages in the console window that VB scripts were not working properly on these pages.  The content of the problem registry key on my PCs was a little different from that described above as shown below:

    [HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Program Files\\Common Files\\McAfee\\SystemCore\\ScriptSn.20110517142553.dll"
    "ThreadingModel"="Both"

    After I edited the key to change the target to vbscript.dll as described above, the problems I had displaying interactive content on the PC running Vista Home Premium 32-bit were solved.  On the machine running Vista 64-bit, another key also had to be changed as follows: 

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\SysWow64\\vbscript.dll"
    "ThreadingModel"="Both"

    Thank you for identifying the solution.  The affected registry keys can be changed manually or by running the McAfee Removal Tool available at http://download.mcafee.com/products/licensed/cust_support_patches/MCPR.exe .

    • Edited by Man-o-Kati Wednesday, February 1, 2012 10:32 PM New information.
    Tuesday, January 31, 2012 10:35 PM
  • The registry entry was my answer also, thankyou for providing that.  Although note in my case I was using Windows 7 Home Premium 64 bit edition.  Thus the registry key I needed to update was the following:

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
    @="C:\\Windows\\SysWOW64\\vbscript.dll"
    "ThreadingModel"="Both"

    Wednesday, November 21, 2012 11:17 PM
  • Thank you so much for this solution, it finally worked for me after having searched for weeks...

    BR,

    Cece.

    Saturday, December 22, 2012 2:57 PM