AutoIT stopped working

[jcrist90]

On 6/22/2019 at 7:37 PM, mLipok said:

Save your script to C drive ... Add FileExist('D:\....au3') and give as the result.

I think you are using #RequireAdmin but the D drive is not mapped for admin..... 

 

Sorry fort long silence.  I created a test script as you suggested, here it is:

ConsoleWrite("FileExist = " & FileExists("D:\....au3") & @CRLF)

 

Here is the result:

>"C:\Program Files (x86)\AutoIt3\SciTE\..\autoit3.exe" /ErrorStdOut "C:\Users\<myusername>\Documents\AU3\test.au3"    
FileExist = 1
>Exit code: 0    Time: 0.1028

So the file is there and AutoIT sees the file properly, it just ignores any content in it

[water]

Could you please add #RequireAdmin and try again?

#RequireAdmin
ConsoleWrite("FileExist = " & FileExists("D:\....au3") & @CRLF)

 

[jcrist90]

If I add this then Windows dialog pops out asking  if I want to allow this script to make changes on my computer. After approval the program finishes but I don't see any information in the console, just "Exit code: 0"

[Jos]

22 minutes ago, jcrist90 said:

After approval the program finishes but I don't see any information in the console, just "Exit code: 0"

That's because the program is re-shelled with elevated rights thus not the same PID and not output will be shown by SciTE.
I have been able to fix this in the latest version of Autoit3Wrapper which comes with the separate installer SciTE4AutoIt3.

Jos

[water]

As a workaround you could replace ConsoleWrite with FileWriteLine and then check the created file.

[TheDcoder]

1 hour ago, Jos said:

I have been able to fix this in the latest version of Autoit3Wrapper which comes with the separate installer SciTE4AutoIt3.

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

Edited June 29, 2019 by TheDcoder

[Jos]

2 hours ago, TheDcoder said:

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

This is what it does: 

1. AutoIt3Wrapper checks whether the script needs to be elevated by checking for #RequireAdmin. 
2. When it does, it will check the current execution level with IsAdmin() and when at the same level it just shells the script and ends AutoIt3Wrapper.
   Else it will continue to the next step 3.
3. It will perform "Func RestartReqAdmin()" which:
   1. It creates a MailSLot for receiving the output of the Elevated process.
   2. It creates a TempFile which will be use as a trigger for monitoring the end of the Elevated script.
   3. It creates a Temp au3 script that has #RequireAdmin and simple shells the original commandline used to by F5, replacing "/run" by "/RunAdmin" and at the end will delete the trigger file. 
   4. It the Runs this created temp script and monitor's the MailBox for output till the trigger file is deleted.
4. The shelled process in the previous step will now still prompt for UAC, and be re-shelled, but AutoIt3Wrapper wait for the trigger file, so keeps on waiting for the output which is now send to the MailSLot in stead of the Console. See "Func __ConsoleWrite($s)" for details.

All clear? 
You can find the code in Autoit3Wrapper -> Func RestartReqAdmin()

Jos

ps: This works only one way as far as I remember, so only the elevated could send to the regular process's mailslot.

Edited June 29, 2019 by Jos

[argumentum]

1 hour ago, Jos said:

now send to the MailSLot in stead of the Console.

_WinAPI_ChangeWindowMessageFilterEx may be of use to keep a 2 way interaction ?.

[TheDcoder]

4 hours ago, Jos said:

All clear? 

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

[Jos]

24 minutes ago, TheDcoder said:

Maybe it is possible to improve the communication using named pipes, but I understand that this is going to be more complex.

I would say these mailslot UDF posted by @trancexx are pretty advanced ...no?: 

 

Here you find some documentation for it: https://docs.microsoft.com/en-us/windows/desktop/ipc/mailslots

Jos

Edited June 29, 2019 by Jos

[TheDcoder]

16 minutes ago, Jos said:

I would say these mailslot UDF posted by @trancexx are pretty advanced ...no?:  

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

Edited June 29, 2019 by TheDcoder

[argumentum]

5 hours ago, argumentum said:

_WinAPI_ChangeWindowMessageFilterEx may be of use

ok, that was not of much help.
@Jos, I updated the ForkUDF ( even tho I don't feel it was ready, but is functional ), to show in the example file "Example_Fork_Events.au3" what I mean by using _WinAPI_ChangeWindowMessageFilterEx().

[Jos]

I checked it briefly but believe that function is used for regular windows messages, not MailSLot.
Let's bring this topic back on track and take this discussion into another thread when it needs further discussion, but for me is the trigger file fine for the moment. 

Jos