AutoIt won't run scripts inside shared drive (VirtualBox shared folder)

[TheDcoder]

@Jos The plot thickens, I added this code in Line 2978 (included):

Local $aFile_tot = FileRead($hFile)
ConsoleWrite("Script Contents: " & @CRLF)
ConsoleWrite($aFile_tot & @CRLF)

and the output:

>"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "W:\Test.au3" /UserParams    
+>20:31:22 Starting AutoIt3Wrapper v.19.102.1901.0 SciTE v.4.1.2.0   Keyboard:00004009  OS:WIN_10/  CPU:X64 OS:X64  Environment(Language:0409)  CodePage:0  utf8.auto.check:4
+>         SciTEDir => C:\Program Files (x86)\AutoIt3\SciTE   UserDir => C:\Users\John Doe\AppData\Local\AutoIt v3\SciTE\AutoIt3Wrapper   SCITE_USERHOME => C:\Users\John Doe\AppData\Local\AutoIt v3\SciTE 
Script Contents: 
#AutoIt3Wrapper_Run_Au3Stripper=y
#include <MsgBoxConstants.au3>

If MsgBox($MB_YESNO, "Test", "Is it working?") = $IDYES Then
    ConsoleWrite("It is working!")
Else
    ConsoleWrite("It does not work...")
EndIf

ConsoleWrite(@CRLF)

>Running AU3Check (3.3.14.5)  from:C:\Program Files (x86)\AutoIt3  input:W:\Test.au3
+>20:31:22 AU3Check ended.rc:0
>Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3.exe "W:\Test.au3"    
+>Setting Hotkeys...--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
+>20:31:22 AutoIt3.exe ended.rc:0
+>20:31:22 AutoIt3Wrapper Finished.
>Exit code: 0    Time: 1.001

Au3Wrapper is able to read the file... but for some reason the stripper doesn't run 🤔

 

1 hour ago, Jos said:

 ( I assume you know how to do that ...right?)

Luckily yes

[Jos]

Understand why au3stripper isn't running as that only happens ofcourse when you compile the script. Sorry about that. 

So we now know we can read the script fine. Is there anyway you can monitor the creation of the PID's when you run the script?
Wondering whether it only creates only or multiple.

Just to be sure I understand it correctly: the c drive is in the virtualbox and the script is used from a mapped drive...right?

Jos

Edited May 27, 2019 by Jos

[TheDcoder]

17 minutes ago, Jos said:

Is there anyway you can monitor the creation of the PID's when you run the script?
Wondering whether it only creates only or multiple. 

I should be able to do that via Process Hacker or one of the Sysinternals tools, not an easy thing to do though as it requires some fiddling around and good timing.

However I am not sure which part of the execution process you are curious about... if ran from SciTE it should create 2 processes, one for Au3Wrapper (which works fine) and another one for my script (which exits without any information).

16 minutes ago, Jos said:

Just to be sure I understand it correctly: the c drive is in the virtualbox and the script is used from a mapped drive...right?

Correct, the mapped drive is a native Windows shared drive as far as I can see...

19 minutes ago, Jos said:

Understand why au3stripper isn't running as that only happens ofcourse when you compile the script. Sorry about that. 

Well I was thinking the same thing, but I almost never use Au3Wrapper so I left it up to the ones who would know about it

[Jos]

5 hours ago, TheDcoder said:

However I am not sure which part of the execution process you are curious about... if ran from SciTE it should create 2 processes, one for Au3Wrapper (which works fine) and another one for my script (which exits without any information).

Correct, so AutoIt3Wrapper itself is an AutoIt3 process and it will shell 2 processes when performing a Run command:

1. the autoit3 process to run the script.
2. an monitor process which monitors the shelled script.

I am interested whether the shelled AutoIt3 process for your script creates another process and ends the original process. This is also what happens when you get a UAC after which the whole process is reshelled elevated.
Maybe it is easier when you simply run your script with autoit3.exe yourself from the commandprompt for this test?

Jos

 

[TheDcoder]

@Jos I see

7 hours ago, Jos said:

Maybe it is easier when you simply run your script with autoit3.exe yourself from the commandprompt for this test?

I have already done so several times, I have included the output from cmd a few posts back:

15 hours ago, TheDcoder said:

16 hours ago, Jos said:

Have you also tried only using the AutoIt3.exe program to run the script without using SciTE & AutoIt3Wrapper ?

Many times, I have also posted the output from my testing session in cmd:

On 5/26/2019 at 11:23 PM, TheDcoder said:

 

