Start-Process -WorkingDirectory 作为管理员未设置位置

Question

When I enter the command

Start-Process powershell -WorkingDirectory "D:\folder"

it opens new PowerShell window with D:\\folder location set.

But when I enter the command

Start-Process powershell -WorkingDirectory "D:\folder" -Verb RunAs

it opens new PowerShell window with admin rights but with C:\\Windows\\system32 location set.

How can I open new PowerShell window with admin rights and my own location determined?

Answer 1

I also had the same problem and solved it with this command:

Start-Process powershell.exe -verb runAs -ArgumentList '-NoExit', '-Command', 'cd D:\folder'

Once you run the above command, Windows will launch with admin authority and the specified directory.

Answer 2

Here's another example which can be used for opening CMD from PowerShell as an administrator into the current folder:

Start-Process cmd -ArgumentList ("/k cd {0}" -f (Get-Location).path) -Verb RunAs
if used within a script you can use
Start-Process cmd -ArgumentList ("/k cd {0}" -f $PSScriptRoot) -Verb RunAs

If you want to open a new elevated PowerShell session from the current one which is not elevated you can use:
Start-Process powershell.exe -ArgumentList ("-NoExit",("cd {0}" -f (Get-Location).path)) -Verb RunAs
or
Start-Process powershell.exe -ArgumentList ("-NoExit",("cd {0}" -f (Get-Location).path)) -Verb RunAs
when used inside scripts

Answer 3

Once you run Powershell as administrator;

user the push-location command like so:

Push-Location -Path C:\

or put it into your script and run the script from the elevated Powershell prompt.

Answer 4

When using Start-Process with -Verb RunAs , a -WorkingDirectory argument is honored if the target executable is a .NET executable ; examples:

• pwsh.exe (the PowerShell (Core) CLI) does honor it.
• cmd.exe and, curiously, powershell.exe (the Windows PowerShell CLI) do not , and invariably use C:\\Windows\\System32 .
  • The problem exists at the level of the .NET API that PowerShell uses behind the scenes (see System.Diagnostics.ProcessStartInfo ), as of this writing (.NET 6.0.0-preview.4.21253.7).

Unless you know that you're invoking a .NET executable, a workaround that changes to the desired working folder in the new process is therefore required; to offer a more robust alternative toふゆな's helpful answer :

$dir = $PWD.ProviderPath # use the current dir.

Start-Process -Verb RunAs powershell.exe @"
-noexit -c Set-Location -LiteralPath "$dir"
"@

• The embedded "..." quoting around $dir ensures that paths with spaces are also handled correctly. (To use the current directory without an intermediate variable, replace "dir" with "$($PWD.ProviderPath)" .

  • Using a here-string ( @"<newline>...<newline>"@ ) isn't strictly necessary, but simplifies the embedded quoting; with a regular expandable string ( "..." ), the embedded " must be escaped as `" (or "" ).

• Using $PWD 's .ProviderPath property ensures that a file-system- native path is used (based on drive letters also seen in cmd.exe , for instance), given that the calling session's current location may be based on a PowerShell-only drive (see New-PSDrive ) that the elevated process may not have defined (at all or not based on the same root location).

  • Caveat : If the native path is on a mapped network drive , this won't work, because elevated processes do not see the same drive mappings; in that event, pass the underlying UNC path.

Workaround for launching a GUI application elevated from a given working directory :

Since changing to the working directory must happen in the new, elevated process, a helper shell process is needed to perform this operation, which is best done via cmd.exe (for better performance):

$exeToLaunch = 'Notepad.exe' # may include arguments
$dir = $PWD.ProviderPath # use the current dir.

Start-Process -Verb RunAs -WindowStyle Hidden cmd.exe @"
/c cd "$dir" & $exeToLaunch
"@

Answer 5

I just ran your code example and it opened correctly for me at the WorkingDirectory location. Ensure the directory exists before you run the command. I tested against a drive on C and secondary drive as well and both worked.