Windows – VBS script execution blocked on Windows 10

octavescriptvbscriptwindowswindows 10

Posting this question on behalf of GNU Octave trying to troubleshoot execution problems. We've recently had a handful of Windows users install the software and be unable to run the program. Often they get no errors, messages, or useful feedback, they double click the startup icon and nothing happens.

In a recent case, we were able to work with the user to narrow the problem down to his system being unable to execute VBS scripts. Octave uses an octave.vbs file (called with wscript) to set path and environment variables and start the program.

Current diagnostic attempts:

The user created a simple test script on his desktop as per this example to just pop up a system dialog. He is unable to execute the script, and gets no popup or error message.
Had him move the file to different locations, like C:\temp, the same folder as Octave, etc., and the file would not execute.
Verified wscript's existence by having him run wscript from the run dialog, and the "Windows Script Host Settings" dialog popped up.
Right clicking he script file and checking Open With shows the default file association is with "Microsoft windows based script host" as it should be (and clicking that produces no script execution.)
Shift-right click and 'run as administrator' makes no difference.
Temporarily disabling Antivirus real time protection makes no difference.
Checked registry entries to make sure there is no Enabled=0 key as per this article (there is not).

Can anyone provide guidance on what Windows or other settings would prevent vbs scripts from running, and how we can correct this issue? Or what further things to check to identify the problem? Is there some new default security setting in Windows or coming with updates that would account for this?

User is running Windows 10 Home and the built-in Windows Defender and the latest updates. It's not a managed system. No special security settings were ever changed deliberately/knowingly by him. Version info below:

Windows specifications:
Edition: Windows 10 Home
Version: 2004
Installed on: 2020-01-10
OS build: 19041.421
Experience: Windows Feature Experience Pack 120.2212.31.0

For reference the original discussion thread with this problem can be found on the Octave discussion forum, but I think I've captured all relevant information above.

EDIT: Adding a note from a maintainer list discussion – for users that cannot run a vbs file for any reason, the octave.bat file is still present on the system, located in the mingw64/bin folder. A user can change the desktop shortcuts to point to that file instead of the octave.vbs file and octave should run without issue, although there might be some aesthetic changes with additional command prompt windows visible at times.

Best Answer

Based on the ProcMon log, it has been found that wscript.exe was loading 4 anti-virus software modules (3 Avast & 1 McAfee IOfficeAntiVirus module).

The McAfee IOfficeAntiVirus module is the most likely culprit which is blocking wscript.exe from executing scripts.

Completely uninstalling McAfee ought to fix the problem.

Set Last Loggedon - Win7.vbs

    '--------------
'Start of UAC workaround code

If WScript.Arguments.length =0 Then
  Set objShell = CreateObject("Shell.Application")

  objShell.ShellExecute "wscript.exe", Chr(34) & _
  WScript.ScriptFullName & Chr(34) & " uac", "", "runas", 1
Else

'--------------
'Start of code

    dim WSHShell
    Set WSHShell = Wscript.CreateObject("WScript.Shell")
    dim strRegKey
    strComputerName = wshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )
    strRegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\"

    StrUser = InputBox("Please enter in username," & vbCrLf & vbCrLf & "e.g. joe.local", "Set Last logged on", "UserName")
    StrDomain = InputBox("Please enter in domain for logon," & vbCrLf & vbCrLf & "e.g. DOMAIN", "Set Logon Domain OR leave blank if a local user account")

    If StrDomain = "" then
         StrDomain = "."
       Else
    End If

    wshShell.RegWrite strRegKey & "LastLoggedOnUser", StrDomain & "\" & StrUser, "REG_SZ"

        WScript.Echo "Setup Completed. Please restart the computer to complete the process"

    '--------------
    'End of code


    '--------------
    'End of UAC workaround code

    End If

Full Source: Windows 7 - VBS script to change last user logged on user

Windows – Force 64bit WScript to run .vbs

The following code will check if the system is 64Bit and in this case close the script and rerun it forcing the 64Bit Host by calling it directly with the script as parameter.

If fso.FileExists("C:\Windows\SysWOW64\wscript.exe") Then
    If InStr(1, WScript.FullName, "SysWOW64", vbTextCompare) <> 0 Then ' = very basic 64bit check replace if you want a more sophisticated one
        newFullName = Replace(WScript.FullName, "SysWOW64", "Sysnative", 1, -1, vbTextCompare) ' System32 will be replaced by Sysnative. calls to sysnative bypass WoW64 emulation, cscript or wscript stays the same as they were
        newArguments = "" ' all arguments are given to the new script call
        For Each arg In WScript.Arguments
            newArguments = newArguments & arg & " "
        Next
        wso.Run newFullName & " """ & WScript.ScriptFullName & """ " & newArguments, , False
        WScript.Quit ' Close 32Bit scripting host
    End If
End If

This workaround ensures that the script is run in 64Bit no matter who calls it. If you have a situation where you can control the call (e.g. the script is only ever called via a specific link) you can probably just use the basic principle (which is the sysnative file system redirector) directly in your shortcut.

Best Answer

Related Solutions

Windows 7 – VBS Script to change last logged on user

Set Last Loggedon - Win7.vbs

Windows – Force 64bit WScript to run .vbs

Related Question