microsoft
UI Access is not supported for Desktop AppX processes
Describe the bug Cant use .MSIX packaging for WinUI3 Desktop apps that uses UIAccess. When launching the app an error "the request is not supported" pops up, and the app fails to launch.
The following error is observed in event viewer:
0x80070032: Cannot create the process for package fd6e7c45-f095-4b47-a46a-71657af65eae_1.0.0.0_x64__0dbdf1n3n58kt because UI Access is not supported for Desktop AppX processes. [LaunchProcess]
Steps to reproduce the bug
Steps to reproduce the behavior:
Package any Winui3 App with UIaccess = True
Install apps .msix
Run app
Error Occurs
Expected behavior it works
Version Info OS: Windows 11 Build 22489.1000
NuGet package version: WindowsAppSDK 0.1.0-prerelease3
| Windows version | Saw the problem? |
|---|---|
| Insider Build (xxxxx) | Yes |
| May 2020 Update (19041) | Yes |
| November 2019 Update (18363) | Yes |
| May 2019 Update (18362) | Yes |
| October 2018 Update (17763) | Yes |
Additional context
This is a major problem as it prevents apps that require UIaccess = True from using .MSIX packaging, commonly assistive technologies apps.
@jeffstall @jvintzel Is there any timeline for when this will be fixed?
Hi @riverar, Thanks for the suggestion, unfortunately that doesn't work either, still get the same UI Access is not supported for Desktop AppX processes error.
This is the list of capabilities I'm currently using.
<Capabilities>
<rescap:Capability Name="runFullTrust" />
<rescap:Capability Name="uiaccess" />
<rescap:Capability Name="allowElevation"/>
<rescap:Capability Name="uiAutomation"/>
</Capabilities>
The combination of runFullTrust and uiAccess (did you have a typo in your manifest?) is supposed to work. I will follow up on the msdn documentation which is erroneous in this area.
Assigning issue to jvintzel for further follow up.
@EHO-makai Thanks for the reply,
I have added a copy of the manifest I'm using below.
I have also tried adding UIaccess = True to a desktop bridge app published with MSIX and using rescap runFullTrust and uiAccess, but it still doesnt work.
I agree that the documentation for this needs improvements.
In addition to those capabilities in your appxmanifest.xml do you have a Fusion (aka SxS) manifest specifying
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
?
Here's the definitive link I'm aware of
This link mentions how the allowElevation capability is necessary but insufficient. That just says the manifest can declare activatable extension points that can run elevated; the capability doesn't guarantee there are any that will run elevated. You need both.
@DrusTheAxe, yes except mine says:
<requestedExecutionLevel level="asInvoker" uiAccess="true" />
As we don't need to run with elevated permission, just uiAccess
Just tried changing to <requestedExecutionLevel level="highestAvailable" uiAccess="true" /> , Problem persists
If you use uiAccess="true" in your fusion manifest, your app will need to be Authenticode signed and put into one of several trusted locations (e.g. system32, program files). (I don't believe that uiAccess mechanism got extended to the WindowsApps folder, hence @DrusTheAxe's false usage.)
Thanks for finding the root problem @riverar. I assumed that the Windows Apps folder would have been a trusted folder - more so than program files.
So I guess the problem still stands, msix doesn't support uiaccess = true, as you can't change the install location for msix distributed apps.
Actually, seems WindowsApps is okay (untested). From the docs:
The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are [...] %ProgramFiles% and its subdirectories.
What's not clear is the relationship of the fusion manfiest uiAccess=true and the appxmanifest uiAccess rescap. And the nebulous errors you're getting are the cherry on top.
Hope we get to the bottom of this and establish a working pattern for others!
@jeffstall @jvintzel @anarvekar-msft @DrusTheAxe is there any timeline for when this will be fixed? I'm surprised this isn't required internally.
@Samuel12321 something odd (or at least not widely understood) is going on. Please file a bug with FeedbackHub for further investigation.
In FeedbackHub under 2. Choose a category please specify Developer Platform > App deployment to ensure the key set of data is captured, and under 4. Add more details tap "Start recording", reproduce the issue, then complete the feedback and it'll report a bug with detailed logs.
+@timkur
@DrusTheAxe have filed the bug.
Bit concerned that this is the second time I have been told to report this elsewhere MSIX GitHub repo -> WASDK -> Feedback Hub
Bit concerned that this is the second time I have been told to report this elsewhere MSIX GitHub repo -> WASDK -> Feedback Hub
No need for concern. WASDK is more on point than MSIX GitHub repo, but it's unclear why there's a problem so more data's needed. FeedbackHub is a convenient and secure way to share detailed logs for analysis. Submitting via FeedbackHub keeps that data handled appropriately (GDPR etc). Don't think of FeedbackHub as reporting the problem to someone else, it's just a tool to share more data with the folks here.
Have no fear, you're in the right neighborhood for the issue.
@DrusTheAxe @timkur Just Thought i would add the link to the feedback Hub item https://aka.ms/AAf3d73 Let me know if you need anything else
As we don't need to run with elevated permission, just uiAccess
How come on earth your WinUI 3 or WinUI 3 Xaml Islands (when it's available) supposed to work with uiaccess=true when WinUI 3 itself doesn't yet support running Elevated !
Support running elevated across Win10 and Win11
Elevated/administrator isn't supported in MSIX WinAppSDK app on Windows 10
Dynamic Dependencies doesn't support Elevation
The app im trying to use this for ModernFlyouts, is a wpf desktop bridge app (with winui 2 xaml islands).
Steps to reproduce the behavior: Package any Winui3 App with UIaccess = True
your reproduce steps said full WinUI 3 app.
Also, WindowsAppSDK's AppWindow supports these UI Frameworks :: pure window Handle/raw Win32, MFC, WPF, WinForm and WinUI3. AFAIK, system XAML/WinUI 1 , WinUI2 or WinUI2 Xaml Islands is not one of them.
If possible Remove the WinUI2 Xaml Islands component and re check if the problem still persists.
I don't have a winui 2 island in a winui 3 app.
I created a normal basic winui 3 app to test and experiment with uiaccess = true, and this is what I discovered the bug with.
However what I actually want to apply this (uiaccess =true) to is a wpf desktop bridge app with winui 2 islands. And subsequent testing revealed that it doesn't work with this either.
Basically what I was trying to say in response to-winui3 doesn't support elevation, is that this bug isn't specific to winui3 and unrelated to elevation not supporting winui3.
Also having the same issue. Would like to know if winui 3 will ever support this?
Has there been any progress with fixing this? @DrusTheAxe @jeffstall @CLFPosthumus @kanismohammed-zz
Getting this problem trying to repackage SuperNova (magnification software) as an MSIX package for Azure Virtual Desktop. Are there any workarounds?
Due to this issue we are currently unable to MSIX SuperNova for Azure AVD. Is there any workaound or a fix available? Thanks
The ModernFlyouts team has been blocked by this for a while, there does not appear to be a workaround or a fix that i am aware of, and Microsoft doesn't seem interested in fixing this.
Due to this issue we are currently unable to MSIX SuperNova for Azure AVD. Is there any workaround or a fix available? Thanks
@cs302ss What type of app is SuperNova - uwp ?
@Samuel12321 "SuperNova (magnification software)" Here is the link to the vendor's site-- https://yourdolphin.com/en-gb/product/version/major?id=4 Regards