I dont know why would anyone do this, but here it goes: you cannot launch another powershell.exe using Start-Process cmdlet with -UseNewEnvironment switch.
Windows PowerShell:
Start-Process -FilePath C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoNewWindow -UseNewEnvironment
PowerShell Core (Debug build):
Start-Process -FilePath .\powershell.exe -NoNewWindow -UseNewEnvironment
A new instance of powershell.exe console should start.
Windows PowerShell outputs error and dies:
Internal Windows PowerShell error. Loading managed Windows PowerShell failed with error 8009001d.
PowerShell Core (Debug build) outputs more errors + assert message and dies:
Error resolving full path []
Error resolving full path []
PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
The shell cannot be started. A failure occurred during initialization:
ASSERT: caller makes sure it's not null or empty
> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14409.1005
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14409.1005
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-alpha
GitCommitId v6.0.0-alpha.18-9-g8d4db01a5d4b5dcd981ef216d3d7f24b484c7c60-dirty
WSManStackVersion 3.0
CLRVersion
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
PSRemotingProtocolVersion 2.3
PSEdition Core
SerializationVersion 1.1.0.1
It seems we have two problems.
Error resolving full path []
The shell cannot be started. A failure occurred during initialization:
ASSERT: caller makes sure it's not null or empty
The first, I fixed by restore "ProgramFiles" and "ProgramFiles(X86)"environment variables for subprocess.
I don't understand how PowerShell use it in start time and perhaps my fix is not in right place.
The second problem is that new PowerShell process get wrong cursor position in the same console windows. I belive we should open new trackig Issue.
What -UseNewEnvironment appears to be doing is to define _only_ the variables that are _explicitly_ defined, as displayed in System Properties (sysdm.cpl) (with user-level definitions taking precedence over system-level ones, as usual).
However, the _implicitly_ defined environment variables are missing, among them the two @iSazonov mentions.
Additionally, $env:USERNAME contains SYSTEM, because it is explicitly defined as a system-level variable, but not at the user level (where it is normally implicitly defined to reflect the current user).
List of missing, normally implicitly defined environment variables (I don't know what mechanism defines them by default):
ALLUSERSPROFILE
APPDATA
CommonProgramFiles
CommonProgramFiles(x86)
CommonProgramW6432
COMPUTERNAME
HOMEDRIVE
HOMEPATH
LOCALAPPDATA
LOGONSERVER
ProgramData
ProgramFiles
ProgramFiles(x86)
ProgramW6432
PUBLIC
SESSIONNAME
SystemDrive
SystemRoot
USERDOMAIN
USERDOMAIN_ROAMINGPROFILE
USERPROFILE
@iSazonov:
The second problem is that new PowerShell process get wrong cursor position in the same console windows. I belive we should open new trackig Issue.
I think that's an artifact of using -NoNewWindow without -Wait, which makes the output appear asynchronously.
(Normally, if you wanted to run a console app synchronously in the _same_ window you wouldn't use Start-Process at all; my guess is that @0xfeeddeadbeef only included -NoNewWindow so that the error message would show; without it, you'd just see a new window opening and closing right away.)
On Windows, you should use CreateEnvironmentBlock function to create a complete block of environment variables for a specified user.
:tada:This issue was addressed in #10830, which has now been successfully released as v7.1.0-preview.2.:tada:
Handy links:
Most helpful comment
On Windows, you should use
CreateEnvironmentBlockfunction to create a complete block of environment variables for a specified user.