C:\Program Files (x86)\AutoIt3>AutoIt3 "\\VBOXSVR\Win10JailBox\Test.au3"

C:\Program Files (x86)\AutoIt3>echo %ERRORLEVEL%
0

C:\Program Files (x86)\AutoIt3>AutoIt3 W:\Test.au3

C:\Program Files (x86)\AutoIt3>echo %ERRORLEVEL%
0

As you can see, AutoIt is not setting an error either 😕

 

[spudw2k]

1 hour ago, TheDcoder said:

8 hours ago, Jos said:

Maybe it is easier when you simply run your script with autoit3.exe yourself from the commandprompt for this test?

I have already done so several times, I have included the output from cmd a few posts back:

This really smells like it's not an SciTE issue then.  I know I'm beating a dead horse a bit here (as I also asked about this once), but does running the AutoIt3.exe from explorer not work either, or does it seem to be isolated to running it from the CMD prompt?

[TheDcoder]

34 minutes ago, spudw2k said:

This really smells like it's not an SciTE issue then.

I agree, I have had this established in my mind before I started this topic.

34 minutes ago, spudw2k said:

I know I'm beating a dead horse a bit here (as I also asked about this once), but does running the AutoIt3.exe from explorer not work either, or does it seem to be isolated to running it from the CMD prompt?

