The Package Support Framework (PSF) was originally a Microsoft open-source project to help Win32/DotNet applications run when inside an MSIX Container. TMurgent has taken up the support for the PSF in our own fork here on GitHub.
December brings a long-awaited feature to MSIX to the PSF. How long? Well, it was one of the first items of feedback that I provided Microsoft when evaluating a pre-release version of the MSIX Packaging Tool in March of 2018 (6 months before the initial release).
But first the short list of major changes in this release, followed by detailed descriptions. At the end of the article, I will also post the full list of changes from the release notes.
Major Change List:
- HKLM Write Redirection in RegLegacyFixup.
- CreateProcess fixes for linux-like apps.
- GUID spoofing to upper case in COM calls in PsfLauncher.
- Support for systems with KNOWN FOLDER mapping to file shares in MfrFixup.
And on to the details…
HKLM Write Redirection in RegLegacyFixup
This feature fills one of the last feature gaps for customers wanting to move on from Microsoft App-V to MSIX – the ability of the application to write to HKEY_LOCAL_MACHINE.
Some older applications expect to be able to write to HKLM locations in the registry. We are talking about old, crappy, apps here. Ones that are around because the customer doesn’t have a replacement, either because there are no developers (the vendor has abandoned the app or it was built in-house), or the vendor has no competition and doesn’t seem to care (I’m calling out you, Bloomberg Terminal).
With the native installation, these apps no long work unless someone goes in and alters the permissions on the necessary keys, which are typically only used by this application, to give standard users permission to write there.
This is something that App-V handled automatically, by detecting the attempt to modify HKLM and re-directing those changes to a special area under the user’s HKCU for the application package. For some of those App-V customers now converting over, they may not even be aware that the app did this. And now that so many are making the move over to MSIX this year, they are discovering apps that have this issue.
Under MSIX, there is NO ability to write to HKLM, and until now the PSF provided no help for this, although the PSF RegLegacyFixup did include remediation for some other HKLM permission issues.
In this version of the PSF, we add support for HKLM writes based on the same pattern we see in App-V. The support is triggered for a new, optional, configuration rule to be placed in the config.json file for RegLegacyFixup, called “HKLM2HKCU”.
When added to the fixup configuration, writes to HKLM will now be redirected to the user’s virtual registry under HKCU\vHKLM_Redirection. The changes involve not only performing the redirection but ensuring the proper reading of these two layers on other interactions including opening and querying registry keys and items. Several new intercepts needed to be added to the fixup to provide full support for the feature.
As an optional rule, this change should not impact packages that do not request the feature, something that is up to the person or tooling adding in the fixup.
At the same time, the extra debug logging available in the PSF was updated in this fixup to provide better details on what the fixup is doing and clearer result code interpretations.
Create Process fix for “Linux-like” Apps
We have seen a number of applications that use numerous child and grand-child processes and some of those have had issues we identified as “inter-process communication” issues and have not been able to find the cause, until now. Quite often, these are apps that are cross-platform and written in the style the Linux developers like. Maybe we do now.
When apps inside the container spin off child processes, we have to make changes to the process Startup Attributes list to ensure that their children also run inside the container.
Some applications start child processes with their own attributes list. Most of the time this list contains the same attribute we want to modify and so we can modify it in place.
But there is no supported API from Microsoft to add an additional attribute to an existing list.
The problem apps appear to be console applications, and we can see that they are passing shared handles to stdin and stdout console ports in the attribute list. I had never considered this and assumed the problem apps were using a conventional inter-process communication method like a socket or named pipe. The previous fixup for CreateProcess was throwing these attributes out to add in the attribute we needed.
In this version, we have used reverse-engineering techniques to be able understand the undocumented data structure (to be clear, we did not reverse engineer Microsoft code because that would be a no-no. We just used some of the techniques used by folks that do that) so that we can create the list we need. So, while Microsoft documentation tells us that we cannot add new items to the list once the list is created, we found a way to do just that.
Additional debug logging was also added to the PsfRuntime, not only to shed light on these attributes, but also to extract new information we uncovered about the Job Object for processes, which roughly translates to the Container the process is running in. This may be helpful for understanding other situations where processes go awry in the future.
Bottom line: more apps now just work in MSIX.
GUID spoofing to upper case in COM calls
Traditionally, GUIDS for COM are normally, but not always, specified by installers using upper case characters. The native system doesn’t really care as the registry is generally case insensitive when it comes to key and item names.
The Microsoft MSIX Packaging Tool converts these GUIDs to lower case for some reason. But as they are specified in the AppXManifest, and the AppXManifest is case sensitive when it comes to uniqueness and completion rules in the schemas, we needed consistency, so we always expected and use lower-case GUIDs.
But we have now seen an app that has internal code that fails unless the GUID returned is upper-case.
In the September release of the PSF, we had added intercepts in PsfLauncher to allow us to view potential COM issues by monitoring the application calls into COM activation. Until now, these were only for monitoring but with an idea to fix things up and we find them.
In this release we provide the GUID in upper-case whenever it is returned to the application.
KNOWN FOLDER mapping in MfrFixup
The MfrFixup uses the system Known Folders to identify certain file paths, in essence to be able to map virtual file and registry VFS paths to their actual counterpart locations on the native system.
We have seen an MFRFixup that occurs when the value of a known folder is not in drive:\folder form but is a UNC form such as \\server\folder. The MFRFixup was ignoring these mappings as invalid. This is now addressed in this fixup.
Note: The FileRedirectionFixup likely has the same flaw, and it is not being addressed as that fixup is deprecated. The MfrFixup should be used instead.
Supporting Tooling
This version of the PSF will be included in Release 7.0.0.0 of TMEditX.
It will be included in the next release of PsfTooling (next release following the current release of 6.14).
For other vendors that use this branch of the PSF, check with that vendor.
Full Release Notes:
December 2025 Updates
- RegLegacyFixup: Add new optional rule that allows packaged apps to write to HKLM. HKLM2HKCU rule allows these writes by redirecting these writes to a new key in the virtual registry under HKCU. This is similar to how App-V worked and help fill a major gap in compatibility. Several new intercepts were also added to this fixup to handle this new support, including RegQueryInfoKey, RegSetValue, and RegSetValueEx.
- PsfRuntime: When launching a process, if the caller includes Startup Attributes, integrate those with the attributes we must add to keep the process inside the container. This solves some longstanding issues with apps that start child processes that are console apps, especially using programming patterns typically seen in cross-platform (linux) apps that communicate by using stdin/stdout handles passed to the child this way.
- PsfRuntime: When launching a process, if it requests a working directory and it does not exist, create the virtual directory first.
- PsfRuntime: When launching a process, check if the caller already requested the process to start suspended. PsfRuntime normally suspends the new process so that it can inject PSF dlls into it and then resumes the process once that is done. With this change, if the caller requested suspension, PsfRuntime should not resume the process, but leave that to the calling process.
- PsfRuntime: Added experimental added logging (when logging level is increased for debugging) about the job object that a process in running in at its startup. This debugging will aid us in solving additional compatibility issues in certain apps.
- PsfRuntime: Updates to intercept CreateProcessAsUser to solve process launching issue.
- PsfRuntime: When starting a process, use the full path to the exe if known. Solves issue with how some apps start child apps and ApplicationAlias doesn’t find it (for some unknown reason). In one known case, there was a bug in the open-source vendor code that was triggered, but we can fix is here.
- MfrFixup: Tweak to the logic in determining when to pre-create directories in the redirection area to ensure directories are created in certain situations.
- MfrFixup: Support added for customer scenarios that use traditional “Folder Redirection” techniques to redirect known folders using URL paths to file shares.
- EnvVarFixup: Handle the case of an app that calls GetEnvironmentVariable with a null name.
- PsfRuntime: In the previous release we added informational logging of COM calls by the app. In this release we solve an issue seen whereby the case of the COM Guids were important. The MMPT converts these to lower case and we now reconvert them to upper case when called by the app to solve this issue. Eventually this code may move to a new ComFixup dll.
For those unaware, PSF stands for Package Support Framework, an open-source utility that I contribute to for helping traditional Win32 and DotNet applications run inside the MSIX packaging container. This article contains information regarding new contributions.
