tl;dr:
The -s
option is an expected part of the command line used to launch a background job via a new PowerShell process - it puts the new process in server mode, which is required to communicate with the calling process for background job management.
- It is not a legacy option, but it isn't documented either, because it is only meant to be used internally by PowerShell.
Given that everything you describe is as expected, the problem is likely with the specific commands you run via -InitializationScript
and in the main script block (the implied -ScriptBlock
argument).
As you've discovered, a Start-Job
call spawns a powershell -s -NoLogo -NoProfile
call behind the scenes (discoverable via Task Manager).
That is, a new PowerShell process is created to run the commands in the background.
An -EncodedCommand
parameter with a Base64-encoded command string is only present if you invoked Start-Process
with the -Initialization
parameter - the main script block (the (implied) -ScriptBlock
argument) is not passed via the command line (see below).
-s
is used PowerShell-internally - always - to invoke background jobs, and -s
, as you've also discovered, is an alias for the -servermode
switch. (Given that only -STA
is documented, one would expect -s
to be short for -STA
, but it is not).
-s
/ -servermode
is an implementation detail, used only by PowerShell itself, which is why it isn't documented.
This location in the PowerShell Core source code on GitHub shows you how the command line for the background process is constructed.
Server mode is the mode the background process must be in in order to communicate with the calling process via its standard streams (stdin, stdout, stderr): That is, the command to execute in the background is sent to the background process through its stdin stream, and the background process reports its output via its stdout and stderr streams.[1]
Note that XML-based serialization / deserialization happens during this inter-process communication, using the same infrastructure as PowerShell remoting - see this answer for more information.
[1] Ohad Schneider points out that it is possible to accidentally disrupt this communication if the main script block contains commands such as Start-Process -NoNewWindow
with a console program that directly write to the background process' stdout stream - see this answer.