fix(keyboardmanager): handle title bar setup failure - #49477
Open
MuhammadMusaab-UlHaq wants to merge 1 commit into
Open
fix(keyboardmanager): handle title bar setup failure#49477MuhammadMusaab-UlHaq wants to merge 1 commit into
MuhammadMusaab-UlHaq wants to merge 1 commit into
Conversation
…#49399) On some Windows 10 systems, setting ExtendsContentIntoTitleBar fails with ERROR_ALREADY_INITIALIZED and prevents the WinUI 3 editor from opening. Check whether title bar customization is supported and handle only that failure so the editor can continue with the system title bar.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Author
|
@microsoft-github-policy-service agree |
moooyo
reviewed
Jul 27, 2026
|
|
||
| try | ||
| { | ||
| if (AppWindowTitleBar.IsCustomizationSupported()) |
Contributor
There was a problem hiding this comment.
Seems it would not fix this bug. Could you please provide any evidence for your fix?
IsCustomizationSupported will always return true on a os which version greater than windows 10 1809 with WASDK 1.2
Merged
7 tasks
Contributor
|
seems this could fix #49524. |
moooyo
added a commit
that referenced
this pull request
Jul 28, 2026
…nch crash (0xC0000409) (#49524) ## Summary of the Pull Request `PowerToys.KeyboardManagerEditorUI.exe` fail-fasts with `0xC0000409` (`STATUS_STACK_BUFFER_OVERRUN`) during `MainWindow` construction, so the new Keyboard Manager editor never opens. `KeyboardManagerEditorUI.csproj` was the **only WinUI 3 executable in the repo missing `<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>`**, so it was built framework-package-dependent and mixed two Windows App SDK provenances in one process. ## PR Checklist - [x] Closes: #49399 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized <!-- no user-facing strings added --> - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places <!-- no new binaries --> - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx ## Detailed Description of the Pull Request / Additional comments ### Root cause The reporter's WinDbg capture shows a first-chance `Core::ApiException` carrying `0x800704DF` (`ERROR_ALREADY_INITIALIZED`): ``` MainWindow.SetTitleBar -> Microsoft.UI.Xaml.Window.set_ExtendsContentIntoTitleBar -> Microsoft.UI.Input!InputNonClientPointerSourceWinRTStatics::GetForWindowIdHelper -> Microsoft.UI.Windowing.Core!RegisterWindowFeature -> Core::NamedApiObject::Init -> Core::ApiException ``` `ExtendsContentIntoTitleBar` is the **site**, not the cause — it is simply the first user statement that crosses XAML -> Windowing -> Input. `microsoft.windowsappsdk.foundation/*/buildTransitive/Microsoft.WindowsAppSDK.BootstrapCommon.targets` turns the bootstrapper on precisely when this project's shape is hit: ```xml <PropertyGroup Condition="'$(WindowsAppSdkBootstrapInitialize)'=='' and '$(WindowsAppSDKSelfContained)'!='true' and '$(WindowsPackageType)'=='None' and ('$(OutputType)'=='Exe' or '$(OutputType)'=='Winexe')"> <WindowsAppSdkBootstrapInitialize>true</WindowsAppSdkBootstrapInitialize> </PropertyGroup> ``` That compiles in `MddBootstrapAutoInitializer.cs`, which joins the machine-wide `Microsoft.WindowsAppRuntime` MSIX framework package to the process package graph before `Main`. Meanwhile the exe's own directory — `WinUI3Apps` — is first in the Win32 DLL search order and already contains a complete app-local Windows App SDK payload, deployed there by the other 14 self-contained apps. One process, two Windows App SDK provenances, and the one-time feature-type registration in `Microsoft.UI.Input` collides. The omission was easy to miss: the project imports `src\Common.SelfContained.props`, whose name suggests it covers this — but it only sets the **.NET** `<SelfContained>` property, which is unrelated. This also explains why the reporter could not shake it off: the framework package is machine state, so uninstall/reinstall and wiping `%LOCALAPPDATA%\Microsoft\PowerToys` change nothing. The classic C++ editor is unaffected because it uses WinUI 2 XAML Islands and ships no Windows App SDK at all. `PowerToys.Settings.exe` ran healthily in the same elevated session on the same day while doing strictly more title-bar work (it sets `ExtendsContentIntoTitleBar` twice and drives `InputNonClientPointerSource.GetForWindowId` on every `SizeChanged`) — because it *is* self-contained. ### Two additional defects fixed Both were found while investigating why the crash left no diagnostics at all: 1. **`App.xaml.cs` initialized the logger via fire-and-forget `Task.Run`** — the only one of ~30 `Logger.InitializeLogger` call sites in the repo to do so. That races window creation, and `Logger` has no buffering or replay (`Trace.WriteLine` straight through, listener attached in `InitializeLogger`), so anything logged before the listener is attached is lost permanently. This is why the user's bug report bundle contains a `WinUI3Editor` log for the day it worked and **no log file at all** for the day it crashed. Made synchronous, ordered to match `FileLocksmithXAML/App.xaml.cs`, plus a log line before the window is constructed. 2. **`MainWindow` never called `WindowHelpers.ForceTopBorder1PixelInsetOnWindows10`**, unlike the other PowerToys WinUI 3 module windows (AdvancedPaste, EnvironmentVariables, FileLocksmith, Hosts, ImageResizer, Peek, RegistryPreview, Settings). It is a no-op on Windows 11 and fixes the black top border from microsoft/microsoft-ui-xaml#6901 on Windows 10 — the OS this issue was reported against. Happy to drop this hunk if reviewers prefer a minimal diff. Deliberately **not** done: wrapping `new MainWindow()` in `try/catch`. The failure is a WIL `RaiseFailFastException`, which managed code cannot intercept; and swallowing managed exceptions there would leave a windowless zombie process still holding the runner's `m_hEditorProcess` handle, making the runner take its "editor already open" branch and breaking every subsequent launch. That is why #49477 cannot work. ### Repo-wide audit All 15 WinUI 3 executables (`UseWinUI=true` and `OutputType=WinExe`) were checked. **KeyboardManagerEditorUI was the only one missing the property**; the other 14 already set it. Also verified as correct and unchanged: the 7 WinUI class libraries (property is app-level, N/A), `runner.vcxproj` and `PowerRenameUI.vcxproj` (native exes, both already `true`), and `PowerToys.MeasureToolCore.vcxproj` / `FindMyMouse.vcxproj` (deliberately `false` — in-proc module DLLs whose host already establishes the self-contained context). There is no repo-level default or build guard for this property; it is hand-copied into 17 project files, which is how the hole opened. A `Directory.Build.targets` guard that errors when an unpackaged Windows App SDK executable omits it would prevent recurrence, but it would catch nothing today, so I left it out of this PR to keep the diff scoped. Happy to open it separately. ## Validation Steps Performed Built `KeyboardManagerEditorUI.csproj` (x64/Debug) and diffed the build output before and after the change: | | before | after | `PowerToys.Hosts.exe` (reference) | |---|---|---|---| | `obj\x64\Debug\Manifests\` (created only by `CreateWinRTRegistration`) | absent | **present** | present | | `activatableClass` registrations embedded in the exe | **0** | **1912** | 1912 | | assembly references `Microsoft.WindowsAppRuntime.Bootstrap.Net` / `MddBootstrap` | **yes** | **no** | no | The editor now resolves every `Microsoft.UI.*` activation app-locally through registration-free WinRT instead of the machine framework package, which removes the mixing hazard. **Not yet validated on Windows 10.** I do not have a Windows 10 19045 machine, so the crash repro itself is unverified end-to-end. The deployment-mode change is verified from build output as above; confirmation from the issue reporter would be valuable. A useful discriminator if anyone has the reporter's ProcDump dump: `lm v m Microsoft.UI.*` — if `Microsoft.UI.Input.dll` is listed twice from two different paths, the mechanism is confirmed directly. Co-authored-by: Yu Leng (from Dev Box) <[email protected]> Co-authored-by: Claude <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #49399.
On some Windows 10 systems, the new Keyboard Manager editor closes before its window opens. This happens when custom title bar setup fails with
ERROR_ALREADY_INITIALIZED.This change checks whether custom title bars are supported. It handles only this known error, writes it to the log, and lets the editor continue with the normal Windows title bar. Other errors are not hidden.
PR Checklist
Detailed Description of the Pull Request / Additional comments
MainWindow.xaml.csnow checksAppWindowTitleBar.IsCustomizationSupported()before setting a custom title bar.It also handles HRESULT
0x800704DF(ERROR_ALREADY_INITIALIZED). This is the error shown in the crash report. The check is kept narrow so other title bar errors are still reported normally.If this error occurs, the editor uses the normal Windows title bar instead of closing during startup.
Testing was not possible because i dont have a windows 10 setup right now.