Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Hey.

This is also seems to reach back to the days of powershell.exe but still happens with current 7.4 versions.

I run some (POSIX) shell scripts from Cygwin, and for some Windows specific stuff they use PowerShell since there's no better way to get to the data.

One thing is, that – since in my shell scripts I sanitise (that is clear) most env vars – I have a function that searches for the executable path of a Windows Python installation.

That function supports "manual" installations, but also ones via the Microsoft Store, so I do something like:

powershell.exe -NonInteractive -NoProfile -Command "
\$ErrorActionPreference = 'Stop'
( Get-AppxPackage -Publisher 'CN=4975D53F-AA7E-49A5-8B49-EA4FDC1BB66B' -Name 'PythonSoftwareFoundation.Python.*'  |  Sort-Object -Descending -CaseSensitive -Property { [System.Version](\$_.Version) } ).InstallLocation   |   Write-Host
                              "

to get the list of Python App Installation pathnames, sorted by version.

If using pwsh.exe on may need to add a Import-Module Appx -UseWindowsPowerShell (because of the nasty #13138). I'm using Windows 10 (don't wanna throw away my still perfectly working hardware just to satisfy Win 11's nonrequirements ;-) ).

Works in principle fine, but as I've mentioned earlier, my shell scripts basically clear their environment (except for a few things like PATH (which they overwrite however with a POSIX like path list O:-) )... and it turns out, that this causes the file tree:

.
└── %SystemDrive%
    └── ProgramData
        └── Microsoft
            └── Windows
                └── Caches
                    ├── cversions.2.db
                    ├── {6AF0698E-D558-4F6E-9B3C-3716689AF493}.2.ver0x0000000000000001.db
                    └── {DDF571F2-BE98-426D-8288-1A9A39C3FDA2}.2.ver0x0000000000000001.db

to be created, whenever I run Get-AppxPackage.

Seems the culprit is that I have no SYSTEMDRIVE env var set in my (POSIX) shell script, and thus PowerShell probably doesn't get it either.

One can (from Cygwin) easily test via:

1. env -i SYSTEMDRIVE="${SYSTEMDRIVE}" '/cygdrive/c/Program Files/PowerShell/7/pwsh' -NonInteractive -NoProfile -Command "
   \$ErrorActionPreference = 'Stop'
   Import-Module Appx -UseWindowsPowerShell
   ( Get-AppxPackage -Publisher 'CN=4975D53F-AA7E-49A5-8B49-EA4FDC1BB66B' -Name 'PythonSoftwareFoundation.Python.*' )
   "
   

   Here the env var is passed through and no %SystemDrive% is created

2. env -i '/cygdrive/c/Program Files/PowerShell/7/pwsh' -NonInteractive -NoProfile -Command "
   \$ErrorActionPreference = 'Stop'
   Import-Module Appx -UseWindowsPowerShell
   ( Get-AppxPackage -Publisher 'CN=4975D53F-AA7E-49A5-8B49-EA4FDC1BB66B' -Name 'PythonSoftwareFoundation.Python.*' )
   "
   

   Here all env vars are cleared and %SystemDrive% is created.

Expected behavior

Well, ideally it would of course somehow simply not create that directory and stuff beneath.<br>
So far I did "quite some" PowerShell scripting (which I all call the same from Cygwin with the same cleared environment), and I saw no issues when Windows env vars where missing... so it kinda would be nice if that would also work here (so maybe just don't create cache files?).

But I can of course understand, if you argue that these env vars, under Windows are mandatory like `libc` is in Linux.

In that case this should IMO however just produce an error and not spuriously create some file tree at the current working direction.<br>
Especially not with the name of the envvar (which I guess is just not expanded then but taken literally?). This in turn may even be one of the subtle things which an attacker might somehow abuse (not that I'd have any concrete attack with it).

Also, is there any documentation about which Windows env vars PowerShell strictly requires?

Actual behavior

Spuriously creates a file tree at the working directory.

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.19041.4412
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.4412
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

and

Name                           Value
----                           -----
PSVersion                      7.4.2
PSEdition                      Core
GitCommitId                    7.4.2
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

### Visuals

_No response_

Maybe that's also something more general. In particular I've just noticed that the same happens with python.

PS> Get-Command Get-AppxPackage

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Get-AppxPackage                                    1.0        Appx

Given that Get-AppxPackage comes from a module in 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx' then it seems reasonable that it has expectations of a windows environment. As far as I can tell it is not part of the PowerShell Core project.

since in my shell scripts I sanitise (that is clear) most env vars

Fortunately, you have already identified the root cause.

If you want to have a clean environment without any environment variables that Windows programs depend on, then don't run any Windows programs that depend on those environment variables.

If you want to have a clean environment without any environment variables that Windows programs depend on, then don't run any Windows programs that depend on those environment variables.

Well, still it's probably not good behaviour if the programs behave odd without any error, when crucial stuff is missing.

Well, still it's probably not good behaviour if the programs behave odd without any error, when crucial stuff is missing.

You are absolutely right, I would not recommend removing standard windows environment variables that windows apps have a reasonable expectation of being correctly set in order to operate.

PowerShell itself doesn't have a dependency on $env:SYSTEMDRIVE when using cmdlets in general so this seems to be something internal to the AppX module. That modules is part of Windows and not serviced as part of PowerShell so you'll need to report this via the Windows Feedback tool

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.

📣 Hey @philcerf, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms