TheDcoder

Indeed, I agree. The reason why I said named pipes can improve is because as far as I understand, they are more suited for 1-to-1 communication and have fewer limitations than mail slots... not to mention that AutoIt's standard UDF library has functions for named pipes

Yes, thanks for the overview... quite an intricate approach Maybe it is possible to improve the communication using named pipes, but I understand that this is going to be more complex. Doesn't matter really as long as it gets the job done

Just curious about how this is implemented, how is the output relayed from the privileged process back to SciTE?

The latest version of Windows 10 I presume, I update it regulary. I also just updated my host operating system, I have VirtualBox v6.0.8 r130520. I did another quick test now... still doesn't work

Fedora 30 with VirtualBox from the official Oracle repository

Thanks for mentioning my topic @Jos I assume you are running the scripts from one of the network drives? Please test if you could run a script if it is in the system (usually C) drive... the desktop is a handy location to test I am able to replicate the issue on my computer, and I volunteer for any testing efforts... maybe we can use a debug version of AutoIt to output some useful information to see what is happening behind the scenes with reading the script?

AutoIt scripts by default are portable and don't leave many traces behind on the computer when ran. Only you can make your program/script not portable by integrating it with other (from the script's perspective) 3rd party applications or leaving data outside your script's directory.

Wish I knew about this when I was using Windows... I am sure some will find this very useful My story is about the same, but it was a long game installation instead of copying. I had to wipe the existing install (because I was away and not sure if it was installed properly) and do it again, fun times.

Ah, true, I didn't think of this aspect... I guess this is one of the anti-features of AutoIt 😕 Oh well, atleast it is free to use

Give them the source code, let them perform a security audit manually. There isn't anything more that can be done unfortunatley...

What kind of code analysis test? There is no way to convert automatically your AutoIt code to a C variant, and definitely not code which could be human readable. Your options are to either convince them to perform a manual code analysis on your script or rewrite the whole thing in C/C++

Sounds good... that way we can exploit take advantage of all those cheap web hosting services and make a big interconnected cloud using their SQL servers and run our code on it

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

@argumentum Thanks for putting in the research effort 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. 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. I am sure that the permissions from the Linux side are solid, and I have not changed any permissions when this issue started happening. 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. 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.

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.

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. Hmmm... I am confused, I thought you wanted to check if there were multiple processes spawning when I invoke the script (via AutoIt3.exe)

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

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

I agree, I have had this established in my mind before I started this topic. 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 see I have already done so several times, I have included the output from cmd a few posts back: Many times, I have also posted the output from my testing session in cmd: As you can see, AutoIt is not setting an error either 😕

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). Correct, the mapped drive is a native Windows shared drive as far as I can see... 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

I think this is where your problem lies, are you running AutoIt3.exe with the path of your .au3 file as a parameter in the scheduled task? Okay... I just had a dumb moment and didn't see your command in the first post.

@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 🤔 Luckily yes

@Jos The stripper doesn't seem to have worked, I added the wrapper directive at the top of the script and here is 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 +>18:31:32 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 >Running AU3Check (3.3.14.5) from:C:\Program Files (x86)\AutoIt3 input:W:\Test.au3 +>18:31:32 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 +>18:31:33 AutoIt3.exe ended.rc:0 +>18:31:33 AutoIt3Wrapper Finished. >Exit code: 0 Time: 4.238 Yes, indeed. I was wondering the same... Many times, I have also posted the output from my testing session in cmd: As you can see, AutoIt is not setting an error either 😕

@Jos I am not sure how to do that... and I don't think it is an issue of the file being read as empty (as other tools like SciTE are able to read it just file), the issue seems to be only related to the AutoIt interperter 😟