Run application elevated Topic is solved

[apoklyps3]

How to add elevation when opening and app (ex cmd.exe) inside a script
I'm not intereted in getting the whole script to run as administrator as that doesn't really assure me that the macros inside it will run the apps elevated.

I've gone to that route and it doesn't work:

here is my script

Code: Select all

full_command_line := DllCall("GetCommandLine", "str")

if not (A_IsAdmin or RegExMatch(full_command_line, " /restart(?!\S)"))
{
    try
    {
        if A_IsCompiled
            Run *RunAs "%A_ScriptFullPath%" /restart
        else
            Run *RunAs "%A_AhkPath%" /restart "%A_ScriptFullPath%"
    }
    ExitApp
}


Run, wbemtest
Sleep, 300
Send, {Enter}
SendRaw, root\securitycenter2
Send, {Enter}
Sleep, 300
Send, {i}
Sleep, 300
SendRaw, antivirusproduct
Send, {Enter}
Return

What should I change to get "wbemtest" to open as administrator .
Thanks in advance.

[Osprey]

Simply do:

Code: Select all

Run, *RunAs wbemtest

[apoklyps3]

I think it does the trick.
Can you help me further?
My script does the job, but only on fast computers and I'm trying to make it work on slow computers too via the Winwait function, but something must be wrong. it fails to send keystrokes...

Code: Select all

Run,  *RunAs wbemtest
WinWait, Windows Management Instrumentation Tester
Sleep, 333
Send, {Enter}
WinWait, Connect
Sleep, 333
SendRaw, root\securitycenter2
Send, {Enter}
WinWait, Windows Management Instrumentation Tester
Sleep, 333
Send, i
WinWait, Class Info
Sleep, 333
SendRaw, antivirusproduct
Send, {Enter}
Return

Any ideea what am I doing wrong?

[Osprey]

Failing to send keystrokes often comes down to send mode and key delay. Try adding the following to the top:

Code: Select all

SendMode, Event
SetKeyDelay, 10, 50

...and then changing your SendRaw command to Send.

[apoklyps3]

Seems the problem is "Run, *RunAs wbemtest".
If I remove the *RunAs part the script will work as intended, but ofcourse wbemtest won't get elevated privileges as I need it to.

[apoklyps3]

A bug maybe??

[qwerty12]

No. Everything is as expected. You create a new elevated process from an unelevated one and UIPI does what it's meant to do, blocking you from manipulating the window. If any process could, say, type stuff into a running elevated command prompt and run a dodgy program like that then UAC isn't much good. (And I'm an unimaginative person, I'm sure an actual Windows programmer knows of sleeker ways of doing the same for any arbitrary program.)

The AutoHotkey FAQ has a section on this topic.

I'm not intereted in getting the whole script to run as administrator as that doesn't really assure me that the macros inside it will run the apps elevated.

Believe me, it's harder to start something unelevated from an elevated process.
Just run your entire script elevated.

(Also, depending on what you're doing with wbemtest, you might find it easier to just use AutoHotkey to query WMI, instead of sending keystrokes. I don't know how to do it myself, but there's tons of examples around.)

[apoklyps3]

Ok. Makes sense.
my main issue with running the whole script elevated was that on some systems it takes multiple time to start elevated and it will open multiple wbemtest instances.
any ideea how I could bypass this?

[qwerty12]

Honestly, I have no clue how that would happen without seeing multiple elevation prompts. (And with the code you posted, when unelevated, ExitApp should always be called. At least that's what I saw when I clicked OK, Cancel at the elevation prompt, and also when I let it time out.)

You might consider setting #SingleInstance to force, wrapping your RunAs & Send etc. commands with a simple if (!WinExist("Windows Management Instrumentation Tester")) { or something.

[apoklyps3]

It usually happens when UAC is set to the highest security setting. The script will restart many times and somehow so does wbemtest.

[apoklyps3]

I'm on to another issue.
by default the script is generated for 64bit systems, so of course it won't run on 32bit machines.
if i generate it for 32bit wich should run on both types of arhitectures it gives me an error that it can't find wbemtest when I run it on x64 architecture (didn't have to ocasion to test it on 32bit also)

[ferryiol]

I'm on to another issue.
by default the script is generated for 64bit systems, so of course it won't run on 32bit machines.
if i generate it for 32bit wich should run on both types of arhitectures it gives me an error that it can't find wbemtest when I run it on x64 architecture (didn't have to ocasion to test it on 32bit also)

