Shimming apps that start other processes in the package.


I'm not sure if the PSF is designed to handle the need to shim child processes of the shortcut app.


For example, FileZilla.exe will start fzftp.exe as a child process.  I can put PsfShimLauncher in as the shortcut to launch FileZilla.exe with shims, but how would I get the shims into the child processes?  Will PsfShimLauncher also notice these as long as configured in the json?  If not, how would we do this?

10 Replies

It seems like something changed in 1809 regarding child process. On a machine pre-1809 the fixup is applied to the child process too but that does not happen anymore on machined with the 1809 update installed.

 I attached a simple test app (just rename the extension from zip to appx, it failed to upload it otherwise) we use internally. After you install it select "Launch second" to launch a child process and then "Write". On the pre-1809 machine this works, while on 1809 it crashes (i.e. the fixup does not get inherited from the parent process).


@John Vintzelconscious or accidental change in the OS?

I'll check into it and get back to you.



It seems to me that we have a general flaw regarding child processes and shims.  I think that in the end, the config.json would have to have both x86 and x64 shims listed, and the logic that imports them into the process would have to look at the process and decide which one to import.  


Any other solution will fail if a x86 app launches a child x64 app or visa versa.

if FileZilla.exe launches fzftp.exe via CreateProcess the fixup will apply to both, assuming both processes are in the package of course.



Hi Bogdan,


The custom Launcher in the sample calls the System.Diagnostics.Process.Start .NET function that in turn calls to Shell Execute. When calling Shell execute the process creation escapes out of the calling process and the fixup won’t apply, we are not supporting this scenario today.

Is there a specific reason why you are using it? Can you try using the official psfLauncher to achieve it.



Hi Vlad, John, 


Thanks for the quick reply.


We just used the standard documentation from  .NET to launch the process, we didn't write the code specifically to call ShellExecute or CreateProcess. Actually, we left the default value (true) for the property UseShellExecute when we initially wrote the code. If we set it to false, then indeed the child process inherits the fixup.


However, the point here is that the default for this property (UseShellExecute) in .NET changed over the 1809 update and this could affect other user apps too, not just our sample. Apps for which users might not be able to change the code.


This is what we were trying to understand, if this change was intended or accidental?


Regarding your question, we are using our customer launcher because it provides additional functionality (migrating user shortcuts, pins, appdata, etc.. from the old msi version of the app) while also including the PSF support you guys published. It is something we have in Advanced Installer long before PSF was announced. 


Also, as I said above, is we set UseShellExecute to false then the fixup is inherited, so there isn't a problem with our launcher, it behaves just as yours. 


@Tim Mangan

 From our tests, if you have the x86 and x64 executables called PsfRunDll<arch>.exe, and their corresponding dlls, next to the PSF runtimemanager then the fixups are correctly inherited by the processes, when launching a process for an app with a different bitness.






ShellExecute option is needed to launch some processes, for example, with RunAs (but there are other reasons too).  As we are dealing with legacy software, much of it was written without manifests and in ways that require elevation today.


@Bogdan Mitrache: So in your example, the json.conf file would also have reference to the 32 and 64 bit fixup files, but tied to the different applications?  I guess that works, as long as every app has an ApplicationId (exe files without shortcuts/ftas don't by default and might be an issue).  It might be better to be able to wildcard the application names (so we don't need to manually generate ApplicationIIds) in the lower section and have a 32 and 64 bit entries in the conf and have PsfRunDll figure it the bitness automatically.

Thanks Bogdan.

Can you please file it on feedbackhub and I will direct it to the .Net team. It will be great if you can add customers/apps that were impacted.

Changing to shell execute as a default is a reasonable change to guarantee the process launches in the foreground. We should probably add an interception to shell execute as well in our framework.



Thanks for the feedback Tim.

Do you know about specific app examples that are doing it today that you can share with us?


We do support cross-architecture launches where a 32-bit process is creating a 64-bit process or vice-versa.

You can include both arch fixups in the package and refer to them from the config.

Today this is the logic we have;

When enumerating the list of fixup dll names, PSF Runtime will make two attempts to load the dll, each made relative to the package root:

  1. First using the name exactly as it is given (e.g. "ContosoFixup.dll" in the example above)
  2. If that fails, then it appends the current architecture bitness (32 or 64) to the end of the dll name (e.g. "ContosoFixup64.dll" if the current process is a 64-bit process) and attempts to load that

This is done to support applications that contain both 32 and 64-bit executables, but need the same fixups applied to both. This is why all of the inbox fixups produce binaries named _____32.dll and _____64.dll by default. This naming convention also carries over to executables to prevent naming conflicts.

Please look here for more details -



"So in your example, the json.conf file would also have reference to the 32 and 64 bit fixup files, but tied to the different applications?"

@TIMOTHY_MANGAN Yes, we leverage the PSF behavior Vlad explained in his last post.


@Vladimir Postel Thanks, I submitted the issue on the feedback hub.