Env Var Fixup not working

[MasterPackager]

I have created a test package with just some copied cmd.exe files and trying to add an environment variable in the PSF. Here is my config.json { "applications": [ { "id": "TESTOne", "executable": "VFS/AppVPackageDrive/test/test1.exe", "workingDirectory": "VFS/AppVPackageDrive/test/test1/" }, { "id": "TESTTwo", "executable": "VFS/AppVPackageDrive/test/test2.exe", "workingDirectory": "VFS/AppVPackageDrive/test/test2/" }, { "id": "TESTThree", "executable": "VFS/AppVPackageDrive/test/test3.exe", "workingDirectory": "VFS/AppVPackageDrive/test/test3/" } ], "processes": [ { "executable": "test1" }, { "executable": "test2" }, { "executable": "test2" } ], "config": { "EnvVars": [ { "name" : "Var1Name", "value" : "SpecifiedValue1", "useregistry": "false" }, { "name" : "Var2Name", "value" : "BackupValue2", "useregistry": "true" } ] } }

As you can see the variable is not visible, but the PSF is working as the working directory is modified:

I have also attached the MSIX package here: testenv_1.1.1.0_x64__ywx2rxjwzwnxe.zip

Is the config file incorrect or is the fixup not working correctly?

Also the example in readme.md here - https://github.com/microsoft/MSIX-PackageSupportFramework/tree/master/fixups/EnvVarFixup is incorrect

[MasterPackager]

We spoke with @TimMangan at AppmanageEvent and he suggested that it is not being applied because cmd is not inside the bubble. He was right, but I tried with another application and still cannot get the environment variable to show up. MasterPackager_22.3.8241.1_x64__ywx2rxjwzwnxe_Envfix_signed.zip We would really appreciate if @TimMangan you could take a look at this.

[TimMangan]

Let's talk offline. I need to understand which version of the PSF sources you are including.

[TimMangan]

Oh how I wish the dlls had version markings...

[dhoehna]

@MasterPackager You can force CMD.exe to be launched inside the package by preventing breakaway. Check out Powershellscriptrunner.h Docs for proc thread attribute.

PSF uses this to prevent powershell from breaking away.

[MasterPackager]

Let's talk offline. I need to understand which version of the PSF sources you are including.

@TimMangan This time I used TMEditX-2.4.0.0-X64 to add the PSF, so I guess you should be able to tell the version from that.

[MasterPackager]

@MasterPackager You can force CMD.exe to be launched inside the package by preventing breakaway. Check out Powershellscriptrunner.h Docs for proc thread attribute.

PSF uses this to prevent powershell from breaking away.

@dhoehna thank you. this is useful, but the problem isn't that cmd is not in the bubble, but the fact that I can't get the envvar fixup working at all.

[dhoehna]

Oh. I am sorry. Jumped the gun there. @ravishroshanms have you looked into this?

[aniketbanerji]

The SET command in command prompt displays user, system environment variables (which are stored in global HKLM and HKCU registry).

This fixup adds environment variables in package scope and hence does not get added in global hive (where system or user environment variables are stored). So, environment variables added through this fixup can't be seen through SET command in command prompt.

Using GetEnvironmentVariable in your application would confirm if the environment variable has been added for the package.

[TimMangan]

Oh, The JSON shown looks like it has a different problem, one probably preventing the fixup to be loaded into the application at all.

The value of the json field "executable" under "processes" should be a regex pattern, and I don't think "MasterPackager" will match "MasterPackager.exe". The value "MasterPackager" with a 'period asterisk' after should. Also, the value of just the period asterisk would match any program running inside the container, which is what I normally use.

[MasterPackager]

@TimMangan I added "MasterPackager" when "." didn't work. I tried with the default json also that was generated by TMEditX-2.4.0.0-X64 which also didn't work - `{ "enableReportError": true, "applications": [ { "id": "PSFLAUNCHEROne", "executable": "VFS\ProgramFilesX86\Master Packager\MasterPackager.exe", "arguments": "", "workingDirectory": "" }, { "id": "PSFLAUNCHERTwo", "executable": "VFS\ProgramFilesX86\Master Packager\MasterRepackager.exe", "arguments": "", "workingDirectory": "" }, { "id": "PSFLAUNCHERThree", "executable": "VFS\ProgramFilesX86\Master Packager\MasterWrapper.exe", "arguments": "", "workingDirectory": "" } ], "processes": [ { "executable": "^PsfLauncher." }, { "executable": "^[Pp]ower[Ss]hell." }, { "executable": ".", "fixups": [ { "dll": "EnvVarFixup.dll", "config": { "envVars": [ { "name": "TestSystem", "useregistry": "true", "value": "TestSystem" }, { "name": "TestUser", "useregistry": "false", "value": "TestUser" } ] } } ] } ] }`

@aniketbanerji I used process explorer also to check the environment variables and they are not there.

[TimMangan]

There are two requirements to see the virtualized environment variables:

1. The process enumerating or querying the variable must be running inside the container.
2. The process enumerating or querying the variable must use a standard api to perform the action. I believe that Process Explorer uses underdocumented interfaces to read kernel memory (the Process block) directly, which does not know about the virtualized variables.

To determine if the process is in the container you can use an elevated Process Explorer (either inside or outside of the container) and look at the Jobs tab. Alternatively, you can add the "Package Name" and/or "JobID" column in Task Manager.

To see what the app sees, you can create a shortcut to a cmd in the package (to run inside the container), or alternatively you can use the powershell "invoke-CommandInDesktopPackage". In both cases, you use period asterisk method in the json.

[MasterPackager]

@TimMangan 1. Usually I would think so, but it shows an environment variable that is set only during runtime from MasterPackager.exe. 2. And if it can see variables set during runtime then I think it should be able to see psf variables too. I will try including process explorer in the package or try the invoke-CommandInDesktopPackage.

you can create a shortcut to a cmd in the package

That is the first problem I had. That cmd was not running within the container and it had no job ID in task manager.

[MasterPackager]

I managed to finally get it working by writing my own small console app that just outputs the value of an environment variable. The JSON example provided here is completely wrong - https://github.com/microsoft/MSIX-PackageSupportFramework/tree/master/fixups/EnvVarFixup I only got it working thanks to @TimMangan TMEditX, that created the JSON syntax correctly, without it I would not have understood what the correct syntax is for this fixup. Thanks @TimMangan

[TimMangan]

Hopefully the documentation here: https://github.com/TimMangan/MSIX-PackageSupportFramework/blob/develop/fixups/EnvVarFixup/readme.md (which is what TMEditX uses) is correct, and maybe now a bit clearer.