you might be blocked by the antivirus on the machine as the sequence you outlined thus far matches that of popular malware even though I am sure your intentions are pure and godly

[qwerty12]

it can't find wbemtest when I run it on x64 architecture (didn't have to ocasion to test it on 32bit also)

File System Redirector

Try something like

Code: Select all

if (A_Is64bitOS && A_PtrSize == 4)
	Run, %A_WinDir%\SysNative\wbemtest.exe
else
	Run, wbemtest

or

Code: Select all

if (A_Is64bitOS && A_PtrSize == 4) ; first condition is self- explanatory, the second tells you you are running a 32-bit script on a 64-bit system (64-bit pointers are 8 bytes)
	DllCall("Wow64DisableWow64FsRedirection", "Ptr*", oldRedirectionValue) ; disable redirection
Run, wbemtest
if (oldRedirectionValue) {
	DllCall("Wow64RevertWow64FsRedirection", "Ptr", oldRedirectionValue) ; re-enable it, something that must be done ASAP
	oldRedirectionValue : =0
}

if you need to actually disable the redirection for an amount of time rather than just overriding it when needed. I recommend the first approach.

[apoklyps3]

thanks but with the first i get : error failed attempt to launch program "Run, %A_WinDir%\SysNative\wbemtest.exe"

and with the second error : oldRedirectionValue : =0
this line does not contain a recognized action

the purpose of this script is to run on both x86 and x64 OS and to go directly to antivirus product enum so you can see if there are leftover entries from uninstalled security solutions.

[qwerty12]

My bad. The first should actually be Run, %A_WinDir%\SysNative\wbem\wbemtest.exe

With the second, that's just a typo on my part, try oldRedirectionValue := 0

(I'm still of the opinion that running wbemtest and automating it by keystrokes is weird when you can query WMI with AHK. Admittedly, I don't know how to do it myself, but I do know there's tons of examples around.)

[apoklyps3]

I think it works. no error anymore. many thanks.
Does winwait also work with multiple variables ? ex : Windows in french will have " Windows Management Instrumentation Tester" window called differently so I wouldn't want the script to freze on other languages.
Many thanks

I would have gone with WMI query but unfortunately that only displays the infromation without the possibility to alter stuff.

[qwerty12]

Does winwait also work with multiple variables ? ex : Windows in french will have " Windows Management Instrumentation Tester" window called differently so I wouldn't want the script to freze on other languages.
Many thanks

I think you might be able to use a window group, but I'm not sure.

Code: Select all

Run, %A_WinDir%\SysNative\wbem\wbemtest.exe,,, wbempid ; fix the path as necessary 
WinWait ahk_class #32770 ahk_pid %wbempid%

might also work for you. (The downside being that #32770 is the generic class for dialog boxes, so if wbemtest showed an error message, WinWait would probably flock to that.

I would have gone with WMI query but unfortunately that only displays the infromation without the possibility to alter stuff.

Fair enough. Performing WMI queries that change settings is surely possible in AHK, but I know even less about the GUI commands needed to make such an interface suited for altering things than I do the WMI queries themselves.

[apoklyps3]

Many thanks and happy new year !
You helped alot. Basicaly made the whole script work as I wanted, but unfortunately I hit another brick wall. And it's the one you mentioned so many times. The send key part.
Unfortunately different language windows has a different key shortcut for the tasks i want.
I wonder if I can make so it will hit the correct button from wbemtest interface, no matter the language I am on

[apoklyps3]

found that I can work around that with "ControlClick" , but it seems it doesn't work everytime. It doesn't click the button every time I run the script.

LE: it seems it malfunctions, when the mouse is on top of the wbemtest window.