View Single Post
Old 24th November 2015, 09:50   #5
Major Dude
LoRd_MuldeR's Avatar
Join Date: Sep 2005
Location: Somewhere over the Slaughterhouse
Posts: 797
Originally Posted by Anders View Post
ExecShell nor any kind of ExecShellWait is enough to reliably start a process elevated, this is bad advice.
Sure, ShellExecute(Ex) cannot "reliably" start an elevated process from a non-elevated one, because the user has to explicitly agree in the UAC dialog to launch the process. If the user doesn't agree (or the timeout hits), the process won't start. And, if the current user in not "admin", he even has to enter "admin" credentials into the UAC dialog in order to launch the process.

But: Using ShellExecute(Ex) it's at least possible to start a process that requires "elevation" from a non-elevated process (and if user declined, you can detect the issue and just retry) - whereas Exec or ExecWait just fail in that situation with error #740.

See also:

Originally Posted by Anders View Post
A) Vista, 7 (and 8?) with UAC turned off.
I think if UAC is turned off, then ShellExecute(Ex) just launches the "elevated" process without showing the UAC dialog. In this special situation Exec or ExecWait could do the job too, but they'd start failing as soon as UAC is actually not turned off on some computer. ShellExecute(Ex), on the other hand, works fine under both conditions, I believe.

Originally Posted by Anders View Post
2000, XP and 2003 with non-admin credentials used in the runas dialog.
Since these "legacy" systems didn't have UAC, they just ignore the "elevation" request from the Manifest.

If a "non-admin" user launches your installer on any of these systems (or an "admin" user uses run as to run your installer under a "non-admin" account), you have a problem anyway! The installer needs to detect this via UserInfo plug-in and abort...

My Plugins: StdUtils | NSISList | CPUFeatures | ExecTimeout | KillProc
My source of inspiration:
LoRd_MuldeR is offline   Reply With Quote