Variables issue breaking scripts

[rich12312]

A child process spawned by Desktop Commander inherits an incomplete environment block — 30 variables, missing ProgramData, ALLUSERSPROFILE, windir, COMPUTERNAME, USERDOMAIN and OS. Windows OpenSSH's ssh.exe -V exits 255 with no output; setting ProgramData alone fixes it. ALLUSERSPROFILE set to the same path does not substitute. Expected: children inherit the full user environment as a normal console does.

[rich12312]

Bug report — child processes on Windows inherit an incomplete environment block

Severity: Low frequency, high diagnostic cost. Nothing is corrupted; tools
fail in a way that is very hard to attribute.

Platform: Windows 11, PowerShell 5.1 and PowerShell 7.x, both affected
identically.

---

Summary

Processes started via start_process on Windows inherit an environment block
that is missing several variables Windows itself normally guarantees. In our
case six were absent:

ProgramData
ALLUSERSPROFILE
windir
COMPUTERNAME
USERDOMAIN
OS

Most tools never notice. Some fail hard, and at least one fails silently.

The failure that cost us the most

Windows OpenSSH (C:\Windows\System32\OpenSSH\ssh.exe) resolves its
system-wide configuration under %ProgramData%\ssh\. With ProgramData unset
it exits 255 having written nothing at all — no stdout, no stderr, no
event log entry, no message of any kind. ALLUSERSPROFILE does not substitute.

ssh -V alone fails this way, so even a version probe returns 255. That makes
the binary look broken rather than mis-invoked.

Git for Windows' bundled ssh.exe (MSYS2) is unaffected, because it resolves
its configuration relative to its own installation prefix rather than
%ProgramData%.

Why this is expensive to diagnose rather than merely annoying

The symptom presents as "this specific binary is broken on this machine". Every
natural next step reinforces that reading:

• The System32 binary fails; the Git binary works. Conclusion drawn:
  the System32 build is damaged.
• Running the same script in an elevated terminal succeeds. Conclusion drawn:
  it is a permissions or elevation problem. In fact the elevated terminal was
  launched by the shell and therefore had a complete environment — the two
  runs differed in privilege and environment and launcher, so the
  comparison could not isolate anything.
• Re-running under PowerShell 7 instead of 5.1 fails identically. Conclusion
  drawn: not a shell-version issue, therefore environmental factors ruled out.
  In fact PowerShell 7 was started the same way and inherited the same
  incomplete block, so the control shared the fault and proved nothing.

Each of those is a reasonable inference. All three point away from the cause.
Acting on the second one, a system file check was authorised and run against a
machine that had nothing wrong with it.

The single diagnostic that would have resolved this immediately is printing the
environment block, which is not something anyone thinks to do when a binary
appears broken.

Reproduction

1. Via start_process, run a script containing:

   "ProgramData=[$env:ProgramData]"
   & "C:\Windows\System32\OpenSSH\ssh.exe" -V
   "exit=$LASTEXITCODE"
   

2. Observed: ProgramData=[], no version banner, exit=255.

3. Run the same script from an ordinary interactive terminal.

4. Observed: ProgramData=[C:\ProgramData], version banner printed, exit=0.

Setting $env:ProgramData = 'C:\ProgramData' before the call in case 1 makes it
succeed, with nothing else changed.

Suggested fixes, in order of preference

1. Pass the full parent environment through to spawned processes on Windows,
   rather than a subset. This is the actual fix.
2. If a filtered environment is deliberate, guarantee the small set of
   variables Windows treats as always-present — at minimum ProgramData,
   ALLUSERSPROFILE, windir, SystemRoot, COMPUTERNAME, USERDOMAIN, OS.
3. Failing both, document the filtering, because the resulting failures are
   silent and are attributed to the wrong component by default.

Not claimed

We have not established why the environment is filtered, whether it is
intentional, or whether the set of missing variables is stable across versions
or machines. Those are observations from one Windows 11 host. The report is the
behaviour and its cost, not a diagnosis of the implementation.