AutoIt doesn't work anymore after Win10 Update

[Ginger]

We use AutoIt to start programs that require administrator rights. It has worked on both Windows 7 and Windows 10 so far. Unfortunately we have to update the Windows 10 computers regularly. And this is the problem: after such an update has taken place (Win 10 1909), the AutoIt script doesn't work anymore - nothing happens. The script is just a one-liner:

RunAs ("administrator", ".", "password", 1, '"program path"')

It will not work with the local or domain administrator after the update. The local administrator account is activated and we can start the corresponding program manually away from AutoIt - i.e. by entering the authentication.
We have reinstalled two of the affected computers with Windows 10 1909: then the script works again. So the Windows 10 update seems to do something to the administrators.
What might be interesting: even before the Windows 10 updates, only the administrator accounts that were also called "Administrator" worked, with other administrator accounts the same phenomenon appeared as now with the administrator accounts that are also called Administrator: nothing happened. 

[Danp2]

Hi Ginger,

Have you ruled out your AV software? That would be the first item I would check. Have you tried compiling to an A3X instead of an EXE?

Dan

P.S. I haven't used it, but you could also check out Au3toCmd

[Ginger]

Hi Dan,
thanks for your reply. Yes, we have also tried with AV (Sophos)  ruled out - but without success.
AX3 and Au3toCmd are new to us. We will have to see if this can help.

The strange thing is, it's always the same script. it works until we make an Win 10 Update (1909).
And if we reinstall 1909 at this machines, it works again 

[Subz]

What do you mean by it stops after Win 10 Update (1909) and re-install Win 10 1909 it works?  Are you saying upgrading to Win 10 1909 breaks AutoIt but installing Win 10 1909 from fresh it works?

Can you confirm that you're using #RequireAdmin at the top of your script?  I found that in the past with our Win 7 machines we had UAC switched off so we didn't require #RequireAdmin, but we decided with Win 10 to enable it, so we had to update our scripts with #RequireAdmin.

[Ginger]

42 minutes ago, Subz said:

What do you mean by it stops after Win 10 Update (1909) and re-install Win 10 1909 it works?  Are you saying upgrading to Win 10 1909 breaks AutoIt but installing Win 10 1909 from fresh it works?

Yes, exactly - same machine, same script.

43 minutes ago, Subz said:

Can you confirm that you're using #RequireAdmin at the top of your script?  I found that in the past with our Win 7 machines we had UAC switched off so we didn't require #RequireAdmin, but we decided with Win 10 to enable it, so we had to update our scripts with #RequireAdmin.

No, we haven't used that so far. But I'll test it.

[Ginger]

with #RequireAdmin it works even less: then the User Account Control appears even on computers with freshly installed Windows and asks for username and Password.

[Danp2]

But does the script now run on the "broken" workstation when using #RequireAdmin?

[Ginger]

15 hours ago, Danp2 said:

But does the script now run on the "broken" workstation when using #RequireAdmin?

No, even then the program in question is not started by the script.
To avoid misunderstandings: it is not the script that requires administrator rights, but this particular program that is to be started.

[argumentum]

add it to the task Scheduler OnDemand with highest rights. That should do it and safer than having the admin password somewhere, even if encrypted.  

[Ginger]

So, we were able to solve the problem in a roundabout way: as it turns out now, a Win10 update to 1909 is not a basic problem for our AutoIT script, but it definitely has to do with the program that is supposed to be started by the script. Other ("normal") programs can very well be started with the script on an updated computer.

The detour: The script no longer calls the program, but a batch file which then calls the program.

Thanks to you for dealing with our (obviously quite exotic) Problem!

 

1 hour ago, argumentum said:

add it to the task Scheduler OnDemand with highest rights. That should do it and safer than having the admin password somewhere, even if encrypted.  

Thanks, didn't know, that on demand is possible. We'll check it out.