WinUI 3 full screen window is not correctly displayed in kiosk mode after Win11 update.

Question

WinUI 3 full screen window is not correctly displayed in kiosk mode after Win11 update.

Liang, Ming 121

Here is an UI issue of our WinUI 3 application after we updated Win11 OS( Win 11 IoT LTSC Enterprise ) from "Win 11 OS build (26100.7623)" to "Win 11 OS build (26100.8875)":

The full screen config window is not correctly displayed in kiosk mode. The window now has a extra caption bar that will enable user to adjust the size of the window.

This UI problem cannot reproduced in non-kiosk mode in Win 11 OS build (26100.8875),

This UI problem cannot reproduced in Win10.

This UI problem cannot reproduced in Win 11 OS build (26100.7623).

What is the root cause of this problem and any solution to fix it programatically ? Thanks.

Wrong Window UI:

User's image

Expected Window UI:

User's image

0 comments

2 answers

Your answer

Answer 1

Gatlin Le (WICLOUD CORPORATION) 560 Microsoft External Staff Moderator

Hi @Liang, Ming ,

The extra Windows caption bar is visible above your application's own header. The build comparison narrows the investigation to the kiosk scenario, but it does not yet establish the root cause or a confirmed Windows fix.

One important distinction is that Shell Launcher's V2:AllAppsFullScreen="true" setting controls whether applications are executed in full screen. This shell-level behavior should not automatically be treated as equivalent to explicitly selecting WinUI's borderless full-screen presenter. Microsoft documents FullScreenPresenter as configuring a window without a border or title bar and hiding the system taskbar. See the Shell Launcher configuration reference and AppWindow documentation.

As a focused test on a test device, apply the full-screen presenter explicitly to the affected configuration window using its existing AppWindow instance:

appWindow.SetPresenter(
    Microsoft.UI.Windowing.AppWindowPresenterKind.FullScreen);

This is the documented programmatic approach to requesting full-screen presentation, rather than maximizing or resizing the window. It is not a verified fix for build 26100.8875.

As a timing test, try making the call immediately after activating the window and record appWindow.Presenter.Kind immediately before and after the call, and again if the caption appears:

If the caption disappears and stays hidden, explicit full-screen presentation may be a usable workaround in your environment.
If the presenter later becomes Overlapped, the next step is to identify what changes the window's presentation.
If it remains FullScreen while the extra caption is visible, please report that result rather than repeatedly reapplying the presenter.

Please share the affected window's creation/activation code, your Windows App SDK version, and the current Shell Launcher <Shell> entry, including V2:AppType and V2:AllAppsFullScreen. Also clarify whether this configuration window is the shell's startup window or another window opened by the application. Remove sensitive paths, account details, and identifiers before posting.

Separately, the Wrong UI screenshot contains a resource card below the filters that is absent from the expected screenshot. Is that resource card unexpected when using the same application data and settings, or were the screenshots taken in different states?

The initialization code and presenter values will help distinguish a presentation-state change from a caption issue occurring while full-screen presentation remains selected.

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.

Gatlin Le (WICLOUD CORPORATION) 560 Reputation points Microsoft External Staff Moderator

2026-09-22T04:37:31.63+00:00

Hi @Liang, Ming ,

I’ve shared an answer. Did you get a chance to look at it? If you have any questions, just drop a comment and I’ll try my best to help.

Thank you.

Liang, Ming 121

Here is the shell launcher configuration file, is there anything might cause the problem in it?

<?xml version="1.0" encoding="utf-8"?>
<ShellLauncherConfiguration xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration" xmlns:v2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
<Profiles>
<DefaultProfile>
<Shell Shell="C:\Program Files\DD\DD Shell\DDShell.exe"><DefaultAction Action="RestartShell"/>
</Shell>
</DefaultProfile>
</Profiles>
<Configs/>
</ShellLauncherConfiguration>

Liang, Ming 121 Reputation points

2026-09-22T23:17:01.7766667+00:00

I like to mention a similar issue. below is the code of File Picker window used in our application,

After we updated Win11 OS( Win 11 IoT LTSC Enterprise ) from "Win 11 OS build (26100.7623)" to "Win 11 OS build (26100.8875)", the file picker window will be displayed full screen in both kiosk mode and non-kiosk mode.
Gatlin Le (WICLOUD CORPORATION) 560 Reputation points Microsoft External Staff Moderator

2026-09-23T03:17:41.7266667+00:00
Hi @Liang, Ming ,

Thank you for sharing the configuration and the file-picker code. Your XML does not set v2:AllAppsFullScreen="true". Since the picker also fills the screen outside kiosk mode, I would investigate its behavior separately from the kiosk-only caption issue for now.

Regarding the Shell Launcher configuration

To clarify my earlier answer, AllAppsFullScreen="true" was a setting to check, not something confirmed in your configuration. Declaring the v2 namespace does not enable that setting.

Microsoft documents that when AllAppsFullScreen is omitted or false, only the custom shell application runs full screen, while other applications launched by the user run windowed (Shell Launcher configuration). This describes application-level behavior, rather than guaranteeing how individual dialogs within the shell process are presented.

The DefaultProfile with an empty <Configs/> is also a documented configuration pattern. RestartShell controls what happens when the shell exits, rather than window sizing. I would therefore leave the XML unchanged for the next test.

About the File-picker code

Your helper calls the native GetOpenFileName API. My earlier AppWindow.SetPresenter suggestion applies to your WinUI configuration window, not directly to this native file dialog.

One detail worth testing is that hwndOwner is declared but never assigned. Windows permits a dialog without an owner (OPENFILENAMEW structure), so this is not a confirmed cause of the behavior after the update. However, associating the picker with the window that opens it provides a focused comparison.

On a test device:

Add IntPtr ownerHwnd as the first parameter of your existing ShowDialog method.

Assign it when initializing the structure, keeping the remaining code unchanged for this test:
var ofn = new OpenFileName(); ofn.lStructSize = Marshal.SizeOf(ofn); ofn.hwndOwner = ownerHwnd;

