PSF Launcher

The PSF Launcher acts as a wrapper for the application, it injects the psfRuntime to the application process and then activates it. To configure it, change the entry point of the app in the AppxManifest.xml and add a new config.json file to the package as shown below;
Based on the manifest's application ID, the psfLauncher looks for the app's launch configuration in the config.json. The config.json can specify multiple application configurations via the applications array. Each element maps the unique app ID to an executable which the psfLauncher will activate, using the Detours library to inject the psfRuntime library into the app process. The app element must include the app executable. It may optionally include a custom working directory, which otherwise defaults to Windows\System32.

PSF Launcher also supports running an additional "monitor" app, intended for PsfMonitor. You use PsfMonitor to view the output in conjuction with TraceFixup injection configured to output to events.

Configuration

PSF Launcher uses a config.json file to configure the behavior.

Given an application package with an AppxManifest.xml file containing the following:

<Package ...>
  ...
  <Applications>
    <Application Id="PrimaryApp"
                 Executable="PrimaryApp.exe"
                 EntryPoint="Windows.FullTrustApplication">
      ...
    </Application>
  <Applications>
    <Application Id="PSFSample"
                 Executable="PSFLauncher64.exe"
                 EntryPoint="Windows.FullTrustApplication">
      ...
    </Application>
  </Applications>
</Package>

A possible config.json example would be:

{
	"applications": [
	{
		"id": "PSFLAUNCHERSixFour",
      		"executable": "PrimaryApp.exe",
      		"workingDirectory": "",
      		"monitor": {
			"executable": "PsfMonitor.exe",
			"arguments": "",
			"asadmin": true,
        		"wait": false
      		}
    	}
  	],
	"processes": [
	{
		"executable": ".*PrimaryApp.*",
		"shims": [ 
		{ 
			"dll": "TraceFixup64.dll",
			"config": {
					"traceMethod": "eventlog",
					"traceLevels": {
						"default": "always"
					}
			}
		} 
	        ]
    	}
  	]
}

In this example, the configuration is directing the PsfLauncher to start PsfMonitor and then the referenced Primary App. PsfMonitor to be run using RunAs, followed by PrimaryApp once the monitoring app is stable. The root folder of the package is for the CurrentDirectory. In the processes section of the example, the json further configures Trace Fixup to be injected into the Primary app, and that is to capture all levels of trace to the event log.

Array	Key	Value
applications	id	Use the value of the Id attribute of the Application element in the package manifest.
applications	executable	The package-relative path to the executable that you want to start. In most cases, you can get this value from your package manifest file before you modify it. It's the value of the Executable attribute of the Application element.
applications	workingDirectory	(Optional) A package-relative path to use as the working directory of the application that starts. If you don't set this value, the operating system uses the System32 directory as the application's working directory. If you supply a value in the form of an empty string, it will use the directory of the referenced executable.
applications	monitor	(Optional) If present, the monitor identifies a secondary program that is to be launched prior to starting the primary application. A good example might be PsfMonitor.exe. The monitor configuration is further explained below.
processes	executable	In most cases, this will be the name of the executable configured above with the path and file extension removed.
fixups	dll	Package-relative path to the fixup, .msix/.appx to load.
fixups	config	(Optional) Controls how the fixup dl behaves. The exact format of this value varies on a fixup-by-fixup basis as each fixup can interpret this "blob" as it wants.

The applications, processes, and fixups keys are arrays. That means that you can use the config.json file to specify more than one application, process, and fixup DLL.

The optional monitor item has a further configuration consists of the following items:

Key	Value
'executable'	The name of the executable relative to the root of the package.
'arguments'	A string containing any command line arguments that the monitor executable requires.
'asadmin'	A boolean (0 or 1) indicating if the executable needs to be launched as an admin. To use this option you must mark the package with the RunAsAdministrator capability. If the monitor executable has a manifest (internal or external) it is ignored. If not expressed, this defaults to a 0.
'wait'	A boolean (0 or 1) indicating if the launcher should wait for the monitor program to exit prior to starting the primary application. When not set, the launcher will WaitForInputIdle on the monitor before launching the primary application. This option is not normally used and defaults to 0.