No worries, more clarification is always better. This issue is not isolated to cmd, running AutoIt3.exe from anywhere is producing the same result (i.e it doesn't work from anywhere when the script is inside a shared drive)

I have so far tried running AutoIt3.exe from SciTE, Explorer and Command Prompt. I was not able to observe any changes in behaviour

[Jos]

I had seen that but did you monitor the processes and was one one process created or could it be multiple are created?

Jos

[TheDcoder]

@Jos I can test it if you want, do you want me to test directly with AutoIt3.exe?

[BrewManNH]

Have you tried the command line using "Start /wait" ?

[TheDcoder]

@BrewManNH Good suggestion, I will try it tomorrow and report back

[Jos]

8 hours ago, TheDcoder said:

@Jos I can test it if you want, do you want me to test directly with AutoIt3.exe?

Yes, though that was already answered....   

[TheDcoder]

5 hours ago, BrewManNH said:

Have you tried the command line using "Start /wait" ?

C:\Program Files (x86)\AutoIt3>start /wait AutoIt3.exe "W:\Test.au3"

C:\Program Files (x86)\AutoIt3>echo %ERRORLEVEL%
0

It exited immediatley... so this indeed confirms that AutoIt3 is, for some reason, unable/is not willing to execute the script.

1 hour ago, Jos said:

Yes, though that was already answered....   

Hmmm... I am confused, I thought you wanted to check if there were multiple processes spawning when I invoke the script (via AutoIt3.exe)

[TheDcoder]

Bump, I would like to get this issue solved... it is very strange considering that this started happening randomly one day, I have been using this method for many months to execute my scripts.

[argumentum]

On 5/26/2019 at 2:58 PM, argumentum said:

...there is access and permissions.

..there is UTF-8 with and w/o boom. Look at that ?

There is also https://www.virtualbox.org/wiki/Sharing_files_on_OSE , maybe ?

in https://docs.oracle.com/cd/E97728_01/E97727/html/vboxmanage-sharedfolder.html they say:
By default, shared folders have read/write access to the files on the host path. On Linux distributions, shared folders are mounted with 770 file permissions with root user and vboxsf as the group. Using this option the file permissions change to 700. Optional.

PS: Unable to replicate the failure, troubleshooting is kind of impossible  =/   

PS2: if you could make a vm with your setup, anyone could t/s it.
( Make a VirtualBox with the host OS that has the WinOS inside as a VirtualBox, just as your setup. Make sure it fails just as it does in your setup. ZIP/RAR/what not, the vm and upload it somewhere)
We can t/s it that way. At least I will.

Edited June 1, 2019 by argumentum

[TheDcoder]

@argumentum Thanks for putting in the research effort

41 minutes ago, argumentum said:

..there is UTF-8 with and w/o boom. Look at that ?

I have just checked the encoding of my scripts, it is UTF-8... which is pretty universal, I know instances where the BOM (byte ordering mark) has caused issues, but I don't have it in my files.

43 minutes ago, argumentum said:

There is also https://www.virtualbox.org/wiki/Sharing_files_on_OSE , maybe ?

That wikipage is pretty confusing as it states that the open source edition of the VirtualBox doesn't have the shared folder feature... but it does? Maybe it is just an old page which is not up to date.

44 minutes ago, argumentum said:

in https://docs.oracle.com/cd/E97728_01/E97727/html/vboxmanage-sharedfolder.html they say:
By default, shared folders have read/write access to the files on the host path. On Linux distributions, shared folders are mounted with 770 file permissions with root user and vboxsf as the group. Using this option the file permissions change to 700. Optional.

I am sure that the permissions from the Linux side are solid, and I have not changed any permissions when this issue started happening.

44 minutes ago, argumentum said:

PS: Unable to replicate the failure, troubleshooting is kind of impossible  =/    

This is probably isolated to my installation of Windows... maybe it has something to do with one of the updates that I received? No idea.

45 minutes ago, argumentum said:

PS2: if you could make a vm with your setup, anyone could t/s it.
( Make a VirtualBox with the host OS that has the WinOS inside as a VirtualBox, just as your setup. Make sure it fails just as it does in your setup. ZIP/RAR/what not, the vm and upload it somewhere)
We can t/s it that way. At least I will.

I could try making a clean VM to reproduce the issue, but I cannot share it due to Windows licensing limits... and the issue is pretty strange anyway, it may not occur with a fresh installation.

[argumentum]

31 minutes ago, TheDcoder said:

but I cannot share it due to Windows licensing limits

You can, as far as I can think, distribute it w/o a licence, as it will work for some time. They have distros for browser testing ( ..did at https://www.microsoft.com/en-us/software-download/techbench but is not found now ) that did not need a licence as it was for testing.

( that is how I tested https://www.autoitscript.com/forum/topic/149137-sign-your-exe-with-a-digital-signature-signtoolexe/?do=findComment&comment=1316928 to make sure it'd work everywhere ) 

31 minutes ago, TheDcoder said:

the issue is pretty strange anyway, it may not occur with a fresh installation

Then make a new vm and see if you can compare both to find the difference that creates the issue. 

Edited June 1, 2019 by argumentum

[TheDcoder]

9 hours ago, argumentum said:

You can, as far as I can think, distribute it w/o a licence, as it will work for some time. They have distros for browser testing ( ..did at https://www.microsoft.com/en-us/software-download/techbench but is not found now ) that did not need a licence as it was for testing.

I did spot the browser testing VMs they had up for download just a few days ago... I might try them if things get desperate enough.

9 hours ago, argumentum said:

Then make a new vm and see if you can compare both to find the difference that creates the issue. 

Easier said than done... imagine what nightmare it would be to compare two different Windows installations to find meaningful differences

---

I would love if an AutoIt developer could shed some light on the situation... if I knew what API calls was AutoIt making to read the script, I can try recreating that myself and figure out the cause that way. Maybe I can even receive a special testing version with some debugging statements to the console to see what AutoIt is really up to?

[Joboy2k]

I know this is an older thread but this exact issue started happening to me today, I tested everything I could thats been mentioned in this thread and all the exact same results.

I started to notice that some of my scripts were working. The only thing I noticed the working scripts had were that they were large (70-80k lines).

So I did some testings with a simple script of just "Msgbox(0,0,0)" (which didn't work) and kept adding 500 lines of "Msgbox(0,0,0)" all the way to 4500 lines worth (which now works as expected). Now time to work backwards until I found the exact line that made it work which ended up being 4371 lines (this worked but 4370 didn't)

Then I tested further, I deleted line 4371 (which again stopped it working) and then changed the last line (4370) to "Msgbox(0,0,00)" (just added 1 extra character) and again the program started working which  made me realise it was the total lines it was the total characters in the entire script. 

I checked the size of the file and it was EXACTLY 64KB, I went back into the file and changed the last line again back to "Msgbox(0,0,0)" which made made the file 63.9KB and stopped the program working.

 

I checked through and tested with all my scripts, every single one under 64KB didnt work and every single one 64kb and up worked perfectly.

I'm not smart enough to understand why this stops the scripts working but its to much of coincedence that every script 64 and above works so it must have something to do with it. if anyone could shed some light on this situation with this new bit of info it would be great.

Im running windows 10 pro on a VirtualBox 64bit on the latest Scite/Autoit/Windows updates and all extension pack and guest additions for VirtualBox.

Hope this helps someone get to the bottom of the issue.

[TheDcoder]

@joboy2k Interesting findings, thanks for testing and tracking down this issue more, I will try to reproduce the outcome with latest VirtualBox.