WinUI 3 app UI is displayed incorrectly in kiosk mode after the Win 11 update.

Liang, Ming 121 Reputation points
2026-09-11T00:58:15.2766667+00:00

we have a WinUI 3 application that runs in kiosk mode (implemented using shell launcher V2).

We found that when the app runs in kiosk mode on Win11 OS build (26100.8875), the app UI is displayed incorrectly, such as the small warning widow and welcome window now pop up full screen. The problem cannot reproduced when app run in non-kiosk mode. And this problem cannot be reproduced in kiosk mode on Win11 OS build (26100.7623)

could you tell me how to resolve this UI problem? thanks.

Win11 OS build (26100.8875) component list:

QFE Supplemental Pack - Windows 11 24H2 x64 26200.8875

Windows 11 LTSC 2024 - Base Image 26100.8875

Win11 OS build (26100.7623) component list:

QFE Supplemental Pack - Windows 11 24H2 x64 26200.7623

Windows 11 LTSC 2024 - Base Image 26100.6725

application is dependent on windowsdesktop-runtime-9.0.11-win-x64

Windows development | WinUI
0 comments
Answer accepted by question author
Gatlin Le (WICLOUD CORPORATION) 805 Reputation points Microsoft External Staff Moderator
2026-09-11T05:58:50.33+00:00

Hi @Liang, Ming ,

Thanks for the detailed report — the build comparison you included made this much easier to narrow down.

The first place I'd look is the V2:AllAppsFullScreen attribute on the element in your Shell Launcher v2 configuration. It controls whether every app window launches full screen, or only the custom shell app itself (configuration reference).

What makes this relevant is that in WinUI 3, every Microsoft.UI.Xaml.Window gets its own top-level HWND — there's a strict 1:1 mapping between an AppWindow and a top-level HWND (windowing overview). So, your warning and welcome windows aren't lightweight child dialogs; they're independent top-level windows, which puts them in scope for a shell-level full-screen policy. That would also fit with the behavior only showing up in kiosk mode.

To confirm, open the Shell Launcher XML you're deploying and check that attribute. If it's true, try flipping it to false and re-applying:

One thing to expect: your main window won't be sized by the shell anymore, so you'll want to handle it in code — apply a presenter to just the main window and leave the secondary ones on the default OverlappedPresenter, sizing them explicitly with AppWindow.Resize() (AppWindow APIs):

Worth knowing if you go that route: AppWindow uses physical device pixels while XAML layout uses effective pixels, so sizes won't map 1:1 on a high-DPI kiosk display — the relationship is physical = DIP × DPI / 96 (DPI background).

Longer term, if those windows were ContentDialog instances instead of separate Window objects, they'd render inside the main window's HWND rather than as top-level windows of their own (dialogs and flyouts) — more work than a config change, but worth having on your radar.

If flipping the attribute doesn't sort it out, two quick things would help: the element from your XML (feel free to redact account names or internal paths), and whether those windows are separate Window objects or already ContentDialog.

If you found my response helpful or informative, I would greatly appreciate it if you could share your thoughts by reacting to this answer or leaving a comment.

Thank you.

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Gatlin Le (WICLOUD CORPORATION) 805 Reputation points Microsoft External Staff Moderator
    2026-09-14T03:36:44.7466667+00:00

    Hi @Liang, Ming ,

    Thank you for taking the time to research the possible approaches and test them in your environment, and for sharing the result with the community.

    I cannot currently point you to a verified Microsoft fix or OS-level setting for this specific issue. This does not establish that none exists; it means I do not have a confirmed platform-level resolution to recommend. I would also treat the "Controller-First UX" explanation as an unconfirmed hypothesis rather than the established root cause. I could not find Microsoft documentation describing such a feature, and the "controller-first" terminology in Windows refers to the Xbox Full Screen Experience, an opt-in gamepad-oriented shell for handheld gaming devices enabled from Settings > Gaming > Full screen experience, which is not part of the Shell Launcher or kiosk stack.

    For the code-based approach that worked for you, I would suggest centralizing the working initialization logic in a shared helper or window-creation method instead of duplicating the implementation in every window class. Each affected secondary window would still need to go through that initialization, but the logic could be maintained in one place. This would reduce duplication; it would not replace the workaround with an OS-level fix.

    With your permission, I'd like to keep the summary below on this thread. It would be wonderful if someone facing the same problem could find the answer easily.

    The problem you were facing: Your WinUI 3 application runs in kiosk mode using Shell Launcher V2. On Windows 11 build 26100.8875, secondary windows, such as the warning and welcome windows, opened full screen instead of at their intended size. You reported that the issue did not occur outside kiosk mode or on build 26100.7623.

    The approach that worked: You confirmed that the first approach you shared worked in your environment: explicitly configuring the secondary window during initialization, including its presenter, size, and ownership, rather than relying on the default behavior in the kiosk session.

    The approach uses an OverlappedPresenter applied through AppWindow.SetPresenter(), together with an explicit window size through AppWindow.Resize() (windowing overview). One detail worth noting on a kiosk display: AppWindow works in physical device pixels while XAML layout works in effective pixels, so the values will not map 1:1 at high DPI. Your tested initialization can serve as the basis for the shared helper described above.

    If anything above doesn't match what you actually implemented, let me know and I'll correct it.

    Was this answer helpful?

  2. Liang, Ming 121 Reputation points
    2026-09-14T00:38:27.0733333+00:00

    Thanks , @Gatlin Le (WICLOUD CORPORATION)

    Here is the solutions provided by Google AI. And we tried the solution 1 and it worked.

    so if the root cause is "Controller-First UX", does Microsoft has a better solution for this problem. or do we have to sove this problem programmatically by changing code for every sub windows in our WinUI 3 application?
    User's image

    User's image

    User's image

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.