When a processes under the influence of the PSF starts a new process, this action is caught by the version of PsfRuntime in the calling process (CreateProcessHook). This code will create the new process as suspended, and then (attempt to) inject a fresh copy of PsfRuntime into the new process.
The current code (around lines 164-173 of the develop branch) uses psf::runtime_dll_name which returns the name assuming the bitness of the calling process. So if a 32-bit process is starting a 64-bit process that injection will fail (or visa versa). The result is that the new process never gets a chance to run.
This code will need to be updated. Probably best is to look at the bitness of the started process to select the correct name to use, but if not perhaps it can at least retry a different bitness upon error. PsfRundll.exe is also a possibility to consider, but I think that you'd still need to modify code to look at the bitness of the started process.
When a processes under the influence of the PSF starts a new process, this action is caught by the version of PsfRuntime in the calling process (CreateProcessHook). This code will create the new process as suspended, and then (attempt to) inject a fresh copy of PsfRuntime into the new process.
The current code (around lines 164-173 of the develop branch) uses psf::runtime_dll_name which returns the name assuming the bitness of the calling process. So if a 32-bit process is starting a 64-bit process that injection will fail (or visa versa). The result is that the new process never gets a chance to run.
This code will need to be updated. Probably best is to look at the bitness of the started process to select the correct name to use, but if not perhaps it can at least retry a different bitness upon error. PsfRundll.exe is also a possibility to consider, but I think that you'd still need to modify code to look at the bitness of the started process.