Issue:
In order to obtain the Exit Code from a Process we are executing the Start-Process cmdlet with the following parameters:
-PassThru -Wait -WindowStyle Hidden
or
-PassThru -Wait -NoNewWindow

In rare cases, this leads to the following exception:
System.Management.Automation.CmdletInvocationException: Cannot process request because the process (<ProcessIdHere>) has exited. ---> System.InvalidOperationException: Cannot process request because the process (<ProcessIdHere>) has exited.
at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
at System.Diagnostics.Process.OpenProcessHandle(Int32 access)
at System.Diagnostics.Process.get_Handle()

After the Exception occurred, the returned Object does not contain a Handle nor Exit Code but the executable itself executed without issue.

We also tried to remove the “-Wait” Parameter and use the $process.WaitForExit() Method without success (as proposed here: https://stackoverflow.com/questions/44057728/start-process-system-diagnostics-process-exitcode-is-null-with-nonewwindow and https://stackoverflow.com/questions/10262231/obtaining-exitcode-using-start-process-and-waitforexit-instead-of-wait).

This happens on Windows 7 and Windows 10 Clients.
When the issue occurs, it is mostly when running small and low footprint executables like reg.exe.

Possible Cause:
This error is probably caused by the fact, that the process which was opened by Start-Process has already finished (and thereby is already killed) when Start-Process tries to get the handle.

Example:
$process = Start-Process -PassThru -Wait -NoNewWindow -FilePath “C:\Windows\System32\reg.exe” -ArgumentList “import C:\temp\dummy.reg”

1. Start-Process executes “reg.exe”
2. “reg.exe” terminates, before Start-Process is able to get the handle (get_Handle Method)
3. Start-Process throws a System.InvalidOperationException Exception

PowerShell Environment:
PSVersion 5.1.16299.666

Is it possible to fix the behavior of Start-Process in order to get consistent results?

Add the ability to make SOAP calls which originally was done using New-WebServiceProxy.

SOAP services are still common in both small companies and large enterprise where some products only have this method of integration. Many legacy systems both purchased and built in house use SOAP and will continue to for a significant time as the cost of upgrading is either too great, does not make commercial sense or simply impossible.

I have only just started to look at PowerShell 6 and this is a complete road block for using it at this time. If there are alternative options without having to use HttpClient and build the full messages which can be very complex, please let me know.

In module "RemoteDesktopServices"

Run powershell as administrator, execute next:

Import-Module RemoteDesktopServices
New-Item -Path "RDS:\GatewayServer\RAP" -Name "Test_RAP_1 (test)" -UserGroups "Remote Users@DomainName" -ComputerGroupType 1 -ComputerGroup "RDS_group@DomainName"

Get error:
New-Item : The path contains characters that are not valid.
At line:1 char:1
+ New-Item -Path "RDS:\GatewayServer\RAP" -Name "Test_RAP_1 (test 123)" ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (RDS:\GatewaySer...AP_1 (test 123):String) [New-Item], ArgumentException
+ FullyQualifiedErrorId : IllegalCharacters,Microsoft.PowerShell.Commands.NewItemCommand

but if execute without parenthesis characters, its will executed with success

New-Item -Path "RDS:\GatewayServer\RAP" -Name "Test_RAP_1 test" -UserGroups "Remote Users@DomainName" -ComputerGroupType 1 -ComputerGroup "RDS_group@DomainName"

Moreover, if you create a policy through a graphical interface, then there are no such problems.

It's probably useless and a shame that M$$ is usually not fixing this kind of bugs:

Some PowerShell xml Files have the wrong encoding, for example this one:
c:\Windows\System32\WindowsPowerShell\v1.0\Event.Format.ps1xml

It states that it is using:
<?xml version="1.0" encoding="utf-8" ?>
but in fact, it's utf-16.

Test it:
$xmldoc = New-Object xml.XmlDocument
$xmldoc.Load('c:\Windows\System32\WindowsPowerShell\v1.0\Event.Format.ps1xml')
Exception calling "Load" with "1" argument(s): "'.', hexadecimal value 0x00, is an invalid character. Line 2, position 1."

Change the header to:
<?xml version="1.0" encoding="utf-16" ?>
and it will work.

M$ still does not have the most basic unit tests to assure that config files must have the right encoding?
Shame on you, M$$!

It's even worse: M$$ must have developed code to workaround this bug - otherwise, PowerShell would raise an exception because .Net is crashing.

It's probably useless and a shame that M$$ is usually not fixing this kind of bugs:

Some PowerShell xml Files have the wrong encoding, for example this one:
c:\Windows\System32\WindowsPowerShell\v1.0\Event.Format.ps1xml

It states that it is using:
<?xml version="1.0" encoding="utf-8" ?>
but in fact, it's utf-16.

Test it:
$xmldoc = New-Object xml.XmlDocument
$xmldoc.Load('c:\Windows\System32\WindowsPowerShell\v1.0\Event.Format.ps1xml')
Exception calling "Load" with "1" argument(s): "'.', hexadecimal value 0x00, is an invalid character. Line 2, position 1."

Change the header to:
<?xml version="1.0" encoding="utf-16" ?>
and it will work.

M$ still does not have the most basic unit tests to assure that config files must have the right encoding?
Shame on you, M$$!

It's even worse: M$$ must have developed code to workaround this bug - otherwise, PowerShell would raise an exception because .Net is crashing.

It's annoying that we have to report Bugs in UserVoices
and its a shame that M$$ is fixing BUGS only if there are enough UserVoices.

Anyway:

Hello

If we create this Directory Junction between local Drives:
mklink /J C:\Temp D:\Data\Temp\

So that accessing: C:\Temp\
in fact works here: D:\Data\Temp

Now, if we call e.g.
(Get-Item C:\Temp\MyFile.txt).Target

We get:

Wrong: Target : {C:\Data\Temp\MyFile.txt}
Should be: Target : {D:\Data\Temp\MyFile.txt}
It's a shame that M$ still does not have Unit Tests to validate the most basic situations.
(Assuring to return the right Target on different LinkTypes, is the most important reason for this code.)

This issue exists in all PowerShell versions, probably because even Tools like FindLinks64.exe (Sysinternals) returns the wrong Drive.

Kind regards,
Thomas

It's annoying that we have to report Bugs in UserVoices
and its a shame that M$$ is fixing BUGS only if there are enough UserVoices.

Anyway:

Hello

If we create this Directory Junction between local Drives:
mklink /J C:\Temp D:\Data\Temp\

So that accessing: C:\Temp\
in fact works here: D:\Data\Temp

Now, if we call e.g.
(Get-Item C:\Temp\MyFile.txt).Target

We get:

Wrong: Target : {C:\Data\Temp\MyFile.txt}
Should be: Target : {D:\Data\Temp\MyFile.txt}
It's a shame that M$ still does not have Unit Tests to validate the most basic situations.
(Assuring to return the right Target on different LinkTypes, is the most important reason for this code.)

This issue exists in all PowerShell versions, probably because even Tools like FindLinks64.exe (Sysinternals) returns the wrong Drive.

Kind regards,
Thomas