Run Elevated Process

Run elevated process

You need to set UseShellExecute to true for the Verb to be respected and it must be set to 'false' to redirect standard output. You can't do both.

I'm pretty sure Windows also won't allow you to redirect standard input/output/error across the admin/non-admin security boundary. You'll have to find a different way to get output from the program running as admin.

I didn't read this article, but this may give you more information: http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx

Start a process with elevated privilege

Please see Elevating process privilege programatically.

You either need to throw a UAC Elevation prompt (potentially annoying) or run your root forking process as administrator. By declaring it in the ClickOnce or program manifests, you can ensure that simple double-clicks on your executable will automatically prompt to elevate.

If the end user's machine has UAC enabled, at some point some kind of prompt will appear, as there is no legitimate way of elevating a child process from an unprivileged one.

Elevating process privilege programmatically?

You can indicate the new process should be started with elevated permissions by setting the Verb property of your startInfo object to 'runas', as follows:

startInfo.Verb = "runas";

This will cause Windows to behave as if the process has been started from Explorer with the "Run as Administrator" menu command.

This does mean the UAC prompt will come up and will need to be acknowledged by the user: if this is undesirable (for example because it would happen in the middle of a lengthy process), you'll need to run your entire host process with elevated permissions by Create and Embed an Application Manifest (UAC) to require the 'highestAvailable' execution level: this will cause the UAC prompt to appear as soon as your app is started, and cause all child processes to run with elevated permissions without additional prompting.

Edit: I see you just edited your question to state that "runas" didn't work for you. That's really strange, as it should (and does for me in several production apps). Requiring the parent process to run with elevated rights by embedding the manifest should definitely work, though.

Starting another process with elevation using different user credentials

i was surprised there's no way to do this, until i found an on blog entry by Chris Jackson:

Why Can’t I Elevate My Application to Run As Administrator While Using CreateProcessWithLogonW?

You need a bootstrapper. Some process which will let you do the transition to the alternate user, which could be responsible for running the requireAdministrator application. So, you could design something like this:

Why don’t we just create the ShellExecuteWithLogonW API? I’ll never say never, and we might at some point. But today, the use cases for this APIs have been use cases where there has been an alternate design which is superior.

The most common request is for people writing home-grown software deployment software, where they’d like to encode credentials right into the app and elevate their own process. The real problem here is not the lack of the API, it’s that you have admin credentials encoded in your app for the world to read.

So the solution requires ShellExecute, it's the only one that knows how to trigger a Consent dialog.

It brings up a good point: What are you doing with a person's password already?

Bonus Chatter

There's no UAC on Server Core because there's no windows to show a consent prompt.

PowerShell command to check whether an application is running with elevated privileges

You can use my Test-ProcessElevated cmdlet (It is too long, I've posted to GitHub gist).

For example:

# from pipeline:
Get-Process notepad | Test-ProcessElevated

# from parameter:
Test-ProcessElevated $(Get-Process notepad)

# it returns boolean
if (ps notepad | Test-ProcessElevated)
{
    Write-Host 'notepad is running elevated.'
}

# dwm.exe is running in a different session:
ps dwm | Test-ProcessElevated

I've tested it in both Windows PowerShell 5 and PowerShell 7.

---

Related Topics