3

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 the 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.

EDIT2: just a note for posterity - Since Octave 7, vbs scripts are no longer used to launch the program. A octave-launch.exe file is used instead. The .vbs and .bat launchers are still present, but VBS launch issues as described in this question are now less of an issue.

Nick J
  • 141
  • 1
  • 1
  • 13
  • 1
    Check his PATHEXT environment variable. Make sure .VBS is on the list. Mine looks like this `C:\Users\frodo_baggins>echo %PATHEXT%` ----- `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC` – Señor CMasMas Aug 22 '20 at 20:16
  • user checked and .VBS is there – Nick J Aug 23 '20 at 00:55
  • 1
    Not a solution, but why do you need VBS for something as simple as setting path and environment variables and starting a program? A simple batch script will do it and is guaranteed to work. If you would like to avoid a black CMD window see [this post](https://superuser.com/questions/62525/run-a-batch-file-in-a-completely-hidden-way). – harrymc Aug 25 '20 at 08:53
  • the project shifted from batch to vbs scripting a couple versions back. I don't personally recall the reason for the change but I think it was covered in https://savannah.gnu.org/bugs/?41074 . the blank cmd seemed to matter, but also bringing up a 'firsttime' welcome window. I'd have to dig/ask to see if the vbs is doing anything else that was a problem in the .bat. – Nick J Aug 25 '20 at 15:15
  • but yes, with the security history of vbs scripts on windows (or i guess internet explorer was the bigger culprit), it seems there has been a some issue with various hard to trace security restrictions on vbs files, in addition to user system config changes causing issues. – Nick J Aug 25 '20 at 15:39
  • 1
    Does the sample script run if you execute it like this from CMD Prompt or Run: `wscript.exe C:\test.vbs` (or) `cscript.exe C:\test.vbs` – w32sh Aug 25 '20 at 15:54
  • @harrymc it looks like the main solution on that page that doesn't involve a 3rd party executable still uses a vbs script. although something that converts the .bat into an hidable executable could have possibilities if it could be worked into the crossbuild process. – Nick J Aug 25 '20 at 16:13
  • 1
    It seems that VBS can cause problems, which is news to me. Would you be interested in a solution for hiding a bat file? – harrymc Aug 25 '20 at 16:56
  • @harrymc that would probably require input from the windows installer developers who had more detailed knowledge of why they went away from just trying to hide a .bat file. I have made an inquiry for those details. and will refer you to the conversation if it looks like it would be of use. – Nick J Aug 25 '20 at 17:43
  • @w32sh, directly calling the test script makes no difference, except the cscript call produces a MS copyright notice in the terminal. neither generate anything else visible. – Nick J Aug 25 '20 at 17:47
  • @harrymc , developer has expressed some interest in revisiting the idea of reverting back to a .bat file if it gets the job done. if you're interested, the mailing list thread is at: https://octave.1599824.n4.nabble.com/windows-installer-vbs-vs-bat-startup-script-tp4698025.html – Nick J Aug 26 '20 at 03:54
  • minor update - developer has put most of the startup script into a compiled C executable. Don't think it'll make it into version 6 as that's getting an alpha release right now, but at least sometime moving forward the issue of odd, hard to trace vbs security settings breaking octave startup scripts will be in the past – Nick J Aug 30 '20 at 20:27

4 Answers4

2

Diagnosis

Make sure that "%SystemRoot%\System32\WScript.exe" exists. You can check that with the file explorer (press WIN + E) - type the path %SystemRoot%\System32 into the file explorer's text box to view that directory, then look for WScript.exe there.

Open a command window (press WIN + R then enter cmd.exe) and type the following:

ftype | find /I "VBS"

That should give the result:

VBSFile="%SystemRoot%\System32\WScript.exe" "%1" %*

Then, check

assoc .vbs

which should show:

.vbs=VBSFile

Fix

If any of the above are not correctly set, then your VBS file will not run. To fix the file type (FTYPE) simply run the command

ftype VBSFile="%SystemRoot%\System32\WScript.exe" "%1" %*

To fix the association, run the command

assoc .vbs=VBSFile

If that is all correctly set and the issue still persists, it is likely that anti-malware software is blocking the execution - in that case, look into the answer w32sh gave.

Matt
  • 374
  • 3
  • 14
  • thanks. have verified wscript location previously. also file associations through windows dialogues, but will ask him to check the ftype and assoc through CLI to see if anything different pops up. – Nick J Aug 25 '20 at 15:20
  • verified that all three points are as they should be. wscript is present, ftype and assoc are as expected. – Nick J Aug 25 '20 at 16:09
1

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).

enter image description here

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.

w32sh
  • 11,524
  • 2
  • 39
  • 44
  • so, it turns out the user, while thinking that he only had windows defender running on his system, had multiple other AV apparently active. I'm not certain how that was possible, as in general windows should only allow a single AV to be active. Perhaps there was bundled software with the PC that had expired but was still present? Will update if the user provides any other clarification. Running the procmon with wscript call was the key here to finding out what was actually happening to prevent execution. 'Deleting' McAfee (as the user said. uninstall assumed) allows Octave to run – Nick J Aug 26 '20 at 03:45
  • 1
    It's likely that McAfee's IOfficeAntiVirus module registry keys are/were still active. In case of further issues of a similar kind, McAfee has a clean uninstaller tool that should do the trick. – w32sh Aug 26 '20 at 03:48
1

I don't know if this is going to help or not but I wanted to share my experience in resolving similar symptoms observed after upgrading my device to the following specs

  • Edition Windows 10 Pro
  • Version 2004
  • OS build 19041.450
  • Experience Windows Feature Experience Pack 120.2212.31.0

The device has only one VBScript which is supposed to be running at startup but stopped doing so straight after the upgrade. It's also worth mentioning that the script didn't exist when previous upgrades were installed so at this stage I can't say if the problem is specific to version 2004 or if this is an issue that pertains to W10 upgrades in general.

The issue observed is that instead of being executed at startup, Notepad++ was opening a page displaying the script content. I also noticed that the icon associated with the file holding the script had been changed to the Notepad++ icon after the upgrade.

So, I went to check the file association in the W10 UI (Start > Settings > Apps > Default apps > Choose default apps by file type), and here I could see that the .vbs extension was already assigned to "Microsoft Windows Based Script Host". I then changed the default app by manually selecting "Microsoft Windows Based Script Host" again and then suddenly the file started displaying the Microsoft-generated icon for .vbs items.

From there I was able to run the script manually and automatically at startup as well.

On a side a note, I have also seen my AV blocking some PowerShell commands (but not all) when called directly from with an Excel VBA module, but this has never impacted the execution of the aforementioned script though.

Guest1234-5678-9101112
  • 11
  • 2
0

You should check if there is not another antivirus that blocks your vbs file from running !

Hackoo
  • 1
  • 9
  • 22