Skip to content

Conversation

@Dids
Copy link

@Dids Dids commented Sep 17, 2025

Problem

image

Recent Windows 11 24H2 updates caused two issues with PSF:

  1. Removed the Install DWORD value from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1 while leaving the key itself intact, breaking PowerShell detection logic. PSF may have also been re-creating the \1 key, but at that point it would still be empty.

  2. Broke %MsixPackageRoot% variable replacement in config.json, causing it to resolve to an empty string instead of the package installation path. Not directly related to PSF as far as I'm aware, but potentially a common issue for others.

Solution

  1. Check if the Install value exists when the \1 key opens successfully. If it's missing, trigger the existing fallback logic to check for the \3 key. The code is hopefully fairly self explanatory.

  2. For the %MsixPackageRoot% issue, users should omit the workingDirectory property entirely from config.json to use the default package root path resolution, which works just fine. This may have also been user error on my part, but I had been using this for years with no issue.

Testing

Tested on a Windows 11 24H2 installation. PowerShell scripts now execute correctly, and apps launch properly when using default path resolution instead of %MsixPackageRoot%.

@TimMangan
Copy link
Contributor

TimMangan commented Oct 4, 2025

%MsixPackageRoot% is only supported for the paths of start/end script paths. Entries for the working directory are assumed to be relative to the package root folder, so an entry value of "" is the default pointing to the root folder of the package.

But the powershell change is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants