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

Liang, Ming 101 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 No comments

1 answer

Sort by: Newest
  1. Gatlin Le (WICLOUD CORPORATION) 160 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?

    0 comments No 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.