MSIX Breakaway in 22h2+ (win 10 + 11)

[mattplan8]

I've been packaging in MSIX for a while now, but recently find myself troubleshooting more and more applications with child processes that are executing outside the msix container.

I haven't been able to find anything in the xml reference that controls the behavior, but it would certainly be nice if it could be added to the app manifest.

the examples are pretty niche to the industry, but symphony chat is a good example.  They have a screen snipping tool that executes as a separate exe.  by default it doesn't work, if run via invoke-commandindesktoppackage with -preventbreakaway, it works as expected.

My workaround has been to make wrapper exe's and use psf to launch the wrapper (which subsequently is just a compiled powershell with invoke-commandindesktoppackage)

I'd like a proper solution though, if MS reads this :D

Tim M you probably will, so if you know of a more elegant solution let me know.

[#2]

Worth requesting it here?
https://techcommunity.microsoft.com/t5/msix-feedback/idb-p/MSIXIdeas

[#3]

added it here!
https://techcommunity.microsoft.com/t5/msix-feedback/configurable-breakaway-for-msix-packages-in-app...

[#4]

Upvoted it for you!

[#5]

@mattplan8 

I'm unclear about parts of the scenario.  Specifically, about what executables are inside or outside of the package, or packages.  Can you be more detailed?

[#6]

Linqpad is another example (although more steps to reproduce the issue).

Basically, everything is in the package, but some of the "child" apps are just tools executed from controls within the main application, the child apps aren't in the app manifest (maybe I should try manually adding them). In the symphony example, if you launch Symphony and sign in there is a button to take a screen shot and attach it to chat. When clicked that button launches screen_snipper.exe. By default that screen_snipper.exe is launching outside of the container, then can't find any of the dll's that are part of the container, and fails. When you explicitly tell the package to prevent breakaway, then it works and launches within the container.

Hope that's sufficient information.

[#7]

Child processes for executables in the same package should, by default, start inside the container (unless you are on a Windows 10 release so old that it is out of support anyway). So your issue is rather unique; possibly having to do with how the app starts the child or possibly due to use of the PSF. The PSF shouldn't cause this, but there are known issues with the Microsoft branch in this area.

If the PSF is in use, DebugView should expose what is happening on the child launch. Otherwise, possibly Process Monitor would be needed to understand why this is happening for your package.

[#8]

@mattplan8

I have the same issue with apps calling Word or Excel outside the container while they should start inside. So I reverted those back to App-V. Can you tell me how your workaround works? How would I prevent breakaway of these apps?

Do you mean you just launch the main app with the command invoke-commandindesktoppackage -preventbreakaway? And then all child processes will launch within the container?

[#9]

Just for clarity I've tested on win 10 21h2 and win 11 22h2 and the behavior is the same (at least for these applications) I have actually never been able to confirm the behavior I've seen Tim write about (that it's native behavior is to stay within the container). This also happens without psf, I normally end up using psf because of first time run scripts or simlar, but I've never had a scenario where the file fixup has really accomplished what I was hoping for, or in more recent packages I just used ILV and i found it more reliable.

To test whether my work around will work for you Martijnk79 try the following:
add the package to your user:
add-apppackage [pathtomsix]

then use the powershell commandlet:
Invoke-CommandInDesktopPackage -packagefamilyname [packagefamilyname] -appid [the app id as it appears in the AppManifest.xml] -command cmd -preventbreakaway

an example might be:
Invoke-CommandInDesktopPackage -PackageFamilyName Microsoft.MicrosoftEdge.Stable_8wekyb3d8bbwe -appid MSEDGE -command cmd -preventbreakaway

I made up the appid in the above example, it's probably not correct, but you can find the appid in your app manifest, a common mistake is to think it's the App name from get-apppackage, it is not (althought they sometimes are the same value).

If from that command window you can launch your application, and functions that launch child processes function correctly, you are in my boat. Welcome, there's plenty of room :).

To work around it, I made a wrapper script, example:
$packagefamily = "Linqpad7_1468n5jdfjaw"
$appid= "LINQPADSevenXEightSix"
$name = "Linqpad7"
$app = get-apppackage $name
Invoke-CommandInDesktopPackage -PackageFamilyName $packageFamily -appid $appid -command "$($app.InstallLocation)\VFS\ProgramFilesx64\LINQPAD7\LINQpad7-x86.exe" -PreventBreakaway

Adjust the variables to suit your package of course. No need for updates version after version as long as the basic path stays the same.

Then I use P2EXE to convert to a EXE, sign it to make my security team happy, and pop it in the package and replace the default exe in the app manifest with the compiled script from above (or if I'm using psf for a startup script, I leave that and edit the config.json to launch my wrapper)

[#10]

@mattplan8 

Thanks for the extended writeup!

Unfortunately, it still doesn't work for me. My application is Microsoft Navision and it calls Excel or Word from a couple of buttons in the toolbar. I have no control to what those buttons do, or how they call the Office apps.

But with your method, launching Navision with the -PreventBreakway doesn't change anything. The entire application just crashes when I launch Word/Excel from the MSIX app (Excel/Word never launch) and I get an error in the application log. With App-V or local install, it all just works fine (btw I'm using Win11 multisession but I get the same behavior with Windows Server 2019).

You would assume that any child process within your MSIX container will be launched within the container, just like App-V used to handle it. I see no reason why to launch it outside of it. Then again, I might have a totally different problem with this app. But all Navision apps, all versions behave exactly the same when ran from MSIX.

I also tried to pre-launch Excel from the container using your same command, so Excel is already open from within the container and it should be using that window. But still, same result. The app just crashes with no specific error message.

I will do some other testing as well with other apps that open child processes, see if they work with your workaround. Because it might just be Navision acting up. So thanks again for this post, very helpful!

Faulting application name: finsql.exe, version: 5.0.26084.0, time stamp: 0x47b39d56
Faulting module name: finsql.exe, version: 5.0.26084.0, time stamp: 0x47b39d56
Exception code: 0xc0000005
Fault offset: 0x001e85cf
Faulting process id: 0x2ca8
Faulting application start time: 0x01da2d00e342d297
Faulting application path: C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\finsql.exe
Faulting module path: C:\Program Files (x86)\Microsoft Dynamics NAV\CSIDE Client\finsql.exe
Report Id: dd24e03c-992a-44a8-b4b8-836deb47bf46
Faulting package full name: FRF-P_4.0.0.0_x64__rt6ps99bwbnfa
Faulting package-relative application ID: FRF