Run child process non-elevated from an elevated/As

Question

My application has a built-in self update system via another app called "updater.exe" which is in the same folder with the main application to update. It downloads the newest version, terminates the old one (if it's running) and then overwrites it.

The problem is, to do that the updater.exe must be run with the Administrator privileges in order to have access to C:\Program Files\MyApp

So far so good, the main app runs the updater.exe with Admin privileges (using UAC) but then the problem appears:

After update is completed, I want the new installed version to start automatically. Guess what? Of course the main app runs with the Admin privileges also. The scenerio is simple:

Main app[running as user] --> Updater App[run as admin] --> Main app[ADMIN again]

Just because my application uses My.Settings object, it loses all the stored settings when it run as admin because typically it always start as normal user and as you may know, My.Settings is user-sensivite object.

How can I fix such an issue? I've searched around but could not find anything related to "Run as normal user" but always running as admin, which is quite easy.

Well, honestly, in the other hand, I don't think such a thing could be possible because the updater app cannot know which specific user has started it. Or can it? Is there something I'm missing here ?

If I am right, it is the only option to NOT to use My.Settings but the Windows Registry to store user preferences?

Thanks by now.

Answer 1

One way to "de-elevate" a child process is to start it via Explorer. This should generally work with normal Win users. But if Explorer itself is running elevated, then so will the app you are trying to start. Explorer may be running elevated because:

• The active user is Admin (not just a user with admin privs)
• Explorer.exe was (re)started from a command window which...you got it, is running elevated

... and probably others.

Its better to think of this as starting the app with default rights. If running elevated Explorer will start the new instance elevated, but original first Main App instance would also have run elevated.

Test code to start the same app using a checkbox to select elevated or not:

Dim proc = New Process
proc.StartInfo.UseShellExecute = True
proc.StartInfo.WindowStyle = ProcessWindowStyle.Normal
proc.StartInfo.WorkingDirectory = mypath

If chkAdmin.Checked Then                    ' run this app as admin
    proc.StartInfo.FileName = myApp
    proc.StartInfo.WorkingDirectory = mypath
    proc.StartInfo.Verb = "runas"           ' run "me" as admin
    proc.StartInfo.Arguments = ""
Else                                        ' run explorer w/app as arg
    ' de-elevate new app instance to run de-elevated
    proc.StartInfo.FileName = Path.Combine(windir, "explorer.exe")  
    proc.StartInfo.Verb = ""                ' important!
    proc.StartInfo.Arguments = myApp        ' send the child app name as arg
End If

proc.Start()

This image shows the result:

The label at the top of the form indicates whether that app is running elevated, each app instance was started by the one before it.

The second window down is running elevated. When it started the next instance, the check box for As Admin wasn't checked; as a result the 3rd instance was started via Explorer and is not running elevated. Same for #4 starting #5.