Forum Discussion
MSIX Breakaway in 22h2+ (win 10 + 11)
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...
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?
- 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.- 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?- 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)
- 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.
