New readers please (just) read my second edit.

(Original title: "UAC: Cannot use the command window anymore with Autohotkey (Windows 10)", intermediate title: "UAC: Cannot run es.exe (Voidtools Everything) in the command window from Autohotkey anymore (Windows 10)")

In the past, I have used the command window with AHK; this is not possible anymore, without UAC interfering. Seems there have been "updates" with the most recent W10 (and/or AHK?) update(s).

Even very simply things are not possible anymore, the AHK help is not understandable ( https://www.autohotkey.com/docs/commands/Run.htm ).

I run the following AHK command, always from an administrator account:

runwait, %comspec% /c dir c:\ >>d:downloads\000.txt, , min

(This is identical to an example in the linked help file, except for the fact that in the example, they write the output to c:\, and I want to de-complicate things as much as possible.)

This just opens the command window but does not write any command to it, and thus, there is no output. (You can verify this by leaving the command window open, without the /c attribute: runwait, %comspec% dir c:\ >>d:downloads\000.txt, , min )

So, I have to write

runwait, *runas %comspec% /c dir c:\ >>d:downloads\000.txt, , min

This is as before, except for the *runas "key" as they call it. With this, there is "success", incl. the writing of the output, BUT this command first opens the UAC dialog, which asks, "Do you want to allow the app to make changes to your device?", the only "change" obviously being the writing of the output file; the same would occur if I just piped the output to the clipboard, or if I triggered another program which would just display its help within the command window.

It is obvious that for such things, nobody would want to have to interact with that UAC dialog, but would simply have done this automatically, in order for the output then to be further processed.

Thus, I tried by changing my security settings in the UAC (in the UAC dialog, there is "Show more details", and when you click that, you can read, "Change where these notifications appear", clicking on that then bringing up a slider) from 4/4 to 3/4, then 2/4, then 1/4, and in all these cases (which also would harm my web browsing security), the UAC dialog continued to interfere, so I reset it to 4/4, since that's obviously not the way to get rid of it in my use case (= sending harmless comspec commands from AHK to my system); I probably would have got rid of it if I did the setting to 0/4, which would have left me without any security to third-party attackers.

Thus, what can I do in order for the command window to accept and process my AHK commands, but without my system stopping the processing by displaying the UAC dialog?

(I could make manual changes to the registry if necessary.)


Thank you, harrymc. In fact, after several hours of trying, I hadn't seen this - new - error of mine at all (this line was correct first, then I got it wrong somehow); in my trial script, outcommented, I had previous tries for that with the correct syntax though, which did not work; now that one works indeed; I don't know why this is not persistent.

Also, this trial script is just some (working) lines (the other ones being out-commented), and this simple thing, now, even works from there, without the script being elevated.

Thank you, user3419297. As said above in my edit, for the simple task, this is not even needed, but this scriptlet works fine, I now have to answer the UAC dialog upon loading the AHK script, but can live with that.

Unfortunately, my real task does not work, even now, the command window remains empty, the command is not put into it, so is not processed there.

My real problem is Everything search, by command line, so one of these should work, but NONE of them do, in the amended, elevated script, variant 2 would be the correct syntax I think:

msgbox, variant 1: ; *
runwait, %comspec% "c:\Program Files\Everything\ES\es.exe -h"
; send, {enter}
msgbox, variant 2:
runwait, %comspec% "c:\Program Files\Everything\ES\es.exe" -h
; send, {enter}
msgbox, variant 3:
runwait, %comspec% "c:\Program Files\Everything\ES\es.exe" "-h"
; send, {enter}
msgbox, variant 4:
runwait, %comspec% ""c:\Program Files\Everything\ES\es.exe" -h"
; send, {enter}
msgbox, variant 5:
runwait, %comspec% ""c:\Program Files\Everything\ES\es.exe" "-h""
; send, {enter}

(* = BTW, variant 1 should bring an error message for the space in "Program Files", but since the command is not even written into the command window, even the mandatory error message will not appear.)

(The additional {enter}" commands are certainly not necessary, but with or without, the command text of the "runwait" (or "run") command is NOT written into the command window; all this, as said, sent from my now elevated main AHK script.)

It goes without saying that if I put the command "c:\Program Files\Everything\ES\es.exe" -h directly into a (non-elevated) command window (and then press Enter, of course), the Everything help is displayed in the command window.

Of course, the problem is now considerably complicated, since for checking out, you would have installed the Everything command line ("es.") exe, or possibly some other program.

Before saying it comes down to an Everything / es.exe problem ( https://www.voidtools.com/forum/viewtopic.php?t=1745 and https://www.voidtools.com/forum/viewtopic.php?t=7518 ) I would pretend that the command line should at least be written into the command window, with possible problems afterward, but as said, the command itself does not appear within the command window.

And, even from a non-elevated (extra) script, all this worked fine, incl. real searches, just days ago. (And I had no Everything update in-between, but possibly an AHK update (I did do that recently and may not have done es.exe searches afterwards indeed before today), and possible W10 updates anyway.)


It does NOT seem to be a UAC problem, it all works identically from my now elevated main AHK script, and from any other, seemingly non-elevated script.

It seems it is NOT possible currently to execute a persistent command window from AHK, hence the impossibility to run even "simple" commands in such a window from AHK, without the /c attribute, hence the impossibility to display even the es.exe help there. See:

runwait, %comspec% /c dir c:\ >>d:\downloads\000.txt, , min ; works fine, but

runwait, %comspec% dir c:\ >>d:\downloads\0000.txt, , min ; does NOT work

On the other hand, even the slightest syntax error in es.exe OR in AHK will leave the command window empty, but see:

; the data to be retrieved is always identical:
progvar := "c:\program files\everything\ES\es.exe"
attrvar := "c: parents:1 -export-txt d:\downloads\0both.txt"

; no var used here, works:
; runwait, %comspec% /c "c:\program files\everything\ES\es.exe" c: parents:1 -export-txt d:\downloads\0none.txt

; ditto with persistent command window, command is NOT written into command window, so NO output either:
; runwait, %comspec% "c:\program files\everything\ES\es.exe" c: parents:1 -export-txt d:\downloads\0nonebutpersistent.txt

; only progvar used here, works:
; runwait, %comspec% /c "%progvar%" c: parents:1 -export-txt d:\downloads\0progonly.txt

; both vars used here, works:
runwait, %comspec% /c "%progvar%" %attrvar%

; ditto with persistent command window, command window (persistent) remains empty again:
; runwait, %comspec% "%progvar%" %attrvar%


It's obvious the missing functionality of AHK commands in a persistent command window will regularly mislead users since it (here: falsely) appears as "natural" to try out new commands in a persistent, "viewable" command window first, with then only when they work there, having them processed within a non-persistent window, with the /c attribute: Who could guess this "natural" way of doing things was a fallacy with AHK?

THIRD EDIT: I can confirm that it's NOT a UAC problem, since for other reasons (additional tools didn't work anymore as expected with my AHK script elevated), I out-commented the additional script part again, and (after reboot) the indicated commands above continue to work.

(It goes without saying that putting the prog-calling part into a variable, whilst not doing so for the attributes part, wouldn't make sense, whilst the other way round would make sense; I put both parts into variables.)

For further processing, piping the output into the clipboard would be preferable, in most cases:

progvar := "c:\program files\everything\ES\es.exe"
attrvar := "c: parents:1 |clip"
runwait, %comspec% /c "%progvar%" %attrvar%


I think the problem is that the output file is badly specified.

Instead of d:downloads\000.txt you should have d:\downloads\000.txt.

Your formulation may fail if the current folder on D: is not the root.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.