Sync upstream and upgrade Windows App SDK to 2.3.1 - #18
Closed
crutkas wants to merge 409 commits into
Closed
Conversation
## Summary Fixes microsoft#46767 Items pinned to the End section of the dock did not animate on startup, while Start and Center items did. The EndListView had an explicit empty `ItemContainerTransitions` collection that suppressed all container transitions. Removing it allows the default WinUI entrance animations to play, matching Start and Center behavior. ## Changes - `DockControl.xaml`: Remove empty `TransitionCollection` override from EndListView --------- Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
) ## Problem Since microsoft#47119 (`Refresh check-spelling 0.0.26`, merged 2026-04-23) refreshed the check-spelling tooling and rewrote `.github/actions/spell-check/expect.txt` (938 lines / 633 deletions), the check-spelling bot has been leaving a noisy advisory comment on **every PR**: > #### These words are not needed and should be removed > ABlocked AClient AColumn ACR ADate ADifferent AHybrid ALarger AModifier ANull AOklab APeriod ARandom ARemapped ASingle ASUS bck … The same ~150-word list is appended verbatim to every PR the bot looks at (verified against microsoft#48058, microsoft#48102, microsoft#48104 — the list is identical). These tokens are residual orphans in `expect.txt` from before the 0.0.26 refresh and no longer match anything in source. ## Fix Removes exactly the 147 orphan tokens that the bot has consistently flagged as `now absent` from `.github/actions/spell-check/expect.txt`. The removed tokens are exclusively the ones the bot itself identified. All uppercase Win32 / DirectWrite identifiers that are still used in source (`DWRITE`, `LWIN`, `VCENTER`, `VREDRAW`, etc.) are **preserved**. ## Verification - Diff is a single file, deletions only: `expect.txt` shrinks from 2343 → 2196 lines. - Each of the 4 uppercase Win32 tokens (`DWRITE` line 514, `LWIN` 1074, `VCENTER` 2105, `VREDRAW` 2144 in the original) remains in the file. - The check-spelling job on this PR should now post a clean report (no `should be removed` block). ## Background — which PR introduced the drift | PR | Date | What it changed | |----|------|-----------------| | **microsoft#47119** | 2026-04-23 | Refreshed check-spelling to 0.0.26; rewrote `expect.txt` with 938 line-changes (633 deletions, 305 additions). The duplicated lowercase/uppercase entries and many obsolete tokens originate here. | --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot <Copilot@users.noreply.github.com>
…icrosoft#47361) ## Summary of the Pull Request The File Locksmith IPC layer reads and writes raw UTF-16 (WCHAR) bytes to `last-run.log`, but all three stream opens were using the default text mode. On Windows, the CRT translates `0x0A` bytes to `0x0D 0x0A` on write and collapses `0x0D 0x0A` back to `0x0A` on read. Because each WCHAR is 2 bytes, any code unit whose little-endian byte pair contains `0x0A` in the low position (e.g. `U+010A`, `U+0A0D`) is silently corrupted. The fix opens all three streams in binary mode and adds an explicit open-failure guard. ```cpp // IPC.cpp — Writer::start() // Before m_stream = std::ofstream(path); // After m_stream = std::ofstream(path, std::ios::binary); // + is_open() guard returning E_FAIL on failure // NativeMethods.cpp — StartAsElevated() writer // Before std::ofstream stream(paths_file()); // After std::ofstream stream(paths_file(), std::ios::binary); // NativeMethods.cpp — ReadPathsFromFile() reader // Before std::ifstream stream(paths_file()); // After std::ifstream stream(paths_file(), std::ios::binary); ``` ## PR Checklist - [ ] **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 - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 Three targeted changes across two files: 1. **`FileLocksmithLib/IPC.cpp` — `Writer::start()`**: switched `std::ofstream` from text to binary mode and added an `is_open()` check that returns `E_FAIL` immediately when the file cannot be opened (previously the try/catch did not catch a silent open failure because `std::ofstream` does not throw by default). 2. **`FileLocksmithLibInterop/NativeMethods.cpp` — `StartAsElevated()`**: switched `std::ofstream` from text to binary mode. This is the elevated-restart writer path; without this fix, Unicode corruption persisted when File Locksmith relaunched as administrator. 3. **`FileLocksmithLibInterop/NativeMethods.cpp` — `ReadPathsFromFile()`**: switched `std::ifstream` from text to binary mode. This is the symmetric reader-side bug — even with both writers corrected, the CRT text-mode reader could collapse a `0x0D 0x0A` byte pair (a valid UTF-16 LE code unit, e.g. U+0A0D GURMUKHI EK ONKAR) into a single byte, desynchronising the 2-bytes-at-a-time read loop and corrupting all subsequent path data. No behaviour change for purely ASCII paths. Paths containing Unicode code points whose little-endian UTF-16 byte pair spans `0x0D 0x0A` were silently corrupted in all three code paths before this fix. ## Validation Steps Performed - Code review: no issues flagged. - Full diff reviewed: all three stream opens (`ofstream` writer in `IPC.cpp`, `ofstream` writer in `NativeMethods.cpp`, `ifstream` reader in `NativeMethods.cpp`) now use `std::ios::binary`, making write and read paths byte-exact and symmetric. - Mechanically correct: `std::ios::binary` suppresses Windows CRT `\n`↔`\r\n` translation; the delimiter `L'\n'` (LE bytes `0x0A 0x00`) is unambiguous in binary mode and is handled correctly by the existing read loop. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: MuyuanMS <116717757+MuyuanMS@users.noreply.github.com> Co-authored-by: Muyuan Li (from Dev Box) <muyuanli@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…icrosoft#48111) ## Summary of the Pull Request Two crash-correlation aids for the kernel-side DDC/CI BSOD mitigated by microsoft#47734: 1. Log EDID hardware ID (manufacturer + product code, e.g. `DELD1A8`) during Phase 0 monitor classification, before any DDC/CI capability fetch enters the BSOD risk window. 2. Show a confirmation dialog before turning the Power Display module on from the Settings page, so the user understands the BSOD risk before the first capability fetch runs. ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 ### 1. Phase 0 EdidId logging `MonitorIdentity.EdidIdFromDevicePath` parses the EDID hardware ID segment from a DevicePath of the form ``\?\DISPLAY#DELD1A8#5&abc&0&UID12345#{guid}`` and returns ``DELD1A8``. The 3-letter PNP manufacturer code + 4-hex product code is identical for every physical unit of the same model, so it identifies the *model* without leaking per-unit identifiers. `MonitorManager` logs the EdidId on the existing Phase 0 classification line. Phase 0 uses `QueryDisplayConfig`, which reads OS-cached EDID and cannot BSOD, so this line is guaranteed on disk before the crash-prone Phase 2 capability fetch starts. If a machine crashes during enumeration, the recovered log identifies every attached model (including same-model duplicates), which makes it possible to correlate crash reports to specific monitor models even when the user can't tell us which monitor caused the crash. ### 2. Enable-module confirmation dialog `PowerDisplayViewModel.IsEnabled` setter is refactored to follow the same two-phase pattern already used by `MaxCompatibilityMode`: - `false → true` does not commit immediately; it kicks off `ConfirmAndEnableModuleAsync`, which awaits the existing `DangerousFeatureWarningDialog` (resource prefix `PowerDisplay_EnableModule`) and either commits or reverts the ToggleSwitch via `OnPropertyChanged`. - `true → false` commits unconditionally — we never block a user who wants to turn the module off. - App-startup loads via `InitializeEnabledValue()` / `RefreshEnabledState()` assign the `_isEnabled` field directly, bypassing the setter, so the dialog never fires on settings restore or GPO refresh. - GPO-configured state still short-circuits before any dialog logic. The dialog reuses the existing `DangerousFeatureWarningDialog` injected by `PowerDisplayPage.xaml.cs`. The 5 new `PowerDisplay_EnableModule_*` strings explain that the BSOD is in Windows (not Power Display), that Power Display will auto-disable itself after a detected crash, and that the user has to re-enable + dismiss the warning each time. ## Validation Steps Performed - Built `src/settings-ui` and `src/modules/powerdisplay` locally. - Unit tests: added `EdidIdFromDevicePath_*` cases to `MonitorIdentityTests`, all green. - Settings UI manual: toggling Power Display ON now shows the warning dialog. Pressing Cancel reverts the ToggleSwitch visually; pressing Enable commits and the module starts. Toggling OFF does not prompt. Restarting Settings UI with PowerDisplay enabled does not prompt. GPO-disabled state still locks the toggle. - Log inspection: `MonitorManager` Phase 0 log now shows `EdidId=...` for each path before any capability fetch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…icrosoft#48111) ## Summary of the Pull Request Two crash-correlation aids for the kernel-side DDC/CI BSOD mitigated by microsoft#47734: 1. Log EDID hardware ID (manufacturer + product code, e.g. `DELD1A8`) during Phase 0 monitor classification, before any DDC/CI capability fetch enters the BSOD risk window. 2. Show a confirmation dialog before turning the Power Display module on from the Settings page, so the user understands the BSOD risk before the first capability fetch runs. ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 ### 1. Phase 0 EdidId logging `MonitorIdentity.EdidIdFromDevicePath` parses the EDID hardware ID segment from a DevicePath of the form ``\?\DISPLAY#DELD1A8#5&abc&0&UID12345#{guid}`` and returns ``DELD1A8``. The 3-letter PNP manufacturer code + 4-hex product code is identical for every physical unit of the same model, so it identifies the *model* without leaking per-unit identifiers. `MonitorManager` logs the EdidId on the existing Phase 0 classification line. Phase 0 uses `QueryDisplayConfig`, which reads OS-cached EDID and cannot BSOD, so this line is guaranteed on disk before the crash-prone Phase 2 capability fetch starts. If a machine crashes during enumeration, the recovered log identifies every attached model (including same-model duplicates), which makes it possible to correlate crash reports to specific monitor models even when the user can't tell us which monitor caused the crash. ### 2. Enable-module confirmation dialog `PowerDisplayViewModel.IsEnabled` setter is refactored to follow the same two-phase pattern already used by `MaxCompatibilityMode`: - `false → true` does not commit immediately; it kicks off `ConfirmAndEnableModuleAsync`, which awaits the existing `DangerousFeatureWarningDialog` (resource prefix `PowerDisplay_EnableModule`) and either commits or reverts the ToggleSwitch via `OnPropertyChanged`. - `true → false` commits unconditionally — we never block a user who wants to turn the module off. - App-startup loads via `InitializeEnabledValue()` / `RefreshEnabledState()` assign the `_isEnabled` field directly, bypassing the setter, so the dialog never fires on settings restore or GPO refresh. - GPO-configured state still short-circuits before any dialog logic. The dialog reuses the existing `DangerousFeatureWarningDialog` injected by `PowerDisplayPage.xaml.cs`. The 5 new `PowerDisplay_EnableModule_*` strings explain that the BSOD is in Windows (not Power Display), that Power Display will auto-disable itself after a detected crash, and that the user has to re-enable + dismiss the warning each time. ## Validation Steps Performed - Built `src/settings-ui` and `src/modules/powerdisplay` locally. - Unit tests: added `EdidIdFromDevicePath_*` cases to `MonitorIdentityTests`, all green. - Settings UI manual: toggling Power Display ON now shows the warning dialog. Pressing Cancel reverts the ToggleSwitch visually; pressing Enable commits and the module starts. Toggling OFF does not prompt. Restarting Settings UI with PowerDisplay enabled does not prompt. GPO-disabled state still locks the toggle. - Log inspection: `MonitorManager` Phase 0 log now shows `EdidId=...` for each path before any capability fetch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary of the Pull Request Adding information about using the Command Palette Visual Studio solution filter based on microsoft#47997 (comment). ## PR Checklist - [ ] Closes: microsoft#47997 ## Detailed Description of the Pull Request / Additional comments I found this really useful and couldn't see a reference to it anywhere else in the devdocs. Not sure if this is the best way to describe the process, but I think adding this information somewhere in the debugging doc would really help newcomers to CmdPal development!
… failures (microsoft#48124) ## Summary `ToJsonFromXmlOrCsvAsync` in `AdvancedPaste/Helpers/JsonHelper.cs` documents that it never throws and returns an empty string on any failure. The clipboard read at the top of the method (`clipboardData.GetTextAsync()`) was not wrapped, so a transient clipboard failure could surface as an exception to callers, contrary to the documented contract. This PR: - Wraps `GetTextAsync()` in a try/catch and returns `string.Empty` on failure, matching the pattern already used by the JSON/XML/CSV parsing branches further down in the same method. - Updates the matching unit test to decode input bytes as UTF-8 (`Encoding.UTF8.GetString(input)`) and consume the awaited task via `GetAwaiter().GetResult()`, for consistency with sibling tests elsewhere in the solution. ## Validation - Local build of `AdvancedPaste.sln`. (Note: my machine has a pre-existing NuGet SDK resolver issue unrelated to this change — the same baseline fails on `main` for me. CI should be the source of truth.) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…eceive (microsoft#48118) ## Summary of the Pull Request On the Command Palette Performance Monitor extension's Network widget page, the **Send** and **Receive** list items both used the generic `NetworkIcon` (`\uEC05`), making them visually indistinguishable at a glance. This PR gives each direction its own glyph: - Send → up arrow `\uE74A` - Receive → down arrow `\uE74B` The redundant `↑`/`↓` characters are removed from the Send/Receive subtitles since the icons now carry that meaning. Before vs after: <img width="918" height="122" alt="image" src="https://github.com/user-attachments/assets/4af3a2fc-d5a7-4fb5-98c6-f1889c7e80f2" /> ## PR Checklist - [x] **Closes:** N/A (no existing issue found) - [x] **Communication:** I've discussed this with collaborators - [x] **Tests:** Manually verified - [x] **Localization:** Updated en-US resw (other locales still contain the arrow characters and can be translated/updated by the loc pipeline) ## Detailed Description of the Pull Request / Additional comments Files changed: - `Icons.cs` – added `NetworkUpIcon` and `NetworkDownIcon` - `PerformanceWidgetsPage.cs` – set `Icon` on `_networkUpItem` and `_networkDownItem` - `Strings/en-US/Resources.resw` – `Send ↑` → `Send`, `Receive ↓` → `Receive` ## Validation Steps Performed Local visual verification in Command Palette. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…oft#47981) Reopens the change from microsoft#46743 (which appears to be broken) on a fresh branch. Original author: @daverayment ## Summary GitHub newcomers can be confused by the current duplicate resolution message, as it doesn't clearly point to the original referenced issue - see microsoft#46347 (comment). They may not realise that the microsoft#12345 in the duplicate comment is the relevant link. This small wording update to the duplicate resolution message tightens up wording slightly and includes reference to the prior `/dup #nnn` comment so newcomers don't miss it. ### Before > Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report! ### After > We've identified this issue as a duplicate of an existing one and are closing this thread so discussion stays in one place.<br/><br/>Please see the comment above for the link to the original tracking issue, and feel free to subscribe there for updates. ## Validation Steps Performed N/A - bot reply text change only. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…refactor (microsoft#44553) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Some focussed refactoring / simplifying / cleanup / delinting on the Mouse Without Borders codebase (see [microsoft#44508 - [Mouse Without Borders] - de-linting codebase](microsoft#44508)) now that the Common class has been broken down. This PR does some cleaning up on the ```Logger``` class: * Uplifting coding style (string interpolation, pattern matching, ```var```, etc) * Rationalising and simplifying code * Relocating e.g. IO and UI side effects (writing to disk, displaying dialog boxes) outside of Logger class * Removing dead code, tightening visibility of existing code * Added / updated tests to try to cover as much of the refactoring as possible to prevent regressions I've split the changes into lots of small commits - it might be easier to review the individual commits rather than the whole PR in one go. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [x] **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 - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ### Run manual tests from [Test Checklist Template](https://github.com/microsoft/PowerToys/blob/5bc7201ae2b75b53d3a4bc35119c867ecf71c5f6/doc/releases/tests-checklist-template.md#mouse-without-borders): * Install PowerToys on two PCs in the same local network: - [x] Verify that PowerToys is properly installed on both PCs. - [x] Configure Windows Firewall Rules - ```netsh advfirewall firewall add rule name="PowerToys.MouseWithoutBorders - mc" dir=in action=allow program="C:\src\mc\PowerToys\x64\Debug\PowerToys.exe" enable=yes remoteip=any profile=any protocol=tcp``` * Setup Connection: - [x] Open MWB's settings on the first PC and click the "New Key" button. Verify that a new security key is generated. - [x] Copy the generated security key and paste it in the corresponding input field in the settings of MWB on the second PC. Also enter the name of the first PC in the required field. - [x] Press "Connect" and verify that the machine layout now includes two PC tiles, each displaying their respective PC names. * Verify Connection Status: - [x] Ensure that the border of the remote PC turns green, indicating a successful connection. - [x] Enter an incorrect security key and verify that the border of the remote PC turns red, indicating a failed connection. * Test Remote Mouse/Keyboard Control: - [x] With the PCs connected, test the mouse/keyboard control from one PC to another. Verify that the mouse/keyboard inputs are correctly registered on the other PC. - [ ] Test remote mouse/keyboard control across all four PCs, if available. Verify that inputs are correctly registered on each connected PC when the mouse is active there. - unable to test - only 2 machines available * Test Remote Control with Elevated Apps: - note - the main PowerToys.exe must be running as a **non**-admin for these tests - [x] Open an elevated app on one of the PCs. Verify that without "Use Service" enabled, PowerToys does not control the elevated app. - [x] Enable "Use Service" in MWB's settings (need to run PowerToys.exe as admin to enable "Use Service", then restart PowerToys.exe as non-admin). Verify that PowerToys can now control the elevated app remotely. Verify that MWB processes are running as LocalSystem, while the MWB helper process is running non-elevated. - ```get-process -Name "PowerToys.MouseWithoutBorders*" -IncludeUserName | format-table Id, ProcessName, UserName``` - [x] Process: ```PowerToys.MouseWithoutBorders.exe``` - running as ```SYSTEM``` - [x] Process: ```PowerToys.MouseWithoutBorders.Helper.exe``` - running as current user - ```get-service -Name "PowerToys.*" | ft Status, Name, UserName; get-ciminstance -Class "Win32_Service" -Filter "Name like 'PowerToys%'" | ft ProcessId, Name``` - [ ] Service: ```PowerToys.MWB.Service``` - running as ```Local System``` - [x] Toggle "Use Service" again, verify that each time you do that, the MWB processes are restarted. - [ ] Run PowerToys elevated on one of the machines, verify that you can control elevated apps remotely now on that machine. * Test Module Enable Status: - [ ] For all combinations of "Use Service"/"Run PowerToys as admin", try enabling/disabling MWB module and verify that it's indeed being toggled using task manager. * Test Disconnection/Reconnection: - [ ] Disconnect one of the PCs from network. Verify that the machine layout updates to reflect the disconnection. - [ ] Do the same, but now by exiting PowerToys. - [ ] Start PowerToys again, verify that the PCs are reconnected. * Test Various Local Network Conditions: - [ ] Test MWB performance under various network conditions (e.g., low bandwidth, high latency). Verify that the tool maintains a stable connection and functions correctly. * Clipboard Sharing: - [ ] Copy some text on one PC and verify that the same text can be pasted on another PC. - [ ] Use the screenshot key and Win+Shift+S to take a screenshot on one PC and verify that the screenshot can be pasted on another PC. - [ ] Copy a file in Windows Explorer and verify that the file can be pasted on another PC. Make sure the file size is below 100MB. - [ ] Try to copy multiple files and directories and verify that it's not possible (only the first selected file is being copied). * Drag and Drop: - [ ] Drag a file from Windows Explorer on one PC, cross the screen border onto another PC, and release it there. Verify that the file is copied to the other PC. Make sure the file size is below 100MB. - [ ] While dragging the file, verify that a corresponding icon is displayed under the mouse cursor. - [ ] Without moving the mouse from one PC to the target PC, press CTRL+ALT+F1/2/3/4 hotkey to switch to the target PC directly and verify that file sharing/dropping is not working. * Lock and Unlock with "Use Service" Enabled: - [ ] Enable "Use Service" in MWB's settings. - [ ] Lock a remote PC using Win+L, move the mouse to it remotely, and try to unlock it. Verify that you can unlock the remote PC. - [ ] Disable "Use Service" in MWB's settings, lock the remote PC, move the mouse to it remotely, and try to unlock it. Verify that you can't unlock the remote PC. * Test Settings: - [ ] Change the rest of available settings on MWB page and verify that each setting works as described. ### Group Policy Tests See https://learn.microsoft.com/en-us/windows/powertoys/grouppolicy - [ ] Install *.admx / *.adml and check settings behave as expected - [ ] I'll expand the list of settings here when I get this far :-) - [ ] HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys - [x] ConfigureEnabledUtilityMouseWithoutBorders - [x] ```[missing]``` - "Activation -> Enable Mouse Without Borders" enabled, with GPO warning hidden - ```reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v ConfigureEnabledUtilityMouseWithoutBorders /f``` - [x] ```0``` - "Activation -> Enable Mouse Without Borders" set to "off" and disabled, with GPO warning visible - ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v ConfigureEnabledUtilityMouseWithoutBorders /t REG_DWORD /d 0 /f``` - [x] ```1``` - "Activation -> Enable Mouse Without Borders" set to "on" and disabled, with GPO warning visible - ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v ConfigureEnabledUtilityMouseWithoutBorders /t REG_DWORD /d 1 /f``` - [ ] MwbClipboardSharingEnabled - [ ] MwbFileTransferEnabled - [ ] MwbUseOriginalUserInterface - [ ] MwbDisallowBlockingScreensaver - [ ] MwbSameSubnetOnly - [ ] MwbValidateRemoteIp - [x] MwbDisableUserDefinedIpMappingRules - [x] ```[missing]``` - "Advanced Settings -> IP address mapping" enabled, with GPO warning hidden - ```reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v MwbDisableUserDefinedIpMappingRules /f``` - [x] ```0``` - "Advanced Settings -> IP address mapping" enabled, with GPO warning hidden - ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v MwbDisableUserDefinedIpMappingRules /t REG_DWORD /d 0 /f``` - [x] ```1``` - "Advanced Settings -> IP address mapping" disabled, with GPO warning visible - ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v MwbDisableUserDefinedIpMappingRules /t REG_DWORD /d 1 /f``` - [x] MwbPolicyDefinedIpMappingRules - [x] ```[missing]``` - "Advanced Settings -> IP address mapping" enabled, with GPO warning and GPO values hidden - ```reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v MwbPolicyDefinedIpMappingRules /f``` - [x] ```[empty value]``` - "Advanced Settings -> IP address mapping" enabled, with GPO warning hidden and GPO values hidden - ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v MwbPolicyDefinedIpMappingRules /t REG_MULTI_SZ /d "" /f``` - [x] ```[non-empty value]``` - "Advanced Settings -> IP address mapping" enabled, with GPO warning visible and GPO values visible - ```reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\PowerToys /v MwbPolicyDefinedIpMappingRules /t REG_MULTI_SZ /d "aaa 10.0.0.1\0bbb 10.0.0.2" /f```
## Summary of the Pull Request Updates .NET 10 Runtime / Library packages to the latest 10.0.8 servicing release for security fixes. ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **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 - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 Updates the runtime-related package versions in `Directory.Packages.props` from `10.0.7` to `10.0.8`. ## Validation Steps Performed Co-authored-by: Copilot <copilot@github.com> Co-authored-by: Niels Laute <niels.laute@live.nl>
## Summary Migrate `deps/spdlog` from a git submodule to **vcpkg manifest mode** with an overlay port pinned to the **exact same commit** (`gabime/spdlog@616866fc`). Replaces the polyfill shim added in microsoft#47910 with a proper port-level patch. This is the follow-up to PR microsoft#47928, which I closed after @zadjii-msft / @DHowett clarified that the intended direction was a single combined "move to vcpkg **and** apply a patch file" (one change, not two stepping stones). ## Guidance honored Per @zadjii-msft (offline): - ✅ Convert each submodule to vcpkg **one at a time** — this PR is **spdlog only**. `deps/expected-lite` stays a submodule (separate PR next). - ✅ Atomic commit per dep (multiple commits on the branch for review traceability; squash on merge gives the requested single commit). - ✅ **Don't bump the version.** Only variable changed: submodule → vcpkg. Same commit (`616866fc`, v1.8.5 + 38) the submodule pointed at. Per @DHowett ([review](microsoft#48039 (review))): - ✅ No vcpkg submodule — vswhere-first detection via a Terminal-style `steps-install-vcpkg.yml` template; three-tier `VcpkgRoot` fallback (env var → VS-shipped → runtime clone pinned to manifest baseline). ## Design - **Repo-root manifest**: `vcpkg.json` declares only `spdlog`, with `builtin-baseline` pinned. `vcpkg-configuration.json` registers `deps/vcpkg-overlays/` as overlay-ports. - **Overlay port** `deps/vcpkg-overlays/spdlog/`: `vcpkg_from_github(REF 616866fc...)` with bundled fmt preserved (`-DSPDLOG_FMT_EXTERNAL=OFF`); the MSVC 14.51 fix from microsoft#47910 carried as a proper vcpkg patch on `include/spdlog/fmt/bundled/format.h`. - **vcpkg integration is global** (set in `Cpp.Build.props`, imported via `ForceImportBeforeCppProps` for every `.vcxproj`). An earlier attempt to make vcpkg per-project-opt-in via `deps/spdlog.props` failed because ~85 PowerToys `.vcxproj` files import `spdlog.props` AFTER `Microsoft.Cpp.targets`, by which point `vcpkg.props`' `ClCompile` hook is dead-on-arrival. The trade-off (every C++ project invokes `vcpkg install` once at build time, ~0.5 s on cache hits, manifest declares only spdlog so install set is fixed) is documented in the expanded `Cpp.Build.props` comment. - **`deps/spdlog.props`** is now a thin shim that only sets the historical `SPDLOG_*` preprocessor defines for source-compat. - **`Cpp.Build.targets`** is a new file imported via `ForceImportAfterCppTargets` to load `vcpkg.targets` after `Microsoft.Cpp.targets`. A fail-fast `<Target>` errors with a clear message if `vcpkg.props` can't be found at the resolved `VcpkgRoot`. - **Removes** `deps/spdlog-msvc-fix/` polyfill, in-tree wrapper `src/logging/`, spdlog submodule, the single `<ProjectReference>` in `logger.vcxproj`, plus 3 `.slnf` refs and 2 `.slnx` refs (`PowerToys.slnx` + `installer/PowerToysSetup.slnx`), plus 3 hard-coded `..\deps\spdlog\include` entries in `<AdditionalIncludeDirectories>`. - **CI**: new reusable `.pipelines/v2/templates/steps-install-vcpkg.yml` (vswhere-first, manifest-baseline-pinned fallback clone, respects `useVSPreview`). Gated `Cache@2` for `%LOCALAPPDATA%\vcpkg\archives` keyed on overlay-port contents. Same vcpkg detection added to `tools\build\build-essentials.ps1` for local devs. ## Verification Local build matrix (all 4 configs of `logger.vcxproj` and a representative late-import consumer): | Config | Result | Notes | |--------|--------|-------| | Release \| x64 | ✅ | vcpkg install ~21 s, `logger.lib` produced | | Debug \| x64 | ✅ | **Validates patch fixes the actual MSVC 14.51 bug** (`_ITERATOR_DEBUG_LEVEL > 0` → `_SECURE_SCL`) | | Release \| ARM64 | ✅ | vcpkg cross-installs `arm64-windows-static` spdlog in ~16 s | | Debug \| ARM64 | ✅ | **Previously DISABLED for the in-tree spdlog** (per `<Build Solution="Debug\|ARM64" Project="false" />` in `PowerToysSetup.slnx`); this migration FIXES that latent gap | | FancyZonesLib (Release \| x64) | ✅ | Late-import-pattern consumer; previously broke in v2 | Full PowerToys CI (x64 + arm64 + CmdPal SDK + all GitHub Actions checks) green. **Consumer audit**: 72 `.vcxproj` files reference `logger.vcxproj`; all 72 also import `deps/spdlog.props`. No transitive-link breakage. ## Out of scope (intentional) - `deps/expected-lite` migration — next PR per "one-at-a-time" rule. - Remote vcpkg binary cache (Azure Artifacts NuGet feed). Local pipeline `Cache@2` works for now, but a remote feed survives across pipelines and is the long-term answer. Happy to split this into a follow-up. ## Notes for review - Patch in the overlay port is identical content to PR microsoft#47928's patch but regenerated with LF line endings (vcpkg's `vcpkg_apply_patches` is strict; no `--ignore-whitespace`). - Once PowerToys eventually bumps spdlog past v1.14 (which ships fmt 10.2 and drops the affected code path), the overlay port can be deleted and we can use upstream vcpkg's `spdlog` directly. - Re. official-release pipelines and terrapin / less-restricted network isolation: VS-shipped vcpkg is the primary path (no network); the fallback clone is only exercised when VS doesn't ship vcpkg. Happy to wire terrapin into the fallback as a follow-up if the official build template needs it. Closes the work tracked in microsoft#47928 (which was closed unmerged). --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Dustin L. Howett <dustin@howett.net>
## Summary - Fix a grammar typo in the PowerToy project template README heading. - Change "Settings Informations" to "Settings Information". ## Validation - Ran `git diff --check`.
This removes our last git submodule dependency! We were using `expected-lite` in one place, which was being compiled out _anyway_ in favor of using `std::expected`.
Reverts 0819a62 / microsoft#46926 The cmdpal API is literally generated from this spec document. It needs to live with the rest of the code to work correctly. Docs for authoring cmdpal extensions are on https://learn.microsoft.com/en-us/windows/powertoys/command-palette/extension-development, and we should direct docs commentary there.
## Summary of the Pull Request Return a friendly calculator error when Mages evaluates an expression to a complex number instead of letting decimal conversion throw. This fixes the PowerToys Run Calculator result for expressions such as `sqrt(-1)` by detecting `System.Numerics.Complex` results before decimal conversion and showing a localized error message instead. Fixes microsoft#43937 ## PR Checklist - [x] Closes: microsoft#43937 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [x] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places - [x] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [x] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [x] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [x] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [x] **Documentation updated:** Not required for this bug fix. ## Detailed Description of the Pull Request / Additional comments The Calculator plugin previously passed complex results from Mages into `Convert.ToDecimal`, which caused an exception for expressions like `sqrt(-1)`. This PR updates the calculator result transformation logic to detect `System.Numerics.Complex` and return a localized user-facing error message: `Complex numbers are not supported`. It also updates calculator query tests to cover both direct keyword and global query behavior. ## Validation Steps Performed - Added unit test coverage for `=sqrt(-1)` returning `Complex numbers are not supported`. - Added unit test coverage for global query `sqrt(-1)` returning no result instead of surfacing an unhandled exception. - Ran `git diff --check`. - Attempted local build/test with the PowerToys build scripts, but local validation was blocked by Visual Studio/VC tooling configuration issues unrelated to this change: `PlatformToolsetVersion` resolves to an empty value during restore/build.
…8155) ## Summary of the Pull Request Renames the OOBE welcome/overview hyperlink label from **“Documentation on Microsoft Learn”** to **“Documentation”** for brevity and consistency. Scope is limited to the localized string resource used by the OOBE overview page. ## PR Checklist - [ ] **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 - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 - **Resource update (OOBE Overview)** - Updated `Oobe_Overview_DescriptionLinkText.Text` in `src/settings-ui/Settings.UI/Strings/en-us/Resources.resw`. ```xml <data name="Oobe_Overview_DescriptionLinkText.Text" xml:space="preserve"> <value>Documentation</value> </data> ``` ## Validation Steps Performed - Confirmed the OOBE overview string key now resolves to **“Documentation”**. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
…down (microsoft#48173) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Cooperative shutdowns of `PowerDisplay.exe` — Runner's `TerminateApp` NamedPipe message, the `Terminate` named event, tray-quit, Runner-exit detection, and PowerToys upgrades — all call `Environment.Exit(0)` immediately. If DDC/CI discovery is mid-flight, that path skips the `try/finally` that owns `CrashDetectionScope`, leaving `discovery.lock` on disk. Phase 0 at the next `PowerDisplay.exe` startup then treats this orphan as evidence of a real crash and auto-disables the module, surfacing the "PowerDisplay has crashed" InfoBar in Settings UI. This PR adds an `AppDomain.ProcessExit` safety-net inside `CrashDetectionScope`. ProcessExit fires for `Environment.Exit` but **not** for `FailFast` / BSOD / external `TerminateProcess` — exactly the partition we need: cooperative exit → best-effort delete the lock; involuntary kill → leave the lock for Phase 0 to detect (original design intent preserved). <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#48169 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized <!-- no user-facing strings changed --> - [x] **Dev docs:** Added/updated <!-- inline XML doc on CrashDetectionScope explains the ProcessExit partition --> - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments ### Root cause `CrashDetectionScope.Begin()` writes `discovery.lock` before DDC/CI capability fetch and `Dispose()` deletes it when the `using` block exits. The lock is intentionally designed to survive any code path that cannot run user-mode cleanup (BSOD, kernel OOM, `TerminateProcess`), so that the next `PowerDisplay.exe` start can see it and run Phase 0 (write `crash_detected.flag`, set `enabled.PowerDisplay=false` in global `settings.json`, signal `AutoDisablePowerDisplayEvent`). The bug is that several **cooperative** shutdown paths route to `Environment.Exit(0)` immediately: | Path | Code | |---|---| | Runner's `TerminateApp` NamedPipe | `App.xaml.cs::OnNamedPipeMessage` → `Shutdown()` → `Environment.Exit(0)` | | `Terminate` named event | `App.xaml.cs::OnLaunched` → `RegisterEvent(..., () => Environment.Exit(0), "Terminate")` | | Tray-quit | `TrayIconService` callback → `Environment.Exit(0)` | | Runner-exit detection | `RunnerHelper.WaitForPowerToysRunner` callback → `Environment.Exit(0)` | `Environment.Exit` calls `ExitProcess` under the hood, which terminates all threads abruptly. Background `Task.WhenAll` doing DDC capability fetch is killed mid-flight; the `finally` block that calls `scope.Dispose()` never runs; `discovery.lock` orphans; Phase 0 next time false-positives. Concrete repro from logs: - `15:08:42.510` lock written - `15:08:42.79` probe monitor #1 - `15:08:46.92` probe monitor #2 (started, not finished — typical probe takes ~5s) - `15:08:49.03` `TerminateApp` received → `Environment.Exit(0)` → no `Dispose` log line - `15:10:10.03` next startup: Phase 0 sees orphan lock with `pid:17712, startedAt:2026-05-28T07:08:42Z` → writes `crash_detected.flag` → auto-disables ### Fix `CrashDetectionScope.Begin()` now also subscribes to `AppDomain.CurrentDomain.ProcessExit`. The handler does a best-effort `File.Delete(_lockPath)` (swallowing exceptions, as required for ProcessExit handlers). `Dispose()` unsubscribes before deleting. An `Interlocked.Exchange` guards the race between Dispose and ProcessExit so only one of the two performs the delete. ProcessExit's semantics match the cooperative/involuntary partition exactly: | Shutdown path | ProcessExit fires? | Behavior after this PR | |---|---|---| | `Environment.Exit(code)` (all 4 paths above) | yes | lock deleted by handler | | `Environment.FailFast` | no | lock survives → Phase 0 catches it (correct: explicit FailFast = real failure) | | BSOD / external `TerminateProcess` / kernel OOM | no | lock survives → Phase 0 catches it (correct: original design) | | Discovery completes normally / throws | n/a | `try/finally` calls `Dispose()` as before; handler unsubscribed first | ### Testability A new `IProcessExitHook` interface abstracts the subscription so unit tests can simulate ProcessExit without terminating the test runner. Production code uses the default `AppDomainProcessExitHook` singleton; tests inject a fake whose `RaiseExit()` invokes subscribed handlers synchronously. ### Files touched - `src/modules/powerdisplay/PowerDisplay.Lib/Services/IProcessExitHook.cs` *(new)* — interface + production singleton - `src/modules/powerdisplay/PowerDisplay.Lib/Services/CrashDetectionScope.cs` — subscribe in `Begin`, unsubscribe in `Dispose`, add `OnProcessExit` handler, expanded class doc - `src/modules/powerdisplay/PowerDisplay.Lib.UnitTests/CrashDetectionScopeTests.cs` *(new)* — 10 unit tests <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ### Automated 10 new unit tests in `CrashDetectionScopeTests`, all passing: ``` Passed Begin_WritesLockFileAtomically Passed Begin_SubscribesToProcessExit Passed Dispose_UnsubscribesFromProcessExit Passed Dispose_DeletesLockFile Passed ProcessExitFired_BeforeDispose_DeletesLock (core scenario) Passed ProcessExitFired_AfterDispose_DoesNothing Passed Dispose_AfterProcessExit_DoesNotThrow Passed ProcessExitFired_LockFileMissing_DoesNotThrow Passed Dispose_IsIdempotent Passed MultipleScopes_DoNotShareState ``` Full `PowerDisplay.Lib.UnitTests` suite: **129 / 132 passing**. The 3 failures (`DetectOrphanAndDisable_RunsFullSequenceWhenOrphanPresent`, `DetectOrphanAndDisable_HandlesUnknownVersionAsOrphan`, `DetectOrphanAndDisable_LeavesLockIntactOnSignalFailure`) are **pre-existing on `main`** — they fail with `REGDB_E_CLASSNOTREG` from `Constants.AutoDisablePowerDisplayEvent()` (WinRT activation factory not COM-registered in the test environment). Verified by stashing this PR's changes and re-running the same 3 tests on baseline `main` — same failures, same cause, unrelated to this change. ### Manual 1. Reproduced the original false-positive on `main`: - Enable PowerDisplay → open Settings UI → quickly toggle PowerDisplay off - Observe `discovery.lock` left in `%LOCALAPPDATA%\Microsoft\PowerToys\PowerDisplay\` - Re-enable PowerDisplay → Phase 0 writes `crash_detected.flag` → InfoBar appears 2. Repeated the same steps with this branch: - Toggling PowerDisplay off cleanly deletes `discovery.lock` (ProcessExit handler ran) - Re-enabling PowerDisplay shows no InfoBar, no `crash_detected.flag` created 3. BSOD path is unchanged (verified by inspecting the conditional logic — `AppDomain.ProcessExit` does not fire for involuntary terminations; the lock survives just as before). --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary of the Pull Request Both Power Display and Grab and Move have matured beyond their initial release phase. This removes the "NEW" `InfoBadge` from their navigation items in Settings, the two parent navigation groups (Windowing & Layouts, Input / Output) that surfaced the badge when collapsed, and clears the `IsNew` flag for Power Display in the OOBE shell. <img width="1867" height="973" alt="image" src="https://github.com/user-attachments/assets/533f271c-c70f-414f-a76a-43fd9ffbbd44" /> <img width="497" height="575" alt="image" src="https://github.com/user-attachments/assets/fe1e97c3-c806-4f42-a836-76e042630d61" /> <img width="1619" height="1027" alt="image" src="https://github.com/user-attachments/assets/f5db715b-bc69-4505-803a-18a9b2716280" /> ## PR Checklist - [x] Closes: microsoft#48153 - [x] **Communication:** Tracked by the linked issue - [x] **Tests:** Markup-only change; Settings.UI builds clean with WinUI markup compiler (no XAML errors) - [x] **Localization:** No end-user-facing strings changed - [ ] **Dev docs:** N/A - [ ] **New binaries:** N/A - [ ] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments Files touched: - `src/settings-ui/Settings.UI/SettingsXAML/Views/ShellPage.xaml` — removed four `<InfoBadge Style="{StaticResource NewInfoBadge}" />` blocks on `GrabAndMoveNavigationItem`, `PowerDisplayNavigationItem`, and on the two parent group headers `WindowingAndLayoutsNavigationItem` and `InputOutputNavigationItem` (the parent badges existed only to surface a NEW child when the group was collapsed; with no NEW children left in those groups, the parent badges are now stale). - `src/settings-ui/Settings.UI/OOBE/ViewModel/OobeShellViewModel.cs` — flipped `(PowerToysModules.PowerDisplay, true)` to `(PowerToysModules.PowerDisplay, false)`. Grab and Move was already `false`. No other modules or strings affected. ## Validation Steps Performed - Built `src\settings-ui\Settings.UI\PowerToys.Settings.csproj` (Release|x64) with MSBuild from VS 18 Enterprise; `PowerToys.Settings.dll` produced with 0 errors related to this change. WinUI markup compiler would have aborted before producing the DLL if the XAML had syntax issues. - Diff inspected: only the five intended deletions/edits, no collateral changes. - Visual run-time verification of the Settings navigation pane is recommended before merge. Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…microsoft#48151) ## Summary of the Pull Request This updates PowerToys Settings to remove the obsolete “V2” suffix from the Shortcut Guide module name. The UI now consistently shows **Shortcut Guide**. ## PR Checklist - [ ] **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 - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 - **Settings navigation label** - Updated `Shell_ShortcutGuide.Content` to `Shortcut Guide`. - **Module title** - Updated `ShortcutGuide.ModuleTitle` to `Shortcut Guide`. - **OOBE title** - Updated `Oobe_ShortcutGuide.Title` to `Shortcut Guide`. ```xml <data name="Shell_ShortcutGuide.Content" xml:space="preserve"> <value>Shortcut Guide</value> </data> ``` ## Validation Steps Performed - N/A for behavior-level validation in this description (change is limited to localized display strings). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary of the Pull Request Adds **DiskAnalyzer** to the General plugins table in `doc/thirdPartyRunPlugins.md`. - **Plugin:** [Community.PowerToys.Run.Plugin.DiskAnalyzer](https://github.com/thetsaw/PowerToys.Plugin) - - **Author:** thetsaw - - **Keyword:** `ds` - - **License:** MIT - - **Platforms:** x64 and ARM64 ### What it does Scan any folder or drive to find the largest files and subfolders, view drive usage with visual progress bars, and navigate your filesystem all from PowerToys Run. ## PR Checklist - [x] Plugin has been publicly available - [ ] - [x] MIT licensed - [ ] - [x] Releases include x64 and ARM64 zips - [ ] - [x] plugin.json is correctly formatted - [ ] - [x] README includes install instructions ## Detailed Description This is a documentation-only change adding one row to the third-party plugins table. No source code, binaries, or build files are modified.
…menu (microsoft#48140) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Converts the "Show details" context menu command into a toggle that switches between "Show details" and "Hide details" with appropriate icons, and fixes the icon not rendering in the context menu. Address internal a11y bug. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **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 - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
…soft#48171) ## Summary Fixes microsoft#48170 — ShortcutGuide v2 crashes on launch when the bundled `Manifests` directory is absent from the install path. ### Root Cause The `Assets\ShortcutGuide\Manifests\*.yml` files were never reaching the build output directory during the CI solution-level build (`msbuild PowerToys.slnx /t:Build -graph`). The `CopyToOutputDirectory` metadata on `<Content>` items does not reliably copy files to a shared `OutputPath` in this build configuration. As a result, the WiX installer generator found no yml files to package, and the installed product was missing the Manifests directory entirely. At runtime, `PowerToysShortcutsPopulator.Populate()` threw an unhandled `FileNotFoundException` causing a crash loop. ### Fix (3 layers) 1. **Code resilience** (`Program.cs`, `PowerToysShortcutsPopulator.cs`): - Wrap `Populate()` in try/catch so a missing manifest degrades gracefully instead of crashing - Add `File.Exists` guard before `File.ReadAllText` 2. **Build output** (`ShortcutGuide.Ui.csproj`): - Add explicit `CopyManifestsToOutputDir` MSBuild target (`AfterTargets="Build"`) that copies yml files to `$(OutDir)Assets\ShortcutGuide\Manifests\` — same pattern as the existing `CopyPRIFileToOutputDir` target - Keep `<Content Include>` with `CopyToOutputDirectory` as a fallback for publish scenarios 3. **Installer packaging** (`generateAllFileComponents.ps1`, `ShortcutGuide.wxs`): - Add `*.yml` to the file inclusion list - Add `Generate-FileList` / `Generate-FileComponents` calls for `ShortcutGuideManifestsFiles` - Add WiX directory definition and `RemoveFolder` component for the Manifests directory --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
) Addenda to microsoft#47187 that fix only works if the _hwnd is already set. Actually it's crazy it ever worked. Tested by disconnecting and reconnecting RDP a couple times, which pretty consistently reproduces the problem.
…#48103) ## Summary Fixes microsoft#47821 The GPU Performance Monitor widget crashes with `IndexOutOfRangeException` on systems where GPU performance counters fail to enumerate (common on Intel Arc and hybrid GPU configurations). The dock band shows `???` and opening the flyout causes an error. ## Root Cause `GPUStats.CreateGPUImageUrl()` accessed `_stats[index]` without bounds checking. When `GetGPUPerfCounters()` finds no matching counter instances, `_stats` remains empty but callers still pass index 0. `GetGPUName()`, `GetGPUUsage()`, and `GetGPUTemperature()` already have proper guards (`if (_stats.Count <= index) return ...`) — this fix adds the same pattern to the one remaining unguarded method. ## Changes - `GPUStats.cs`: Add bounds check to `CreateGPUImageUrl()` — return empty string if index out of range Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…icrosoft#48250) ## Summary of the Pull Request Reorder the Pin to Dock dialog content so the configuration controls (monitor selector, dock section, label options) appear at the top and the live preview is shown below them. The user now configures the pin first and sees the resulting preview directly underneath, instead of staring at the preview and having to scan past it to find the controls. <img width="515" height="440" alt="image" src="https://github.com/user-attachments/assets/0d1d0543-2b30-48f5-a1aa-676a165870f5" /> ## PR Checklist - [ ] Closes: #xxx - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places ## Detailed Description of the Pull Request / Additional comments XAML-only change to `src/modules/cmdpal/Microsoft.CmdPal.UI/Dock/PinToDockDialogContent.xaml`. The new visual order inside the `ScrollViewer`/`StackPanel` is: 1. Monitor selector (still `Visibility=""Collapsed""` by default; shown when more than one monitor is available) 2. Dock section `Segmented` (Start / Center / End) 3. Label options (`Show title` / `Show subtitle` checkboxes) 4. Divider `Rectangle` 5. Preview `Border` No logic, bindings, `x:Name` identifiers, event handlers, or `x:Uid` keys are changed. ## Validation Steps Performed - Built `Microsoft.CmdPal.UI` (Debug arm64) — clean. - Verified the Pin to Dock dialog renders with controls on top and the preview underneath; segmented selection, label-option checkboxes, and the multi-monitor combo still behave as before. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…page (microsoft#48089) ## Summary When a keyboard shortcut opens CmdPal to an extension while the palette is already showing a dock-launched transient page, `GoHome(false)` cannot restore the root page — the frame's back stack is empty because the transient dock page was never pushed on top of root. The user ends up with only the hotkey-target page in the frame with no way to navigate back to the main list. ## Root Cause In `ShellPage.SummonOnUiThread()`, the hotkey-to-page branch called `GoHome(false)` before sending `ShowWindowMessage`. But when the active page is a transient dock page, `_currentlyTransient` is still `true` and the frame back stack is empty, so `GoHome` can't re-establish the root page as the frame base. ## Fix Added `ResetToHome()` to `ShellViewModel`, mirroring the pattern already used in `WindowHiddenMessage` handling: 1. Clears `_currentlyTransient` 2. Calls `_rootPageService.GoHome()` to reset extension state 3. Sends `PerformCommandMessage` for `_rootPage` — navigating MainListPage into the frame as the base In `ShellPage.SummonOnUiThread()`, the `GoHome(false)` call in the `isPage` branch is replaced with `ViewModel.ResetToHome()`. The root page is then cleanly in the frame before the hotkey target's `PerformCommandMessage` navigates on top of it. Fixes microsoft#47994 Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…soft#48098) ## Summary Fixes microsoft#47939 The Performance Monitor dock band displayed network stats as Receive → Send, but Task Manager shows Send → Receive. This swaps the order to match Task Manager. ## Changes - `PerformanceWidgetsPage.cs`: Swap `_networkUpItem` (Send) before `_networkDownItem` (Receive) in the band items array. Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…te (microsoft#48088) ## Summary When an extension updates its `Subtitle` property asynchronously after initial render, the `TextVisibilityStates` visual state group transitions from `TitleOnly` → `TextVisible`. This transition sets `SubtitleText.Visibility = Visible`, overriding the `CompactStates` setter that had hidden it. ## Fix Added `control.UpdateCompactState()` to `OnTextPropertyChanged` in `DockItemControl.xaml.cs`. This re-applies the compact state after any text property change. When `IsCompact` is `false`, `UpdateCompactState` is a no-op — no behavior change for the non-compact path. Fixes microsoft#47980 Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ring (microsoft#48085) ## Summary Fixes microsoft#46055 — Standardizes built-in fallback title/subtitle format so scoring is consistent across all action fallbacks. ## Problem `MainListPage.cs` scores fallback items by fuzzy-matching the query against both Title and Subtitle, but with different weights: - `nameScore = FuzzyScore(query, Title)` - `descriptionScore = (FuzzyScore(query, Subtitle) - 4) / 2` Fallbacks that embedded the raw query in Title got artificially higher scores than those using Subtitle. This made ranking unpredictable. ## Fix All "action" fallbacks now follow a consistent pattern: - **Title** = static action description (no query text) - **Subtitle** = raw query string (unquoted) "Result" fallbacks (that found a specific matched item) are left unchanged — they correctly show the matched item name in Title. ## Full Fallback Audit (example query: `notepad`) | Fallback | Title | Subtitle | Status | |---|---|---|---| | WebSearch: Search | "Search the web with Edge" | `Search for notepad` | **Changed** — was `Search for "notepad"` in subtitle | | WebSearch: Open URL | "Open in Microsoft Edge" | `Open notepad.com` | **Changed** — was `Open "notepad.com"` in title | | Shell: Run | "Run" | `notepad` | Unchanged — already correct | | Calculator | "3" (result) | `1+2` (query) | Unchanged — intentional exception | | Indexer: single result | "notepad.exe" | `C:\Windows\notepad.exe` | Unchanged — result fallback | | Indexer: multiple results | "File search" | `Search for notepad in files` | **Changed** — was `Search for "notepad" in files` in title | | Windows Settings: single | "Notepad settings" | `Settings > Apps` | Unchanged — result fallback | | Windows Settings: multiple | "Search Windows settings..." | `Search for notepad` | **Changed** — was `Search for "notepad" in Windows settings` in title | | Remote Desktop: exact match | "MyPC" (connection) | "Connect to MyPC" | Unchanged — result fallback | | Remote Desktop: arbitrary host | "Remote Desktop" | `Connect to notepad-host` | **Changed** — was `Connect to notepad-host` in title | | TimeDate | "Monday, May 23" (result) | "Current date" | Unchanged — result fallback | | System | "Shut down" (result) | "Shuts down the computer" | Unchanged — result fallback | | PowerToys | "Color Picker" (static) | "Pick a color..." | Unchanged — result fallback | ## Changes - `FallbackExecuteSearchItem.cs` — Subtitle uses raw query instead of `"Search for \"{query}\""` format - `FallbackOpenURLItem.cs` — Title shows browser name (was query), Subtitle shows raw query (was browser) - `FallbackOpenFileItem.cs` — Multi-result: Title is static display name, Subtitle is raw query - `FallbackWindowsSettingsItem.cs` — Multi-result: Title is static description, Subtitle is raw query - `FallbackRemoteDesktopItem.cs` — Arbitrary host: Title is static "Remote Desktop", Subtitle is raw query --------- Co-authored-by: root <root@io.bbq> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…t#48398) ## Summary Caught while reading through `BugReportTool` for an unrelated review: the two `_snwprintf_s` calls in `EventViewer.cpp` pass `sizeof(buff)` as the buffer-size argument, but `buff` is a `wchar_t[1000]`. `_snwprintf_s` measures its size and count arguments in **wide characters**, not bytes, so the current code advertises a 2000-wchar destination for a buffer that only holds 1000. `cpp wchar_t buff[1000]; // 2000 bytes, 1000 wchars memset(buff, 0, sizeof(buff)); _snwprintf_s(buff, sizeof(buff), fmt, ...); // <-- 2000 passed as wchar count ` If the formatted output ever exceeds 1000 wchars, the Secure CRT bounds check fires (in debug) and - depending on which `_snwprintf_s` overload the compiler selects against the safe template - it can write past the end of the stack buffer in release. Neither format string here is likely to produce 1000+ characters in practice (one substitutes a process name, the other a channel name + integer), so this is more of a latent footgun than a known crash, but the bounds are simply wrong. ## Fix Use `_countof(buff)` for the size argument (which is what `_snwprintf_s` actually wants - element count, not byte count) and pass `_TRUNCATE` for the count so output is safely capped at 999 wchars plus the null terminator: `cpp _snwprintf_s(buff, _countof(buff), _TRUNCATE, fmt, ...); ` Applied to both `GetQuery` and `GetQueryByChannel`. ## Scope Searched the rest of the repo for the same pattern (`_snwprintf_s(buf, sizeof(...))` / `_snprintf_s(buf, sizeof(...))`) - these two call sites are the only occurrences in the codebase. ## Validation - `BugReportTool.sln` rebuilds clean locally (Release|x64) and produces `PowerToys.BugReportTool.exe`. - No behavior change on the happy path - both formats are well under 1000 wchars in normal use. ## Risk Low. Two-line change in a single utility that builds event-log queries for bug reports. Truncation on overflow is strictly safer than the prior behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…and add holding windows button (microsoft#48683) ## Summary Refactors Shortcut Guide from two separate `WindowEx` instances (`MainWindow` + `TaskbarWindow`) into a single full-monitor transparent `OverlayWindow` that hosts both surfaces as XAML UserControls. This enables shared animations and a more polished visual experience, and makes the taskbar shortcut indicators **edge-aware** for Windows 11's top/bottom/left/right taskbar positioning. https://github.com/user-attachments/assets/e40a25f6-4ab3-4073-b1a8-906ef7782877 <img width="507" height="968" alt="image" src="https://github.com/user-attachments/assets/2e06a3d9-32d9-482e-90fe-1f0f8a7d7598" /> ## Changes Closes: microsoft#48435 Closes microsoft#48491 Closes: microsoft#49200 Closes: microsoft#48552 (theme flash on Light/System theme + shortcut-list scroll flutter) Closes: microsoft#48773 ### Architecture - **OverlayWindow**: Single transparent host covering the full monitor work area, using `TransparentTintBackdrop` - **MainPaneControl**: The shortcut list pseudo-window, reusing the shared `TransientSurface` control for chrome (acrylic backdrop, theme shadow, rounded corners) - **TaskbarPaneControl + TaskbarIndicator**: Tooltip-style indicators with triangle tails, positioned above taskbar buttons ### Edge-aware taskbar indicators (Windows 11 top/bottom/left/right) - Detects the taskbar edge via the public, documented `SHAppBarMessage` / `ABM_GETTASKBARPOS` API (the same API CmdPal Dock uses) - Indicators lay out along the correct axis — horizontally for a top/bottom taskbar, vertically for a left/right taskbar — with the triangle tail always pointing toward the taskbar (4-direction tail + per-edge slide-in animation) - For a left/right taskbar, the main pane is inset so the order reads **taskbar | indicators | pane** - **Adaptive sizing**: each indicator's body size is derived from the actual measured UIA taskbar button rect, so the bubbles shrink when Windows uses small icons or combines buttons (many apps open). Uses the smallest button slot (clamped to a readable range) so neighbouring bubbles never overlap; the font scales with it ### Visual polish - Windows 11 system flyout entry/exit animations (slide + fade, ~367ms entrance / ~200ms exit with cubic easing) - Animation direction is position-aware (slides from left when left-aligned, from right when right-aligned) - Taskbar indicators slide in from the taskbar edge with the same timing - Close button on the main flyout title bar ### Robustness - Multi-monitor DPI handling via WM_DPICHANGED suppression (prevents double-scaling on cross-monitor moves) - Win11 phantom border elimination (comprehensive DWM/style stripping) - Click-outside-to-close with animated exit transition - Process lifetime fix (`Application.Current.Exit()` on close) ## Validation - Build clean (x64 Debug, exit 0, empty errors log) - Tested on multi-monitor mixed-DPI setup (150% + 100%) - Tested with the taskbar docked to each edge (top/bottom/left/right) and with small/combined taskbar icons --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Noraa Junker <noraa.junker@outlook.com> Co-authored-by: Clint Rutkas <clint@rutkas.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary of the Pull Request This PR improves performance of Window Walker, to make it faster (or at least make it look like it is faster). - Adds cached Window Walker list items and window snapshots for faster page loading. - Changes window enumeration to refresh asynchronously without blocking initial results. - Adds lazy, sequential icon loading with cached icon data. - Reuses existing list items when window metadata changes. - Fixes incorrect destruction of borrowed window icon handles. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#49315 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **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 - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
…race (microsoft#46973) Narrows this PR to @yeelam-gordon's review feedback. The wait-for-exit before launching the installer is **already in `main`** (landed separately), so the original change here is now redundant. What's **not** in main is the PID-recycle hazard Gordon flagged, so this PR applies just that fix: Open the PowerToys process handle **before** sending `WM_CLOSE`. PowerToys can exit inside its own `WM_CLOSE` handler, after which the OS may recycle its PID — opening by PID afterwards could then fail or attach to an unrelated process that reused it, and `WaitForSingleObject` would wait on the wrong thing. Holding the handle first anchors the kernel object to the original process, so PID reuse is impossible while we wait on it. Rebased onto latest `main` (resolves the previous merge conflict). Originally fixes microsoft#46966. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds an Awake module-services unit-test seed for runtime state creation from timed settings. This is product/module coverage, not Settings UI model serialization.\n\nValidation:\n- Restored and built Awake.ModuleServices.UnitTests x64 Debug\n- Ran the filtered test CreateState_TimedSettings_ReturnsTimedStateWithDuration: 1 passed Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nch crash (0xC0000409) (microsoft#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: microsoft#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 microsoft#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) <yuleng@microsoft.com> Co-authored-by: Claude <noreply@anthropic.com>
## Summary of the Pull Request Updates `SharpCompress` from **0.37.2** to **0.50.1** (latest listed stable) and migrates Peek's `ArchivePreviewer` to the renamed APIs. 0.37.2 is subject to [GHSA-6c8g-7p36-r338](GHSA-6c8g-7p36-r338) (moderate severity), which currently produces an `NU1902` warning on restore. This upgrade clears it. The bump also required a real behavioral fix: `.tar.gz` / `.tgz` previews break outright on 0.50.1 without it. Details below. ## PR Checklist - [ ] Closes: #xxx <!-- N/A: no tracking issue, this is a dependency/security bump --> - [ ] **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 <!-- See "Validation Steps Performed" - Peek has no unit test project today, so this was validated with a differential harness. Happy to add coverage if desired. --> - [x] **Localization:** All end-user-facing strings can be localized <!-- N/A: no strings added or changed --> - [ ] **Dev docs:** Added/updated <!-- N/A --> - [ ] **New binaries:** Added on the required places <!-- N/A: no new binaries. SharpCompress.dll already ships with Peek; only its version changes. --> - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 <!-- N/A --> ## Detailed Description of the Pull Request / Additional comments Two files change: **`Directory.Packages.props`** - central version pin moves `0.37.2` to `0.50.1`. `Peek.FilePreviewer.csproj` needs no edit because its `PackageReference` is versionless under Central Package Management. **`src/modules/peek/Peek.FilePreviewer/Previewers/Archives/ArchivePreviewer.cs`** - the only SharpCompress consumer in the repo. ### API renames Verified by reflecting over the shipped 0.50.1 assembly rather than guessing: | 0.37.2 | 0.50.1 | |---|---| | `ArchiveFactory.Open(...)` | `ArchiveFactory.OpenArchive(...)` | | `ReaderFactory.Open(...)` | `ReaderFactory.OpenReader(...)` | | `IArchive.TotalUncompressSize` | `IArchive.TotalUncompressedSize` | `ArchiveEncoding`, `ReaderOptions.Forced`, and `IEntry.Key`/`Size`/`IsDirectory` are unchanged, so the existing zip CP437 encoding-probe logic ported over without modification. ### Behavioral fix: `.tar.gz` / `.tgz` The renames alone are not sufficient. On 0.50.1, `ArchiveFactory.OpenArchive` can no longer open a gzip-compressed tar as a random-access archive; it throws `ArchiveOperationException: Cannot determine compressed stream type`. On 0.37.2 the same call succeeded and returned `type=Tar`. I probed six alternatives before settling on a fix: `OpenArchive(path)`, `ExtensionHint="tar.gz"`, `ExtensionHint=".tar.gz"`, `LookForHeader=true`, the `FileInfo` overload, and `OpenReader`. Only `ReaderFactory.OpenReader` works. The branch is now forward-only through `OpenReader`, and the `OpenArchive` + `stream.Seek(0)` preamble is removed. This path is user-reachable, so the break would have shipped: `FileItem.Extension` returns `.gz` for `foo.tar.gz`, and `.gz` is in `_supportedFileTypes`, so Peek does preview these files. ### Incidental correctness fix While rewriting that branch, the reported size changes. The old code used `archive.TotalUncompressSize`, which for a `.tar.gz` reported the size of the intermediate **tar container** rather than the sum of the entries. It now accumulates `reader.Entry.Size`, so the footer count/size line is correct for these archives. ## Validation Steps Performed `Peek.FilePreviewer` builds clean (x64 Release) resolving SharpCompress 0.50.1. Peek has no unit test project, and the only archive coverage in `Peek.UITests` is `Peek.FilePreview.ZIPArchive`, which previews `TestAssets\7.zip` and asserts via screenshot comparison. There is no `.tar.gz` test asset, so nothing in the existing suite would have caught the regression above. Given that, I validated with a standalone differential harness that replicates `LoadPreviewAsync` verbatim and runs it against **both** 0.37.2 and 0.50.1 over the same set of archives, comparing entry names and sizes: | Archive | 0.37.2 | 0.50.1 | |---|---|---| | `test.zip` | `sub/nested.txt (19)`, `hello.txt (11)`, total 30 | identical | | `utf8.zip` | names correct | names correct | | `sjis.zip` | `日本語/テスト.txt` correct | identical | | `short.zip` | `caf‚.txt`, `na‹ve.md`, `a¤o.log` (mangled, detected windows-1252) | `café.txt`, `naïve.md`, `año.log` (correct, detected utf-8) | | `test.tar.gz` | opens, total 4096 (container size) | opens, total 30 (correct) | | `test.tar` | ok | ok | | `hello.gz` | ok | ok | All entry names and sizes match. 0.50.1 is strictly more correct on short non-ASCII entry names and on `.tar.gz` sizing. One subtle difference worth flagging for reviewers: on `utf8.zip`, 0.50.1 honors `ArchiveEncoding.Forced` even for UTF-8-flagged zips, so the strict CP437 round-trip no longer throws and `encodingDetermined` comes back `false` where it was `true` before. The decoded names are still correct, because charset detection then correctly identifies UTF-8. No tested case produced wrong output. Manual validation: previewed `.zip`, `.tar`, `.tar.gz`, and `.gz` files in Peek. `NOTICE.md` lists SharpCompress by name without a version, so it needs no update. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: cb1e58a5-de5b-420e-8153-ef9b15810211
Adds the C++ counterpart to microsoft#48346: a focused Runner native unit-test seed for core hotkey conflict behavior. Why this one: - Runner is core infrastructure rather than another C# module test. - It adds the missing native C++ test-project path for Runner. - The seed test is deterministic and covers in-app hotkey conflict detection. - It keeps the active rollout to two PRs: one C# module-services PR (microsoft#48346) and one C++ core/runner PR. Validation: - `tools\build\build.ps1 -Platform x64 -Configuration Debug -Path src\runner\UnitTests` - `vstest.console.exe x64\Debug\tests\Runner\Runner.UnitTests.dll /Tests:HasConflict_TwoModulesSameHotkey_InAppConflict` → 1 passed --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Removing a warning that pops up a lot. **With fix:** <img width="694" height="674" alt="image" src="https://github.com/user-attachments/assets/2a496935-0d4b-45e6-97f2-62b8d4004faa" /> **Without fix:** here it is commented out to show the warning. <img width="1033" height="654" alt="Screenshot 2026-06-30 111523" src="https://github.com/user-attachments/assets/5d8f5df9-3c45-4155-a995-4b666df894fd" /> Found conflicts between different versions of "WindowsBase" that could not be resolved. There was a conflict between "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "WindowsBase, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "WindowsBase, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not. References which depend on "WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref\net10.0\WindowsBase.dll]. C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref\net10.0\WindowsBase.dll Project file item includes which caused reference "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref\net10.0\WindowsBase.dll". C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\10.0.8\ref/net10.0/WindowsBase.dll References which depend on or have been unified to "WindowsBase, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" []. C:\Users\crutkas\.nuget\packages\microsoft.web.webview2\1.0.3719.77\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll Project file item includes which caused reference "C:\Users\crutkas\.nuget\packages\microsoft.web.webview2\1.0.3719.77\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll". C:\Users\crutkas\.nuget\packages\microsoft.web.webview2\1.0.3719.77\buildTransitive\..\\lib_manual\net5.0-windows10.0.17763.0\Microsoft.Web.WebView2.Wpf.dll
## Summary Adds a **Peek.Common.UnitTests** project (MSTest) with unit coverage for Peek.Common.Helpers: - **MathHelper.Modulo** — positive/zero results, negative-dividend wrap-around, large values, and the new non-positive-divisor guard. - **MathHelper.NumberOfDigits** — single/multi-digit, negative, and 9/10 & 99/100 boundary values. - **PathHelper.IsUncPath** — standard UNC, subfolders, dotted-server and IP hosts, plus negatives: drive-letter, relative, empty, HTTP URL, ile:// URI, single backslash, and null. Also adds a small correctness guard to MathHelper.Modulo: a non-positive divisor now throws ArgumentOutOfRangeException instead of silently throwing DivideByZeroException (b == 0) or returning a misleading result (b < 0). Registers the test project in `PowerToys.slnx` (ARM64 + x64). **37 tests pass** locally (x64 Debug). ## Context This is a clean, **tests-only split of microsoft#46684** (the Peek.Common portion), intentionally **without** the bundled global dependency bump from that PR. The PowerAccent.Core portion of microsoft#46684 was shipped separately in microsoft#49104. ## Test coverage | Area | Tests | |------|-------| | MathHelper.Modulo / NumberOfDigits | included | | PathHelper.IsUncPath | included | No production behavior changes beyond the Modulo argument guard, which is covered by the new tests. Co-authored-by: Clint Rutkas <crutkas@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
) ## Summary Corrects `IContextMenu::GetCommandString` handling in the Image Resizer shell extension. ## Changes - `GCS_VERBW` copies the Unicode canonical verb with `StringCchCopyW`, preserving copy failures. - Only `GCS_VALIDATEA` and `GCS_VALIDATEW` return `S_OK`. - ANSI verb requests, help-text requests, and unknown request types return `E_NOTIMPL`. - ANSI string verbs are intentionally not advertised because `InvokeCommand` cannot execute them. - Updates spell-check expectations for the Windows constants used by this implementation. ## Validation The authoritative local versions of all three changed files are pushed together. A Windows build was not run in this Linux environment. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
…osoft#48394) ## Summary Fixes a ThreadPool worker leak in PowerToys Run that can eventually surface as `System.OutOfMemoryException` from `Thread.StartInternal` after rapid typing and repeated stale-query cancellation. Related: microsoft#36041 and duplicate reports microsoft#45704, microsoft#36587, microsoft#39942, microsoft#20264, and microsoft#8878. ## Root cause `MainViewModel.QueryResults` stored the active cancellation token in a mutable field. When a new query replaced that field, older workers could observe the new, non-cancelled token instead of the token belonging to their own query. The previous `CancellationTokenSource` was also disposed while its consumers could still be running. As stale queries accumulated, they continued invoking plugins and consuming ThreadPool workers until the process could no longer create another worker thread. ## Changes - Adds `QuerySession`, which owns one captured token and the complete task lifetime for a query. Superseded sessions are cancelled immediately and their token sources are disposed only after their work completes. - Uses a suspended session start so query state is published before workers can return results. - Adds generation checks before scheduling and applying work so superseded queries cannot enqueue stale plugin tasks or update current results. - Adds a per-plugin execution gate. Calls to the same plugin do not overlap, while unrelated plugins can execute independently; cancelled waiters do not occupy ThreadPool workers. - Preserves legacy `IResultUpdated` compatibility by correlating generation-0 events using `RawQuery`. - Preserves the original two-phase query contract: all non-delayed plugin queries complete and their results are applied before delayed queries start. Delayed queries remain globally parallel, and `noInitialResults` is computed from the complete non-delayed phase. - Cancels and performs a bounded wait for the active query during shutdown. ## Tests `Wox.Test`: **142/142 passing** locally. Coverage includes: - token ownership, cancellation, deferred disposal, shutdown timeout, and suspended session startup; - current-query generation matching and legacy generation-0 compatibility; - per-plugin execution gating and queued latest-query behavior; - deterministic verification that delayed queries cannot start until every non-delayed query completes. ## Manual validation 1. Hold a key in PowerToys Run for 10–15 seconds and confirm the PowerToys Run process thread count stabilizes instead of growing monotonically. 2. Exercise normal Calculator, file, web, and indexer queries. 3. Enable search query tuning and waiting for slow results; confirm results appear and final sorting completes. 4. Start a slow query and type again before it completes; only the newest query should update results. 5. Exit PowerToys with a query in flight; shutdown should complete cleanly without orphaned processes. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Copilot-Session: 54e1bb28-edae-496b-8211-0e1592ddc985
…ocking shutdown cleanup (microsoft#48363) ## Summary The runner WndProc (`tray_icon_window_proc`) does not handle `WM_QUERYENDSESSION` / `WM_ENDSESSION`, **and** its `WM_DESTROY` teardown performs blocking cross-process cleanup. Both contribute to the Watson failure `APPLICATION_HANG_QUIESCE_cfffffff_PowerToys.exe!run_message_loop` on OS shutdown, sign-out, or restart: 1. Without a `WM_ENDSESSION` handler, `DefWindowProc` returns `0` without posting a quit message, so `run_message_loop` stays parked in `GetMessageW` until the OS quiesce timeout (~5 s) force-terminates the process. 2. Even once teardown starts, `WM_DESTROY` calls `close_settings_window()`, which blocks up to 1.5 s on `WaitForSingleObject` against `PowerToys.Settings.exe` (`src/runner/settings_window.cpp:712`), plus `Shell_NotifyIcon(NIM_DELETE)` during Explorer teardown. The Windows [shutdown guidance](https://learn.microsoft.com/windows/win32/shutdown/shutting-down) is explicit that handlers must not block. This PR fixes both issues for the always-on runner. Rollout to module-owned windows is intentionally separate and tracked in microsoft#49539. > Supersedes microsoft#48378 (same Watson bucket) by combining its no-blocking-cleanup fix with a reusable helper and unit tests. The cleanup-skip insight is credited to @yeelam-gordon. Related (same failure class, different binary): microsoft#41260. ## Root cause `src/runner/tray_icon.cpp` → `tray_icon_window_proc` had no case for `WM_QUERYENDSESSION` / `WM_ENDSESSION`, and `WM_DESTROY` unconditionally ran cross-process cleanup. On a full Windows session end, the OS delivers `WM_ENDSESSION` to child applications and reaps them independently, so the runner's waits consume the quiesce budget without helping shutdown complete. ## Fix ### 1. Explicitly stateless helper in `src/common/utils/window.h` `handle_stateless_session_end_message`: - `WM_QUERYENDSESSION` → returns `TRUE`. The name makes clear that this helper is only for processes with no unsaved user state. - `WM_ENDSESSION(TRUE)` → calls `DestroyWindow(window)`, driving the existing `WM_DESTROY → PostQuitMessage(0)` path so `run_message_loop` unwinds. - `WM_ENDSESSION(FALSE)` → leaves the window alone because another application cancelled shutdown. - The optional `out_system_session_ending` flag is set only when the full Windows session is ending. `ENDSESSION_CLOSEAPP` still closes the runner but leaves the flag false so Restart Manager requests retain normal child-process cleanup. Stateful modules must implement their own save/permission behavior rather than adopt this helper. `tray_icon_window_proc` calls it at the top of dispatch and returns immediately when the message is handled. ### 2. Skip blocking cleanup only for a full Windows session end `WM_DESTROY` branches on `g_system_session_ending`: - **User-initiated close or Restart Manager `ENDSESSION_CLOSEAPP`:** unchanged full cleanup (`Shell_NotifyIcon(NIM_DELETE)`, `close_settings_window()`, and `QuickAccessHost::stop()`). - **Full OS shutdown, sign-out, or restart:** posts `WM_QUIT` without waiting on child processes the OS is already reaping in parallel. ### Scope and follow-up This PR intentionally fixes the highest-volume contributor: the always-on runner. Native module processes with their own windows/message loops require module-specific review before adopting the pattern; that inventory and rollout is tracked in microsoft#49539. ### Why not centralize handling inside `run_message_loop`? `WM_QUERYENDSESSION` / `WM_ENDSESSION` invoke the WndProc directly during `GetMessage`; they do not appear as a `MSG` returned to the loop. Handling must therefore live in, or be called from, each relevant WndProc. ## Tests 8 focused tests in `src/common/UnitTests-CommonUtils/Window.Tests.cpp`: | Test | Guards | |---|---| | `HandleStatelessSessionEndMessage_QueryEndSession_AllowsShutdown` | `WM_QUERYENDSESSION` returns `TRUE`. | | `HandleStatelessSessionEndMessage_EndSessionCancelled_DoesNotTearDown` | `WM_ENDSESSION(FALSE)` does not destroy the window. | | `HandleStatelessSessionEndMessage_EndSessionConfirmed_TearsDownAndExitsLoop` | `WM_ENDSESSION(TRUE)` destroys the window and exits before the longer timer fallback. | | `HandleStatelessSessionEndMessage_UnrelatedMessage_NotHandled` | Unrelated messages fall through untouched. | | `HandleStatelessSessionEndMessage_EndSessionConfirmed_SignalsSystemSessionEnding` | A full session end enables the no-wait teardown path. | | `HandleStatelessSessionEndMessage_CloseApp_DoesNotSignalSystemSessionEnding` | Restart Manager closes the window while retaining normal child cleanup. | | `HandleStatelessSessionEndMessage_EndSessionCancelled_DoesNotSignalSystemSessionEnding` | Cancelled shutdown does not flag teardown. | | `HandleStatelessSessionEndMessage_QueryEndSession_DoesNotSignalSystemSessionEnding` | The query phase does not flag teardown. | **Build:** `runner.vcxproj` and `UnitTests-CommonUtils.vcxproj` build clean (`x64|Release`). The 8 focused tests pass. ## Manual validation 1. Build PowerToys and start the runner. 2. Initiate a sign-off (`logoff`) or restart. 3. Confirm Event Viewer (`Windows Logs → Application`) shows no `Application Hang` event for `PowerToys.exe`. 4. Right-click tray → Exit: confirm Settings.exe and the Quick Access host shut down gracefully and no ghost tray icon remains. (microsoft#48378 additionally captured real logoff/restart runs showing `WM_ENDSESSION → WM_DESTROY` completing in 1–8 ms with no hang events—the same full-session path used here.) ## Quality checklist - [x] Linked work item: AB#55588441 - [x] Module follow-up: microsoft#49539 - [x] Cross-references microsoft#41260; supersedes microsoft#48378 - [x] Unit tests (8 in `Window.Tests.cpp`) - [x] No new binaries - [x] Localization: no end-user strings changed - [x] Shared helper documents its stateless contract Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8d70b986-081a-43dd-bbfd-7e6351baef7a
## Summary of the Pull Request Updates the vendored Monaco Editor from 0.47.0 (Mar 2024) to 0.52.2 (Dec 2024). ## PR Checklist - [x] **Communication:** Discussed in microsoft#46692 review - [x] **Tests:** Headless-browser smoke tests pass (syntax highlighting, custom languages, context-menu hack, addAction registration) - [x] **Dev docs:** No doc changes needed (update process unchanged) ## Detailed Description ### What changed | Area | Detail | |------|--------| | `src/Monaco/monacoSRC/min/` | Replaced with `monaco-editor@0.52.2` from npm | | NLS layout | `editor.main.nls.*.js` / `simpleWorker.nls.*.js` removed upstream → `vs/nls.messages.*.js` added | | New language | `typespec` shipped upstream (+1 language, 100→101 total) | | `monacoSpecialLanguages.js` | Inline grammar snapshots (cpp/xml/razor/vb/ini/shell) refreshed from 0.52.2 shipped files | | `monaco_languages.json` | Regenerated; all PowerToys custom languages + extension mappings intact | ### Supply-chain verification - npm tarball SHA-512 verified against registry SRI: `sha512-GEQWEZmfkOGLdd3XK8ryrfWz3AIP8YymVXiPHEdewrUq7mh0qrKrfHLNCXcbB6sTnMLnOZ3ztSiKcciFUkIJwQ==` - Vendored tree hash-verified file-by-file (103 files, all match) ### Why 0.52.2 and not 0.55.1 (latest)? Monaco 0.53+ completely restructured the `min/` bundle: flat hashed chunks instead of per-language AMD modules, `vs/platform/actions/common/actions` removed, `vs/basic-languages/<id>/<id>` modules eliminated. PowerToys' `index.html` (context-menu stripping via MenuRegistry) and `monacoSpecialLanguages.js` (language cloning via AMD require) depend on these internals. **0.52.2 is the last release compatible without a glue-code rewrite.** The 0.55.x port is tracked separately. ## Validation Steps Performed - [x] Tarball SRI integrity verified against npm registry - [x] Vendored tree == tarball (SHA-256 per file, 103/103 match) - [x] `monacoSpecialLanguages.js` passes Node.js syntax check - [x] Headless smoke test (Edge via puppeteer-core): editor creates, tokenization paints (5+ classes), `addAction` entries register, `MenuRegistry` context-menu hack works - [x] Same smoke test passes identically on 0.47.0 baseline (no regressions) - [x] `monaco_languages.json`: 101 languages, all custom IDs present (reg, gitignore, srt, cppExt, xmlExt, txtExt, razorExt, vbExt, iniExt, shellExt) ## Related - Supersedes automation approach in microsoft#46692 (which has fatal bugs; will close separately) - 0.55.x port tracked as follow-up issue Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6bd2181-eff3-4f2a-b25e-dcd1065ead6a
## Summary Adds [Quick Shell](https://github.com/tonythethompson/QuickShell) to the community PowerToys Run plugins list. - **Plugin:** Quick Shell (`qs` keyword) - **Author:** [tonythethompson](https://github.com/tonythethompson) - **Description:** Open saved project folders in any terminal; shared shortcuts with the Quick Shell Command Palette extension ## Install - WinGet (bundled CmdPal + Run): `winget install tonythethompson.QuickShell` - Run-only ZIP: [`QuickShell.Run-x64.zip`](https://github.com/tonythethompson/QuickShell/releases/latest) / [`QuickShell.Run-ARM64.zip`](https://github.com/tonythethompson/QuickShell/releases/latest) - Run-only EXE: `QuickShellforRun-Setup-*-x64.exe` / `*-arm64.exe` from the same release Docs: https://github.com/tonythethompson/QuickShell/blob/master/docs/powertoys-run-plugin.md ## Validation - [x] Listed under General plugins - [x] Links to GitHub repo and author profile - [x] Release assets include Run plugin ZIP and installer Made with [Cursor](https://cursor.com) Co-authored-by: Anthony Thompson <>
…ash if key is empty or invalid (microsoft#49562) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: microsoft#49558 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **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 - [x] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **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 <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
microsoft#49578) ## Summary of the Pull Request `DdcCiController.DiscoverFromHandleAsync` abandons a physical monitor on three paths without destroying its handle. Handles only reach `PhysicalMonitorHandleManager` through monitors that were successfully built: the map is rebuilt from the returned monitor list, and its cleanup pass only destroys handles that were in the *previous* map. A handle dropped on an abandon path therefore never gets destroyed. A discovery runs on every display-topology change, so a monitor that keeps failing leaks one more handle per discovery for the process lifetime — a docking-station user accumulates them. Extracted from microsoft#49445, where the same fix is bundled with maximum-compatibility-mode work it does not depend on. ## PR Checklist - [ ] Closes: #xxx — no issue; extracted from microsoft#49445 - [ ] **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 — none added; rationale below - [x] **Localization:** All end-user-facing strings can be localized — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### The three leaking paths | path | before this PR | | --- | --- | | more physical monitors than `QueryDisplayConfig` entries for the GDI name | `break` leaves `physicals[i..]` unreleased — the whole tail, not just the current one | | capabilities unavailable | `continue` | | `BuildMonitorFromPhysical` returned null (construction failed, or it threw and was caught) | no `else` branch at all | `ReleaseAbandonedPhysical` is null-handle safe and swallows a failing `DestroyPhysicalMonitor` at warn level: one handle that cannot be destroyed must not take down the rest of the discovery pass. ### Why there are no tests Reaching these call sites means faking the whole native enumeration surface — `EnumDisplayMonitors`, `GetMonitorInfo`, `GetPhysicalMonitorsFromHMONITOR` — which is a larger seam than a one-file leak fix should introduce. The paths were verified by reading instead. Happy to add the seam if a maintainer would rather have it covered. ### Known remaining leaks, deliberately out of scope - `GetPhysicalMonitorsWithRetryAsync`'s retry loop discards a whole array of live handles when it retries after seeing NULL handles. - Cancellation unwinds `DiscoverMonitorsAsync` before `UpdateHandleMap` runs, so that pass's handles never enter the map and are never destroyed. Both predate this change and are better addressed separately. ## Validation Steps Performed - built `PowerDisplay.Lib` and `PowerDisplay.Lib.UnitTests` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **186 passed, 0 failed** — no new tests; this only confirms nothing regressed - no hardware validation performed: reaching an abandon path needs a monitor whose capabilities fetch fails or whose construction throws Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
…tings (microsoft#49577) ## Summary of the Pull Request `TryRestore` skipped writing a saved monitor value when it already equalled the value `MonitorViewModel` was showing. That displayed value is only an observation when the discovery-time VCP read succeeded. When the read failed it is a placeholder: | setting | value when the read failed | source | | --- | --- | --- | | brightness | `50` | `MonitorDiscoveryHelper` stamps it — *"Initial placeholder; overwritten if the VCP read succeeds"* | | contrast | `50` | `Monitor` backing-field default | | volume | `50` | `Monitor` backing-field default | | color temperature | `0x05` (6500K) | `Monitor` backing-field default | A saved value that happened to equal one of those silently suppressed the restore, and the monitor kept whatever it powered on with. `50` is the mid-slider value and `0x05` is the most common preset, so the coincidence is not rare. This drops the comparison: a restore now always writes. ## PR Checklist - [ ] Closes: #xxx — no issue; found while splitting up microsoft#49445 - [ ] **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 — none added; `TryRestore` is a private helper in the `PowerDisplay` app project, which has no test project - [x] **Localization:** All end-user-facing strings can be localized — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### Why remove the check rather than refine it The skip-if-equal check dates from PowerDisplay's first commit (microsoft#42642, where it read `// Restore brightness if different from current`); microsoft#47051 only refactored it into the shared `TryRestore` helper. It is day-one "obviously we shouldn't write twice" code, not a response to a reported problem. Removing it is correct by construction: with no skip branch there is no state in which a restore silently does nothing. Any narrower fix has to decide *when* the displayed value can be trusted, and gets that decision wrong in exactly the cases that are hardest to reproduce. ### Cost Two, both bounded: - **A redundant VCP write when the monitor already sits at the saved value.** Some panels surface a write on their OSD. Both paths that reach here are user-initiated: startup restore only runs when `RestoreSettingsOnStartup` is enabled, and a profile apply happens because the user invoked that profile. - **Time.** At most four writes per monitor, serialised on that monitor's I2C bus (~100 ms each). Monitors still run in parallel through the existing `Task.WhenAll`. The `isVisible` guard is untouched, so a monitor still never receives a write for a feature it does not expose — an unsupported VCP `0x14` is not written just because a profile carries a color temperature. Input source and power state are not restored here at all. ### If the redundant write turns out to matter The narrower fix is to keep the comparison and add one clause: also write when `(monitor.ReadValues & flag) != flag`, i.e. when the compared value was never read off the hardware. `MonitorReadFlags` already carries exactly that information, and `Monitor.ReadValues` is already maintained by the discovery-time `Initialize*` methods, so it is a small change on top of this one. I went with the simpler version first — happy to switch if a maintainer would rather keep the optimisation. ## Validation Steps Performed - built `PowerDisplay` and `PowerDisplay.Lib.UnitTests` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **186 passed, 0 failed** — unchanged from `main`; this PR touches only the app project and adds no tests - no hardware validation performed: the placeholder path this PR fixes is reachable only on a monitor whose VCP read fails during discovery Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
…crosoft#48903) ## Summary PowerToys' self-updater downloads the installer into `%LOCALAPPDATA%\Microsoft\PowerToys\Updates` and then launches it from `PowerToys.Update.exe` (Stage 2). This makes that launch path more robust: - Open the downloaded installer with a read-only share so the file stays consistent while we inspect and run it. - Confirm it is a valid, Authenticode-signed **Microsoft** PowerToys installer (valid signing chain + Microsoft organization) before executing it. This single chokepoint covers both freshly downloaded and previously downloaded installers. - If the check does not pass, log and skip the launch instead of running an incomplete or invalid file. ## Implementation - Added `updating::verify_installer_trust` to the shared `common/updating` library (`installer.h` / `installer.cpp`): `WinVerifyTrust` for the signing chain, and `CryptQueryObject` / `CertGetNameString` to confirm the signer's organization is `Microsoft Corporation`. `Wintrust.lib` / `Crypt32.lib` are linked via `#pragma comment(lib, ...)`. - `InstallNewVersionStage2` opens the installer with `FILE_SHARE_READ`, verifies it, and keeps the handle open across `MsiInstallProductW` / the bootstrapper launch so the file stays stable during install. ## Validation - `ApplicationUpdate` and `PowerToys.Update` build clean (x64 Debug). - Existing updating unit tests pass (30/30). - Checked end-to-end against real binaries: a Microsoft Authenticode-signed binary is accepted; a corrupted copy and an unsigned file are both declined. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Muyuan Li <muyuanli@microsoft.com> Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com> Copilot-Session: d168a794-8cce-483d-9c46-10787893dbe2
…rosoft#49579) ## Summary of the Pull Request In Maximum compatibility mode, when a monitor's capabilities string is missing or unparsable, discovery falls back to probing each continuous VCP code directly. That probe issues **one** `GetVCPFeatureAndVCPFeatureReply` per code, back to back, and treats any failure as final. On a panel whose DDC/CI engine answers intermittently, a single transient I2C fault permanently drops that control for the whole discovery pass — and if every code happens to fault, the monitor disappears from the flyout entirely. This replaces the probe with `VcpFeatureProbeService`: - **paced** — 100 ms between transactions, instead of hammering the I2C bus back to back - **retried** — up to 3 attempts, but only for failures another attempt can plausibly get past - **classified** — `DdcErrorClassifier` decides what "transient" means, so the retry budget is not burned on a definitive `DDCCI_VCP_NOT_SUPPORTED` or on a dead physical-monitor handle - **aborted early** — a handle-class error stops the remaining codes rather than issuing more requests against a handle already known to be invalid Extracted from microsoft#49445, which bundles this with a persisted discovery cache and a discovery restructure it does not depend on. This piece stands alone and addresses one of the root causes in microsoft#49342 by itself. ## PR Checklist - [ ] Closes: #xxx — partially addresses microsoft#49342; the remaining causes are in microsoft#49445 - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized — this PR adds none - [ ] **Dev docs:** Added/updated - [x] **New binaries:** Added on the required places — none added; no new project, so no signing JSON, installer WXS or CI YML change is required - [ ] **Documentation updated** ## Detailed Description of the Pull Request / Additional comments ### What is and is not retried `DdcErrorClassifier` names the DDC/CI error codes after `winerror.h` and splits them into two sets. `DdcErrorClassifierTests` pins both the membership of each set **and** the numeric value of every constant against `winerror.h`, so a typo cannot move production and tests together and leave the suite green. Retried — framing, arbitration and timing faults on the I2C bus: `I2C_ERROR_TRANSMITTING_DATA`, `I2C_ERROR_RECEIVING_DATA`, `DDCCI_INVALID_DATA`, `MCA_INTERNAL_ERROR`, `DDCCI_INVALID_MESSAGE_COMMAND`, `DDCCI_INVALID_MESSAGE_LENGTH`, `DDCCI_INVALID_MESSAGE_CHECKSUM`, `DDCCI_CURRENT_CURRENT_VALUE_GREATER_THAN_MAXIMUM_VALUE`, `ERROR_TIMEOUT`. Not retried, each for a stated reason recorded on the predicate: `DDCCI_VCP_NOT_SUPPORTED` is the device's final answer; `I2C_NOT_SUPPORTED` and `I2C_DEVICE_DOES_NOT_EXIST` are permanent bus-level facts; `MCA_INVALID_CAPABILITIES_STRING` belongs to the capabilities path, not to a VCP read; and the two handle-class codes must abort rather than retry. ### Behaviour preserved `FetchCapabilitiesWithFallbackAsync` keeps its signature and still returns `(string, VcpCapabilities?)`, so nothing outside the probe changes. `BuildCapabilitiesFromProbe` synthesizes the same shape `DdcCiNative.ProbeSupportedVcpFeatures` used to, and decides membership the same way: a code counts as supported when the device *replied*, not when the value was usable. A reply proves the opcode is implemented even if the reported range cannot scale a percentage — an unimplemented code fails with `DDCCI_VCP_NOT_SUPPORTED` instead. The set of probed codes moves from a private array in `DdcCiNative` to `NativeConstants.ContinuousVcpCodes`, where the follow-up work in microsoft#49445 also needs it. ### Cost The probe only runs in Maximum compatibility mode, and only when the capabilities string is already unusable — so this adds no I2C traffic to a monitor that parses normally. For a monitor that does reach it, the worst case grows from 3 transactions to 9 plus 900 ms of pacing, and it is bounded: a definitive refusal stops after one attempt, and a handle-class error stops the whole probe. ### What is deliberately left out The probe's values are still discarded — `BuildMonitorFromPhysical` re-reads each code immediately afterwards. Reusing them needs a carrier for the observed value, which is `VcpDiscoveryEvidence` in microsoft#49445. `VcpFeatureProbeService` already returns everything that needs (`VcpProbeObservation` carries the value, the attempt count and the last error); this PR simply does not consume it yet. ## Validation Steps Performed - built `PowerDisplay.Lib.UnitTests` for x64 Debug with VS MSBuild — 0 errors, 0 warnings - ran `PowerDisplay.Lib.UnitTests.dll` with `vstest.console.exe`: **223 passed, 0 failed** (186 on `main` + 37 added here) - `VcpFeatureProbeServiceTests` drives the pacing, the retry budget, the transient/definitive split, cancellation before and during the inter-transaction delay, a throwing native read, and that reads run off the caller's thread — all through an injected reader and an injected delay, so no hardware is needed - no hardware validation performed: reaching this path needs a panel whose capabilities string is unusable **and** whose VCP reads fail intermittently --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
…skipped (microsoft#49580) ## Summary of the Pull Request PowerDisplay's tray context menu **Exit** ended the process with `Environment.Exit(0)`, skipping the teardown that `App.Shutdown()` already performs. Point it at `Shutdown()` instead — a one-line change. What Exit was skipping: - `TrayIconService.Destroy()` — `Shell_NotifyIcon(NIM_DELETE)`, the icon and popup-menu handles, and restoring the subclassed window procedure. Without the `NIM_DELETE`, the notification area can keep showing a stale PowerDisplay icon until the Shell next validates it, which in practice is when the pointer passes over it. - `MainWindow.Dispose()` — which cancels the CLI named-pipe server's `CancellationTokenSource` and disposes the hotkey service, the message hook and `MainViewModel` (monitor manager, display-change watcher, per-monitor view models). `Environment.Exit` does not run finalizers, so none of that happened by another route. The named-pipe terminate message (`PowerDisplayTerminateAppMessage`) has always gone through `Shutdown()`, so this only makes the tray menu agree with a path that is already shipping. The tray menu command is dispatched from the subclassed main-window procedure, so it already runs on the UI thread that owns these objects, and `Shutdown()` still ends with `Environment.Exit(0)` — the process exits unconditionally either way. ## PR Checklist - [ ] Closes: #xxx — no filed issue. Found while working on microsoft#49410; split out so it can be reviewed on its own. - [ ] **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 — none added. The change is process-exit wiring inside `App.OnLaunched`, which has no test harness; validated manually. - [x] **Localization:** All end-user-facing strings can be localized — no new or changed strings. - [ ] **Dev docs:** Added/updated — no doc change warranted for a one-line teardown fix. - [ ] **New binaries:** Added on the required places — none. - [ ] **Documentation updated:** no user-facing behaviour change. ## Detailed Description of the Pull Request / Additional comments ### Deliberately not in scope Two other paths still call `Environment.Exit(0)` directly, and both are pre-existing and unchanged here: - The runner **Terminate** event (`Constants.TerminatePowerDisplayEvent()`) — the module-disable and PowerToys-exit path. Its callback is already marshalled to the UI thread by `NativeEventWaiter`, so it *could* be routed the same way, but adding teardown work to the runner's shutdown path should be validated against the runner's shutdown timeout on its own rather than riding along with a tray-menu fix. - The `RunnerHelper.WaitForPowerToysRunner` watchdog, whose callback runs on a background thread and would need marshalling to the UI thread first. Happy to follow up on either if reviewers would rather see them fixed together. ## Validation Steps Performed - Tray icon → right-click → **Exit**: PowerDisplay exits, the notification icon disappears immediately rather than lingering until hover. - Re-launch from PowerToys Settings after a tray Exit: the tray icon comes back once, not twice. - `powerdisplay` CLI still works after a launch/tray-Exit/launch cycle, confirming the named pipe was released rather than left to process teardown. - Existing terminate paths unchanged: disabling PowerDisplay in Settings and quitting PowerToys both still exit the process. Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
This has been my personal enemy for a year now. VS will skip doing work for your build if it thinks everything is up-to- date. But this version project has been treated as dirty for a long time now. What that means is that incremental builds (READ: dev inner loop builds) end up building the world CONSTANTLY. Because VS thinks FOR SOME REASON that this project needs to rebuild. By setting the `Inputs`/`Outputs` for this `Target`, VS is smart enough to only re-run the task if the inputs actually changed since the last build. Tested by building the code, then building again, and observing that all the projects were successfully noted as up-to-date drive-by: fix some of the other `csproj` files for cmdpal. Closes microsoft#45296
…, snip-to-clipboard, recording border) and fix video trim reliability (microsoft#49553) ## Summary of the Pull Request Ports several recording and editing features from the Sysinternals **Mac ZoomIt** into the Windows PowerToys ZoomIt module, and hardens the video **trim/save** pipeline against a sporadic "Failed to trim the video" failure. Highlights: - **Video trim editor — interior "Delete Region" editing.** In the post-recording trim dialog you can now select and delete interior segments (not just trim the head/tail). Includes red timeline overlays with drag grips, right-drag to select, `Delete` to remove, `Ctrl+Z` to undo, and `Esc` to cancel a pending selection. - **Reliable trim/render.** Fixed a sporadic *"Failed to trim the video"* error. The live capture pipeline produces **fragmented** MP4s (moof/mdat) that play in preview but fail `MediaComposition` render/seek with `0xC00DA7FC`. The render path now (a) sources resolution from the clip's encoding properties first, (b) retries transient failures (0×0 dimensions from a fragmented-MP4 metadata race, `!CanTranscode()`, post-remux render failure), and (c) remuxes fragmented MP4s to a standard seekable MP4 via `MediaTranscoder` before rendering. - **Snip → Copy to clipboard.** New ZoomIt setting to copy a snip directly to the clipboard. - **Recording border color.** The screen-recording selection border now uses a distinct color, and turns orange while recording is active. - **GIF recording robustness.** First-frame timeout so GIF capture doesn't hang when no frames arrive. - **Audio hardening.** Stereo downmix handling and defensive guards in the audio sample generator. - **Opt-in diagnostics.** Recording diagnostics (`[RecDiag]`) are gated behind a registry DWORD `HKCU\Software\Sysinternals\ZoomIt\EnableDebugTrace` (off by default), and all module debug output is prefixed with `[ZoomIt]` for easy filtering in DebugView. - **Fix:** GDI bitmap leak in the snip-to-clipboard path when `SetClipboardData` fails. ## PR Checklist - [ ] **Tests:** ZoomIt is native Win32/WinRT with no unit-test harness; validated manually (see Validation Steps) - [ ] - [x] **Localization:** All end-user-facing strings can be localized <!-- new strings added to Settings.UI en-us Resources.resw --> - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** N/A: no new binaries/projects - [ ] JSON for signing — N/A - [ ] WXS for installer — N/A - [ ] YML for CI pipeline — N/A - [ ] YML for signed pipeline — N/A - [ ] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments Files changed (17): **ZoomIt module (native)** - `VideoRecordingSession.cpp/.h` — interior delete-region trim editor; render/trim reliability (resolution from clip encoding properties, retry loop, fragmented-MP4 → seekable remux); registry-gated `[RecDiag]` diagnostics. - `GifRecordingSession.cpp` — first-frame timeout / no-frames handling. - `AudioSampleGenerator.cpp` — stereo downmix + defensive guards. - `SelectRectangle.cpp/.h`, `PanoramaCapture.cpp` — recording border color parameter. - `Zoomit.cpp` — snip → clipboard workflow; GDI bitmap leak fix on `SetClipboardData` failure. - `ZoomItSettings.h`, `ZoomIt.h`, `ZoomIt.rc`, `resource.h` — new setting + "Delete Region" button + message id. - `pch.h` — `[ZoomIt]` debug-output prefix wrapper. **Settings UI** - `ZoomItProperties.cs`, `ZoomItViewModel.cs`, `ZoomItPage.xaml`, `Resources.resw` — "Copy snip to clipboard" setting and localized strings. Note: ZoomIt is a Sysinternals port kept in its upstream code style, so it is intentionally exempt from the repo `.clang-format` (changed lines follow the surrounding Sysinternals convention). ## Validation Steps Performed Manual validation (no automated ZoomIt harness): - **Trim reliability:** Recorded multiple clips and used Trim → Save repeatedly (including 3-clip compositions produced by Delete Region); render now succeeds consistently (previously failed sporadically with "Failed to trim the video"). - **Delete Region editor:** Right-drag to select an interior segment, `Delete` to remove, `Ctrl+Z` to undo, `Esc` to cancel; saved output reflects the removed segments. - **Snip → clipboard:** Enabled the new setting; snip is placed on the clipboard and pastes correctly. Verified no GDI handle leak when clipboard set fails. - **Recording border:** Verified border color and the orange active-recording state (full-monitor and region). - **GIF:** Confirmed capture no longer hangs when no frames arrive. - **Diagnostics:** With `EnableDebugTrace` unset, no `%TEMP%\ZoomIt_RecDiag.log` and no `[RecDiag]` output; with it set to `1`, `[ZoomIt] [RecDiag ...]` traces appear. - **Style checks:** XamlStyler (clean), StyleCop via building `Settings.UI.Library` and `PowerToys.Settings` (no `SA####` warnings), ZoomIt x64 Release builds with exit code 0.
If you open command palette on one display and resize its expanded size to be very tall, then you move command palette to a monitor that is not that tall and expand it, we will still expand our control to fit the full size of our HWND, which is taller than this new monitor. This PR fixes that by making sure to measure the size that's available on the current monitor and limit the max height of our control when we're expanding it, so that the bottom of the control always fits on the current monitor. Closes: not filed I don't think
…t#48572) ## Summary Keeps Quick Accent-injected keys from retriggering centralized shortcuts and clears native keyboard-listener state whenever the toolbar closes. ## What this changes - Tags backspace, Unicode, and arrow `SendInput` events with `dwExtraInfo = 0x110`, mirroring `CENTRALIZED_KEYBOARD_HOOK_DONT_TRIGGER_FLAG`. - Uses the existing `SendArrowKey(bool)` implementation as the single arrow-injection path, preserving `KEYEVENTF_EXTENDEDKEY` on key-down and key-up. - Checks the number of events sent by every `SendInput` call and logs incomplete sends. - Adds `ForceReset()` to the keyboard service WinRT API and invokes it from the core hide path immediately before `OnChangeDisplay(false)`. - Keeps listener state non-atomic because the low-level hook is installed on the WinUI thread and its callbacks execute on that same thread, as documented by `MainWindow.RunOnUiThread`. ## Testing - Built `PowerAccent.Core.csproj` in Release x64, including `PowerAccentKeyboardService`. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 122a9176-ce18-437c-8af4-c39f83fb2fa6
Update the central Windows App SDK dependency set and the Command Palette extension template to the latest stable release. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a4a1e3da-76e4-4858-bd65-6519dd7d5900
Owner
Author
|
Superseded by microsoft#49597, targeting microsoft/PowerToys. |
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, 👼 SARIF report, or 📝 job summary for details.Unrecognized words (137)These words are not needed and should be removedATRIOX Autorun caseinsensitive Dedup dpm fileexplorerpreview Gotchas hdmi HELPTEXTA HELPTEXTW HMON intput MTND NONELEVATED NOTXORPEN nullability pfo renumbers resx ssf TILLSON unescaped Unsubscribes upserts Uptool VERBA VISEGRADRELAY WKSGTo accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands... in a clone of the git@github.com:crutkas/autoUpgradeAttempt.git repository curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/cfb6f7e75bbfc89c71eaa30366d0c166f1bd9c8c/apply.pl' |
perl - 'https://github.com/crutkas/autoUpgradeAttempt/actions/runs/30605150682/attempts/1' &&
git commit -m 'Update check-spelling metadata'OR To have the bot accept them for you, comment in the PR quoting the following line: Forbidden patterns 🙅 (8)In order to address this, you could change the content to not match the forbidden patterns (comments before forbidden patterns may help explain why they're forbidden), add patterns for acceptable instances, or adjust the forbidden patterns themselves. These forbidden patterns matched content: Should be
|
| ❌ Errors and Notices | Count |
|---|---|
| ℹ️ candidate-pattern | 3 |
| ❌ check-file-path | 4 |
| ❌ forbidden-pattern | 30 |
See ❌ Event descriptions for more information.
If the flagged items are 🤯 false positives
If items relate to a ...
-
binary file (or some other file you wouldn't want to check at all).
Please add a file path to the
excludes.txtfile matching the containing file.File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.
^refers to the file's path from the root of the repository, so^README\.md$would exclude README.md (on whichever branch you're using). -
well-formed pattern.
If you can write a pattern that would match it,
try adding it to thepatterns.txtfile.Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.
Note that patterns can't match multiline strings.
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
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.
Summary of the Pull Request
The fork was behind the latest PowerToys
main, and the Windows App SDK dependency set needed to move from 2.2 to the latest stable 2.3 release. This PR syncs 408 upstream commits, then upgrades the centrally managed Windows App SDK packages and the standalone Command Palette extension template.The package bump alone did not produce a statistically measurable visible-startup improvement in A/B testing. Windows App SDK 2.3's optional XAML optimizations did produce a repeatable improvement, but those behavior changes are intentionally not enabled in this PR.
PR Checklist
Detailed Description of the Pull Request / Additional comments
Updates the dependency set to the versions required by Windows App SDK 2.3.1:
Microsoft.WindowsAppSDK: 2.2.0 -> 2.3.1Microsoft.WindowsAppSDK.Foundation: 2.1.0 -> 2.3.5Microsoft.WindowsAppSDK.AI: 2.2.3 -> 2.3.4Microsoft.WindowsAppSDK.Runtime: 2.2.0 -> 2.3.1Microsoft.WindowsAppSDK: 2.2.0 -> 2.3.1The resolved graph uses WinUI 2.3.0. The four separately tested XAML opt-ins (
DefaultStyleOptimizations,DeferContextFlyoutInit,IconNoGridOptimization, andOptimizeApplyStyles) are not enabled here, keeping this PR scoped to the dependency upgrade.Validation Steps Performed