UI Access is not supported for Desktop AppX processes

[Samuel12321]

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.

[Samuel12321]

@jeffstall @jvintzel Is there any timeline for when this will be fixed?

[riverar]

Does the uiAutomation rescap help at all here?

[Samuel12321]

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>

[EHO-makai]

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.

[Samuel12321]

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

Manifest.txt

[DrusTheAxe]

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.

[Samuel12321]

@DrusTheAxe, yes except mine says: <requestedExecutionLevel level="asInvoker" uiAccess="true" /> As we don't need to run with elevated permission, just uiAccess

[Samuel12321]

Just tried changing to <requestedExecutionLevel level="highestAvailable" uiAccess="true" /> , Problem persists

[riverar]

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

[Samuel12321]

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.

[riverar]

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!

[Samuel12321]

@jeffstall @jvintzel @anarvekar-msft @DrusTheAxe is there any timeline for when this will be fixed? I'm surprised this isn't required internally.

[DrusTheAxe]

@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

[Samuel12321]

@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

[DrusTheAxe]

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.

[Samuel12321]

https://github.com/microsoft/microsoft-ui-xaml/issues/6331

[Samuel12321]

@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

[ghost]

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

[Samuel12321]

The app im trying to use this for ModernFlyouts, is a wpf desktop bridge app (with winui 2 xaml islands).

[ghost]

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.

[Samuel12321]

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.

[Samuel12321]

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.

[Samuel12321]

Has there been any progress with fixing this?

[CLFPosthumus]

Also having the same issue. Would like to know if winui 3 will ever support this?

[Samuel12321]

Has there been any progress with fixing this? @DrusTheAxe @jeffstall @CLFPosthumus @kanismohammed-zz

[ChrisTav424]

Getting this problem trying to repackage SuperNova (magnification software) as an MSIX package for Azure Virtual Desktop. Are there any workarounds?

[cs302ss]

Due to this issue we are currently unable to MSIX SuperNova for Azure AVD. Is there any workaound or a fix available? Thanks

[Samuel12321]

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.

[Samuel12321]

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 ?

[cs302ss]

@Samuel12321 "SuperNova (magnification software)" Here is the link to the vendor's site-- https://yourdolphin.com/en-gb/product/version/major?id=4 Regards

[davetustin]

We are trying to do the same and use MSIX for distributing SuperNova in AVD. We are encountering the same problem.

[christopher-rtf]

We are also building accessibility software, and we are unable to ship via MSIX due to this outstanding issue.

Is there anything we can do to help resolve this (e.g. pitch in on some code)?

[riverar]

@jonwis @DrusTheAxe Is this on the roadmap for the next release by any chance? cc: @dotmorten for awareness

[DrusTheAxe]

@jonwis @DrusTheAxe Is this on the roadmap for the next release by any chance? cc: @dotMorten for awareness

@MikeHillberg @bpulliam Tag you're it

[TimMangan]

Providing additional ideas for those struggling with this...

While there may be many issues preventing this from working, consider this. UIAccess=true is supposed to work without elevation if the exe with that manifest is located in a "well-known location", which includes "C:\Program Files" and sub-directories.

Many think of "C:\Program Files\WindowsApps" as a subdirectory for this purpose, but I believe that it is not. WindowsApps is a NAMESPACE that is mapped (my word) to this place. Thus an internal manifest with AsInvoker and UIAccess=true still causes a UAC prompt.

But even when approved by the end-user, things still go bad and the application launch via CreateProcess fails with 0x10dd, an error code that makes no sense to me. This is with the package capabilities listed with runFullTrust, uiAccess, uiAutomation, and allowElevation.

Placing the exe in the package under VFS\ProgramFilesX64 and starting the package using a native path (a technique that works with App-V) also does not work, although the symptoms appear differently.

[riverar]

I can't reproduce this on Windows 11 25915 rs_prerelease (Canary) / Windows App SDK 1.3.230502000. @Samuel12321 can you still reproduce this issue?

[riverar]

If I fusion manifest the app with uiAccess=true, it produces the following events on deploy (unsigned msix):

Microsoft-Windows-AppXDeploymentServer/Operational

Failed to set the Trust Label on package 34060d07-2249-491b-853e-84e888561736_1.0.0.0_x86__30zg041h3evk2
with flags 0x0. Error: 0x80073CFC.

Deployment Register operation with target volume C: on
Package 34060d07-2249-491b-853e-84e888561736_1.0.0.0_x86__30zg041h3evk2 from:  (AppxManifest.xml)
failed with error 0x80073CF6. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app
deployment issues.

AppX Deployment operation failed for package
34060d07-2249-491b-853e-84e888561736_1.0.0.0_x86__30zg041h3evk2 with error 0x80073CF6.
The specific error text for this failure is: error 0x80070005: While preparing to process the request, the system
failed to register the windows.uiAccess extension due to the following error: Access is denied.
.

Opinion: Doesn't seem like CentennialUiAccess (https://task.ms/19447269, added 3 years or so ago) works properly. Or there's some magic undocumented incantation needed here. Or perhaps there was no testing done with non-Microsoft signed PEs.

[Samuel12321]

@jonwis @DrusTheAxe @dotMorten @MikeHillberg @bpulliam Any Progress on this, its now been 2 years?

[tibitoth]

I've just run into this problem. So there is not any workaround to use UIAccess from a WinUI app with MSIX deployed? What are the alternatives to achieve TopMost with UIAccess?

I would like to draw over start menu.