Call the helper from the owning WinUI window's UI thread, retrieving the handle as described in Retrieve a window handle (HWND):
IntPtr ownerHwnd = WinRT.Interop.WindowNative.GetWindowHandle(this); string filename = FilePicker.ShowDialog( ownerHwnd, @"C:\", new[] { "png", "jpeg", "jpg" }, "Image Files", "Select an image");

Here, this must be the existing Microsoft.UI.Xaml.Window. If the handler is in a page, use a reference to its hosting window instead.

Compare the picker's size in kiosk and non-kiosk sessions on build 26100.8875. This is a diagnostic test, not a verified workaround.

There is also a separate filter-format issue in the code you shared. After recording the ownership-test result, replace the existing filter assignment and filter-building loop with the following for your image-file example:

ofn.lpstrFilter = "Image Files\0*.png;*.jpeg;*.jpg\0\0"; ofn.nFilterIndex = 1;

This supplies the required description/pattern pair with semicolon-separated extensions. It corrects the filter format, not the full-screen behavior.

For the troubleshooting

Could you please share:

Whether assigning the owner changes the picker's size in either session.

Whether the configuration window's extra caption appears before opening the picker or only afterward.

For the original caption issue, the AppWindow.Presenter.Kind value while the caption is visible and your Windows App SDK version.

I cannot yet confirm whether the two symptoms share a root cause. The results above will tell me whether to focus next on dialog ownership, the configuration window's presentation state, or a minimal reproduction across the two builds.
Gatlin Le (WICLOUD CORPORATION) 560 Reputation points Microsoft External Staff Moderator

2026-09-25T03:06:00.93+00:00

Hi @Liang, Ming ,

Just checking in on the troubleshooting steps I shared. When convenient, please let me know what you observed after assigning the file picker an owner window. If the configuration window’s caption bar is still appearing, its AppWindow.Presenter.Kind value at that point would also help narrow down the original issue.
Liang, Ming 121 Reputation points

2026-09-28T06:36:50.65+00:00
@Gatlin Le (WICLOUD CORPORATION)

Here is the google AI's answer to this problem:

I tried the Remedy 1 and 2, neither of them worked.

The problem is caused by a regression in the Windows shell windowing manager introduced in Windows 11 build 26100.8875. [1]

Root Cause

In WinUI 3, every Microsoft.UI.Xaml.Window maps directly to its own top-level system HWND. When a kiosk configuration executes under modern Windows 11 Enterprise LTSC shells (such as Shell Launcher V2 or Assigned Access), the system shell attempts to enforce visual boundaries. [1, 2]

Due to the update behavior in build 26100.8875, the OS shell overrides or fails to honor the initial programmatic borderless request (AppWindowPresenterKind.FullScreen) during the kiosk layout initialization sequence. As a result, the window state drops back to a default Overlapped style with the system caption and title bars visible. [1, 3]

Programmatic Workarounds

Because the OS resets or ignores the presenter style during structural layout generation, you must enforce the full-screen presenter using explicit asynchronous delays or event-driven enforcement.

Remedy 1: Delayed Re-application on Window Activation (Recommended)

Force the window manager to re-evaluate the full-screen layout immediately after the window fully launches and activates within the Kiosk space.

using Microsoft.UI.Windowing;using Microsoft.UI.Xaml;using System;using System.Threading.Tasks; // In your Window code-behind (e.g., MainWindow.xaml.cs)public sealed partial class MainWindow : Window { public MainWindow() { this.InitializeComponent(); // Listen to the Activated event to trap shell overridesthis.Activated += MainWindow_Activated; } private async void MainWindow_Activated(object sender, WindowActivatedEventArgs args) { if (args.WindowActivationState != WindowActivationState.Deactivated) { // Unregister to prevent looping on intentional focus changes this.Activated -= MainWindow_Activated; // Yield control back to the UI thread briefly to ensure the OS // shell finishes its initial presentation pass await Task.Delay(150); ExecuteEnforcedFullScreen(); } } private void ExecuteEnforcedFullScreen() { AppWindow appWindow = this.AppWindow; if (appWindow != null && appWindow.Presenter.Kind != AppWindowPresenterKind.FullScreen) { // Re-apply the programmatic borderless fullscreen presenter appWindow.SetPresenter(AppWindowPresenterKind.FullScreen); } } }

Remedy 2: Listen for Presenter Changes

If the OS asynchronously modifies the window state mid-session, subscribe to the Changed event of the AppWindow to dynamically lock it down: [3]

public MainWindow() { this.InitializeComponent(); this.AppWindow.Changed += AppWindow_Changed; } private void AppWindow_Changed(AppWindow sender, AppWindowChangedEventArgs args) { // Check if the presenter configuration changedif (args.DidPresenterChange) { if (sender.Presenter.Kind != AppWindowPresenterKind.FullScreen) { // Block the OS from degrading it to AppWindowPresenterKind.Overlapped sender.SetPresenter(AppWindowPresenterKind.FullScreen); } } }

Shell Configuration Triage (If using Shell Launcher V2)

If you deploy your kiosk environment using a ShellLauncher configuration XML script, ensure the global full-screen attribute is disabled for independent components: [2]

Locate the tag <V2:AllAppsFullScreen="true">.

Flip this value to false.

Setting this to false stops the OS shell from dynamically forcing random layout overrides onto separate WinUI top-level window elements, giving your C# AppWindow code complete authorization over window sizing. [1, 2]

To ensure this implementation fixes the layout, please verify:

Are you using Shell Launcher V2 or Assigned Access to build this kiosk environment?

Do you have secondary dialog windows or flyouts spawning alongside the core configurator interface?

[1] https://learn.microsoft.com

[2] https://learn.microsoft.com

[3] https://learn.microsoft.com
Gatlin Le (WICLOUD CORPORATION) 560 Reputation points Microsoft External Staff Moderator

2026-09-28T07:57:14.3+00:00

Hi @Liang, Ming ,

Thank you for confirming that neither Remedy 1 nor Remedy 2 worked.

As Thomas shared, his log shows Presenter.Kind changing from FullScreen to Overlapped after Activate() is called. He reported that queuing another SetPresenter(AppWindowPresenterKind.FullScreen) call through the window's DispatcherQueue immediately after Activate() returned restored fullscreen and removed the caption in his kiosk session.

This is a reported workaround, not a confirmed fix for your environment. Thomas reported similar symptoms on an earlier build, 26100.8737, but that does not establish when the issue began or whether both environments share the same cause.

This still relies on reapplying fullscreen, so I cannot assume it will behave differently from the remedies you already tested. The key difference worth comparing is when the presenter is reapplied: directly after Activate() through the affected window's DispatcherQueue, rather than through a delayed Activated handler or a Changed handler.

If you have not tested this exact sequence, could you try it on a test device where the affected configuration window currently calls Activate(), using that window's own DispatcherQueue and AppWindow? Temporarily disable only the two earlier presenter-reapplication handlers for this comparison. Please do not add another Activate() call inside an activation or change handler.

Please record Presenter.Kind immediately before and after Activate(), and before and after SetPresenter inside the queued callback. Also check whether DispatcherQueue.TryEnqueue returns true, whether the callback runs, and whether the additional caption disappears and stays hidden.

Microsoft documents that DispatcherQueue.TryEnqueue queues work on its associated thread. It does not guarantee that kiosk-shell initialization has finished when the callback runs.

If you already tested this exact sequence, there is no need to repeat it. Please share the logs, the relevant window creation and activation code, and your Windows App SDK version so I can compare your result with Thomas's.

I would leave the Shell Launcher configuration unchanged during this test. The AI-generated answer's instruction to switch AllAppsFullScreen from true to false does not match your XML, which does not contain that attribute.

This comparison targets the configuration window's caption issue only. Separately, did assigning hwndOwner change the native file picker's fullscreen behavior?

Answer 2

Hello,

We have been experiencing exactly the same issue for the past few days.

We are using Windows 11 IoT Enterprise LTSC (24H2), and we have enabled kiosk mode with Shell Launcher to replace Explorer.exe with our application's shell in the KioskUser0 session.

In our WinUI 3 application code, we force full-screen mode to hide the title bar (including the minimize, maximize, and close buttons) using the following call:

_appWindow.SetPresenter(AppWindowPresenterKind.FullScreen);

Please note that our application bundles its own versions of the SDKs :

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.8.260209005" />

Since installing KB5095093 (updating to build 26.100.8737), the title bar has been appearing in the kiosk session, while it remains hidden in a standard Windows session on the same device.

We initially tried changing the V2:AllAppsFullScreen setting from "false" to "true" in our Shell Launcher configuration XML, but this made no difference.

To debug our application, we added checks to track the value of Presenter.Kind:

_appWindow.Changed += AppWindow_Changed;

Log($"1. Before SetPresenter: {_appWindow.Presenter.Kind}");

_appWindow.SetPresenter(AppWindowPresenterKind.FullScreen);
Log($"2. After SetPresenter: {_appWindow.Presenter.Kind}");

Activate();
Log($"3. After Activate: {_appWindow.Presenter.Kind}");

DispatcherQueue.TryEnqueue(() =>
{
    Log($"4. Dispatcher before SetPresenter: {_appWindow.Presenter.Kind}");

    _appWindow.SetPresenter(AppWindowPresenterKind.FullScreen);

    Log($"5. Dispatcher after SetPresenter: {_appWindow.Presenter.Kind}");
});

private void AppWindow_Changed(
    AppWindow sender,
    AppWindowChangedEventArgs args)
{
    if (args.DidPresenterChange)
    {
        Log($"Changed: presenter={sender.Presenter.Kind}");
    }
}

Here is the log output from our application running in a kiosk session:

2026-09-23 14:59:50 - 1. Before SetPresenter: FullScreen
2026-09-23 14:59:50 - Changed: presenter=FullScreen
2026-09-23 14:59:50 - 2. After SetPresenter: FullScreen
2026-09-23 14:59:50 - Changed: presenter=FullScreen
2026-09-23 14:59:50 - Changed: presenter=FullScreen
2026-09-23 14:59:50 - Changed: presenter=Overlapped
2026-09-23 14:59:50 - 3. After Activate: Overlapped
2026-09-23 14:59:50 - 4. Dispatcher before SetPresenter: Overlapped
2026-09-23 14:59:50 - Changed: presenter=Overlapped
2026-09-23 14:59:50 - Changed: presenter=FullScreen
2026-09-23 14:59:50 - 5. Dispatcher after SetPresenter: FullScreen

This result confirms the exact issue: Activate() resets the presenter to Overlapped in the Shell Launcher session. Fortunately, reapplying full-screen mode through a deferred call works and resolves the issue.

This therefore appears to be a regression or a change in the Windows/CustomShellHost initialization order introduced in build 26.100.8737.

I have just opened a support ticket to report this issue...

I hope this information helps you resolve your issue.

WinUI 3 full screen window is not correctly displayed in kiosk mode after Win11 update.

2 answers

Regarding the Shell Launcher configuration

About the File-picker code

For the troubleshooting

Root Cause

Programmatic Workarounds

Remedy 1: Delayed Re-application on Window Activation (Recommended)

Remedy 2: Listen for Presenter Changes

Shell Configuration Triage (If using Shell Launcher V2)

Your answer