Run *RunAs problem [SOLVED]

[SKAN]

Solved: UAC should be enabled while installing AutoHotkey. Refer lexikos' post

Can anybody tell me why the following snippet is erring out?

OS: Win7 x86. UAC enabled with default setting.
Installed AHK 32bit unicode 1.1.13.1 as "D:\AutoHotkey\AutoHotkey.exe"
Running the script by double clicking the file in windows explorer.

Code: Select all

if not A_IsAdmin
{
   Run *RunAs "%A_ScriptFullPath%"  ; Requires v1.0.92.01+
   ExitApp
}

MsgBox, IsAdmin: %A_IsAdmin%

[Wade Hatler]

I think it's because *RunAs verb doesn't handle file association right. This works:

Code: Select all

Run *RunAs "%A_AhkPath%" "%A_ScriptFullPath%"

[SKAN]

This works

That works for me.
But does the snippet I posted work for you? It has been copy/pasted from help doc!
I want to confirm whether installing AutoHotkey on non-default path is causing the problem for me.

Thank you.

[Wade Hatler]

Correct. The snipped didn't work for me.

P.S. This snippet assumes no command line parameters. If you want to re-run exactly what you're running, you'd have to generate the rest of the command line as well. I have a snipped to do that if you need it.

[SKAN]

Correct. The snipped didn't work for me.

Thanks! That helps. I do not have to re-install AutoHotkey!

This snippet assumes no command line parameters.

Which is exactly what I require.

My script needs to do the following:
1) Write to registry ( requires admin mode )
2) Restarts Explorer.exe ( which is best done in user mode - else explorer.exe will get unnecessarily elevated )

So, the script will be #SingleInstance and run 3 times like User > Admin > User > ExitApp.



Edit: Well, it cannot be #SingleInstance

[Wade Hatler]

There are a lot of ways to skin that cat. One way, which I assume you're proposing, is to have a single script that goes through and executes the bulk of the processing, and it uses the *RunAs verb to rerun itself with an elevated prompt when necessary. It's as good a way as any, and if you're doing it that way you would in fact not use #SingleInstance, and you would pass additional parameters during the restarted version. The logic would probably look something like this completely untested pseudocode:

Code: Select all

    WriteRegistry()
    RestartExplorer()
    ; Other Work
    ExitApp

WriteRegistry() {
    if (A_IsAdmin) {
        ; Write the Registry Keys Here
        if Instr(StrGet(DllCall("GetCommandLineW"), "UTF-16"), " -ELEVATED") 
            ExitApp
        else
            return
    }
    else if Instr(StrGet(DllCall("GetCommandLineW"), "UTF-16"), " -ELEVATED") 
        throw Exception("Can't acquire Admin Priveledges", -1)

    else 
        RunWait % "*RunAs " StrGet(DllCall("GetCommandLineW"), "UTF-16") " -ELEVATED"
}

RestartExplorer() {
}

The secret sauce here is that you are using DllCall to get the entire commandline (including AutoHotkey.exe), and passing it off using RunWait to re-execute it.

[SKAN]

Thanks for the code.

BTW, no need for StrGet. DllCall( "GetCommandLine", Str ) would be sufficient.
I just found out that once elevated, it is almost impossible to drop to user mode.

So, I am changing my strategy:
'User mode' only script, which
1) Writes a .reg file and calls RegEdit with command line switches
2) Restarts explorer.exe

[Wade Hatler]

You don't actually need to drop back to usermode. The second instance would be running with elevated privileges, and it exits as soon as it's done writing, and the first instance does the rest of the processing, so you'd be OK with the strategy above, but making a .REG file and loading that works just as well and it's probably easier anyway. That's the confusing part about writing those kind of scripts - the same script is doing 2 different things in different instances, and it's easy to get confused. I still do it because I like it better than having 2 different scripts most of the time though.

BTW, no need for StrGet. DllCall( "GetCommandLine", Str ) would be sufficient.

Good tip. I'll give it a try. I was having a bunch of trouble getting GetCommandLine to work consistently across ANSI and Unicode builds, because the strings it generates were giving me a bunch of problems (can't remember the details), so I kind of ended up with that one because it worked - but I never tried the form you showed so I'm going to try it.

[lexikos]

To answer SKAN's original question, it fails because the RunAs verb for .ahk files is not registered on his system. This is done by the installer, but only if you have UAC enabled when you install AutoHotkey; and obviously, only if you install AutoHotkey (1.1).

Code: Select all

FileTypeKey := "AutoHotkeyScript"
;...
RegWrite REG_SZ, HKCR, %FileTypeKey%\Shell\RunAs\Command,, "%A_WorkingDir%\AutoHotkey.exe" "`%1" `%*

I just found out that once elevated, it is almost impossible to drop to user mode.

It's fairly easy, actually. I suggest reading over my post about it or just getting ShellRun() from the AutoHotkey installer, which installs a copy of itself (installer.ahk) along with AutoHotkey. The installer uses it to launch AutoHotkey.

[SKAN]

You don't actually need to drop back to usermode. The second instance would be running with elevated privileges, and it exits as soon as it's done writing, and the first instance does the rest of the processing, so you'd be OK

Oops! I missed that. Thanks, I like the idea.

[SKAN]

To answer SKAN's original question, it fails because the RunAs verb for .ahk files is not registered on his system. This is done by the installer, but only if you have UAC enabled when you install AutoHotkey; and obviously, only if you install AutoHotkey (1.1).

Thanks for the clarification lexikos. I enable UAC only for testing purposes.
I ran the installer executable and selected repair. RunAs verb works now. Thanks again.

ShellRun() from the AutoHotkey installer, which installs a copy of itself (installer.ahk) along with AutoHotkey.

Thank you. I had never peeked in installer.ahk for almost 2 years.

[SKAN]

FYI,

*RunAs only works with file types which have the "RunAs" verb registered, which typically only includes executable files. AutoHotkey_L's installer registers "RunAs" for .ahk files, but only if it thinks UAC is enabled. If you haven't run the installer - or if you're on Windows XP or UAC was disabled when you ran the installer - you'll need to either register the RunAs verb yourself, or use Run *RunAs %A_AhkPath% Script.ahk.

On Windows XP it asks for a username and password, even if you are an administrator.

On Windows Vista and later it just runs the program without prompting if you are an administrator. (You must be careful not to unconditionally call Run *RunAs %A_ScriptFullPath%.)

[lexikos]

I had never peeked in installer.ahk for almost 2 years.

It's less than 2 years old. Before that, the installer was an NSIS script.

[derz00]

Hi, this thread is almost 4 years old, but I cannot get this to happen for me. I reinstalled AHK with UAC fully enabled, and still I get the error when running the code in the original post. Any help?