Forum Discussion
An unhandled win32 exception occurred in PsfLauncher64.exe
nathan-pieces A quick look indicates that you are mixing your fruits.
The PSF can only work when the manifest Application entry has the EntryPoint="windows.FullTrustAppliccation". The executable on that line will be a copy of the PsfLauncherXxx.exe.
PsfLauncher can run the script that you have and then run the target application. However, the form of that target application exe cannot be an exe built as a UWP app. It must be a Win32, .Net Framework, or Windows App SDK based executable.
I'm thinking that you really should be looking at first porting the UWP to the Windows App SDK. The simple UWP app you have there should be a piece of cake. So you should be able to succeed with porting and getting the result you want. Assuming that this is proof of concept, porting your real UWP app might be more challenging depending on what is in it.
If you want your app to use the PSF, it MUST be flagged in the AppXManifest Capabilities for full trust, as well as the Application entry.
If you intend to use PsfLauncherX**.exe you MUST include the appropriate bitness(es) of PsfRuntimeX**.dll.
If there are mixed bitness apps (or concerned that a customer might have a GPO to force an AnyCpu to run 32-bit on an x64 system), you always include both versions of any Psf Dlls in the package, along with both bitesses of PsfRunDllXX.exe
The fields named in the applications section of the json needs to match up with the name of the AppID of the manifest Application record, which normally means the executable is along the line of PsfLauncherXxx.exe. Also note that fields are often Regex (Ecma/Javasript( syntax and not normal windows wildcarding. (Not that I see a problem above, but often folks fail to realize this.)
TIMOTHY_MANGAN
Thank you for taking your time to answer my questions.
I have solved the issue of PsfLauncher64.exe throwing exceptions during debugging. The issue was mismatched AppIDs that I had in my Package.appxmanifest for my WAP project and my config.json.
Although this is now resolved, I still have an issue with my UWP app launching afterwards. I can get my script to run on installation if I run the WAP project in a debug configuration, but cannot get the actual UWP app to launch. It essentially throws the same error as before but it is my app executable that is now throwing the error now. I have tinkered around with everything you have mentioned but sadly cannot figure it out.
I even tried your PSFtooling application!
If you care to look at some source code, I have created a barebones solution that you are welcome to check out https://github.com/nathan-courtney/PSF_UWP_TEST.
I will keep trying different things! I am determined!nathan-pieces A quick look indicates that you are mixing your fruits.
The PSF can only work when the manifest Application entry has the EntryPoint="windows.FullTrustAppliccation". The executable on that line will be a copy of the PsfLauncherXxx.exe.
PsfLauncher can run the script that you have and then run the target application. However, the form of that target application exe cannot be an exe built as a UWP app. It must be a Win32, .Net Framework, or Windows App SDK based executable.
I'm thinking that you really should be looking at first porting the UWP to the Windows App SDK. The simple UWP app you have there should be a piece of cake. So you should be able to succeed with porting and getting the result you want. Assuming that this is proof of concept, porting your real UWP app might be more challenging depending on what is in it.
TIMOTHY_MANGAN
I was afraid that the UWP exe might be incompatible with PSF. I will definitely be looking into porting my UWP application in the future.
I appreciate your help, I probably would have kept on trying to get it working without knowing that I was going down an impossible path.
