SOLVED

App is not lunching after installing from MSIX package

Copper Contributor

App is not lunching after installingit from MSIX package, but if I moved it out side windowsapp folder it works well. any idea how to fix it? 

6 Replies

Most likely your app crashes silently. i.e. it fails to read some config file/registry or to write some user data.

 

You can use the Package Support Framework to trace the crash and try to fix it. Here is an MS Ignite where I made a demo on this topic: https://youtu.be/f3Z7j1XEPgs?t=725

 

You can use the Advanced Installer Express edition., it's free and gives you the PSF integration shown in the video above.

 

p.s. I work on the team building Advanced Installer.

@Bogdan Mitrache I followed the Task manger and I can see the app runs for less than a minute then stops this happen If I started it from the start menu, but If I started it from the windowsapp folder it works well, any Idea? 

thanks 

Hi @mohamed96ashraf 

 

As I said above, you need to trace the app and see what is failing upon launch. The Task manager will not provide that info.

 

If you don't want to use the free Express edition from Advanced Installer you can try the leveraging the PsfTooling  built by @TIMOTHY MANGAN, along with the MSIX Packaging Tool.

@mohamed96ashraf 

 

Your situation is not that unusual, it is downright common!  In my testing, between 70-80% of traditional windows applications will have issues if just dropped into an MSIX container.  Many, but certainly not all, of the issues that occur with running traditional apps in the container can be mitigated.  We have the most experience with using the Package Support Framework to mitigate, and that is generally the first approach suggested.

 

If building the app as a developer, the approach is generally to either use the NuGet package and make configurations needed manually, or to use a third-party install builder that includes the PSF capabilities for you.  For example both AdvancedInstaller and InstallShield are known by me to have this built in; perhaps others do as well.

 

If repackaging, you can use the Microsoft MSIX Packaging tool in conjunction with the free PsfTooling app (as Bogdan indicated). Several third party vendors offer repackaging tools for MSIX as well, and most have PSF capabilities built into their tools.

 

No matter which approach is used to create the package, Bodgan hit it right on the head in the suggestion to add the PSF and include the TraceFixup (and PsfMonitor) as the first step.  This provides monitoring to show exactly what the app requests from the most important Windows API calls, and what was returned.  Knowing the cause helps to determine what fixup to apply, and then you can rebuild your final package using the appropriate fixups for that application.

 

@TIMOTHY MANGAN The app is working fine if I lunched it from its folder, but it is crashing only if i started it from the start menu. any idea? I already included all .dll files 

best response confirmed by Stefan Georgiev (Microsoft)
Solution

@mohamed96ashraf Possibly issue is working directory.  The original MSI/EXE based installer creates a shortcut which is interpreted by MSIX to add it to the start menu.  When it does this, any setting for the working directory is ignored, and even if it were not set explicitly in the lnk file, the default behavior was to use the folder of the target exe as the working directory of the new process.  If you manually launch you'd also get the exe folder to be the working directory.  But under MSIX, the working directory is set to the System32 folder.

 

PsfLauncher may be used to solve this.  With PsfLauncher as the target of the shortcut, it doens't care about the working directory and will use a setting in the config.json file to set the working directory of the ultimate target process.  PsfTooling may be used when repackaging to add PsfLauncher and solve this.

1 best response

Accepted Solutions
best response confirmed by Stefan Georgiev (Microsoft)
Solution

@mohamed96ashraf Possibly issue is working directory.  The original MSI/EXE based installer creates a shortcut which is interpreted by MSIX to add it to the start menu.  When it does this, any setting for the working directory is ignored, and even if it were not set explicitly in the lnk file, the default behavior was to use the folder of the target exe as the working directory of the new process.  If you manually launch you'd also get the exe folder to be the working directory.  But under MSIX, the working directory is set to the System32 folder.

 

PsfLauncher may be used to solve this.  With PsfLauncher as the target of the shortcut, it doens't care about the working directory and will use a setting in the config.json file to set the working directory of the ultimate target process.  PsfTooling may be used when repackaging to add PsfLauncher and solve this.

View solution in original post