Forum Discussion

nathan-pieces's avatar
nathan-pieces
Copper Contributor
Feb 14, 2022
Solved

An unhandled win32 exception occurred in PsfLauncher64.exe

Hello, and thanks for any help in advance.

I have a UWP application that I want to package with the Package Support Framework. All I want to do is run a simple PowerShell script upon installation of my package, however, I cannot seem to get Visual Studio to package it all together correctly. 

I have followed this guide: 
https://docs.microsoft.com/en-us/windows/msix/psf/package-support-framework-vs

I keep running into the same error trying to get the WAP solution to build: 
"An unhandled win32 exception occurred in PsfLauncher64.exe"

The only thing different I am doing is I do not have a runtime fix project, as I do not need one. I just want to run a PowerShell script. 

I cannot figure out what I am doing wrong, or not doing at all. 

As a workaround, I have attempted to configure my UWP application to package itself with the Package Support Framework. Essentially, configuring the Package.manifest to target the PsfLauncher64.exe, and bundling all the appropriate files together in the MSIX package when I hit "Publish" by right clicking my UWP project. That almost worked, as it it runs the script I have provided, but fails to launch my UWP application afterwards. All I can see in Event Viewer is an Error with the title "Event 1000, Application Error" with no other context as to why it fails to launch. 

I feel like I am very close to achieving my goal, but I am missing something. I'd like to do it the "correct way", from the information provided in the article using a Blank project for the PSF installed through NuGet, and a WAP project that targets the Blank project as it's entry point. 

My config.json looks like this:

{
  "processes": [
    {
      "executable": ".*App.*",
      "fixups": []
    }
  ],
  "applications": [
    {
      "id": "MyAppId",
      "executable": "MyApp.App",
      "startScript": {
        "scriptExecutionMode": "-ExecutionPolicy RemoteSigned",
        "scriptPath": "pre_install.ps1",
        "showWindow": false,
        "runInVirtualEnvironment": false,
        "waitForScriptToFinish": true
      }
    }
  ]
}


I have also included StartingScriptWrapper.ps1 in the WAP project as well.

Again, thanks for any help on this. It is slowly driving me crazy.


  • 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.

4 Replies

  • Not sure where to start on this, so let's cover some basics first.

    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.)
    • nathan-pieces's avatar
      nathan-pieces
      Copper Contributor

      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!

      • TIMOTHY_MANGAN's avatar
        TIMOTHY_MANGAN
        MVP

        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.

Resources