bugs of MSIX packaging tool PSF feature

Hi, Guys I once opened a question this September, regarding the PSF Environment Variable fixup issue. As nobody replied the thread, I revoked it, and started to investigate the issue by myself in free cycles. 3 weeks ago, I found the root cause of the issue. Trying to explain the detail here.

Initially, To test the environment variable fixup, I created a Powershell2exe exe by converting below powershell script into an exe.

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

[System.Windows.Forms.MessageBox]::Show("The Environment variable %MSIX% has the value of ${env:msix}")

After reading PSF readme, I realized that the Poweshell2Exe solution doesn't work with PSF fixups. The Environment Variable fixup can only intercept the API of GetEnvironmentVariable from kernel32, also doesn't support API GetEnv from VC runtime.

I set up a least simple test environment (my job role doesn't have the access to full visual studio IDE, so just download the VS build tools which include the c/c++ compile/link exes and the windows SDK), cl.exe and those static libs are good enough to build a test exe which can retrieve the environment variable by calling GetEnvironmentVariable.

Unfortunately, the test Exe still doesn't work with the PSF Environment Variable Fixup .

By using the debugView to collect the PSF log output, you can find that the last log info we can get comes from the psfruntime  routines (config.cpp\load_json), we don't see any log comes from Environment variable fixup after that. This log info did mislead me too much, it made me believe that there is sth wrong in the psfruntime, not from the fixup dll.

I kept trying to locate the issue from PSFRuntime with no good, until I use my test environment to add

GetLastError to the suspicious BP, which tells me that the Environment variable fixup dll (EnvVarFixup32.dll) failed in initializing itself.

I then found that the EnvVarFixup32.dll comes with the MSIX packaging tool had disabled all the log output, and that is why we don't see any fixup dll log from DebugView. Replace the original one with the rebuild one.

With the rebult dll logs support, I can locate the issue to the code InitializeFixup.cpp\ InitializeConfiguration

This is the MSIX Packaging Tools generated config.json file. The above code treats the attribute as string type. But the generated json file treat it as Boolean type.

Apply the double quotation marks to the value, test the MSIX pkg again, Issue SOLVED.

Last week, I also reviewed the DLL redirection fixup when I have free cycle. There is a similar bug for the DLL redirection fix. Below is the MSIX packaging tool generated json file.

You can see this time the auto generated json file sets the attribute "forcePackageDllUse" as a string value. Unfortunately, the DLL redirection fix up (DynamicLibraryFixup32/64.dll) reads it as a Boolean value.

So, this time all you need to do is REMOVING the double quotation mark, or you will get the same DLL initialization error.

During the investigation of the DLL redirection fixup, I realize that there is limitation from the detour, the tech PSF uses to intercept the windows API calls. I can see some types of the exe files are not compatible with the detour. eg, IBM lotus Organizer. (Org6.exe).

I also found that some sites gave out incorrect json sample file, eg,

"filepath": "\\VFS\\ProgramFilesX86\\MSIXPSF\\DLLRedirect\\dll\\PSFDll.dll", this path pattern will not work. The dll path will not redirect to your expected path PsfPkgRootPATH\\VFS\\ProgramFilesX86\\MSIXPSF\\DLLRedirect\\dll\\PSFDll.dll. std::filesystem::path operator "\" will give out the value as "c:\\VFS\\ProgramFilesX86\\MSIXPSF\\DLLRedirect\\dll\\PSFDll.dll" instead.

I use MSIX packaging tool (1.2024.405.0) to create above MSIX test packages. Due to company policy, I don't have MS Store access, so can't test the 1.2024.508.0 from MS Store, if 1.2024.508.0 still has the bugs I mentioned above, please fix them asap.