mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-10-28 08:36:04 +08:00
a5e83e5e24
<!-- 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 Add a maintained twelve-case Mouse Without Borders UI-test suite using `Microsoft.PowerToys.UITest.Next` and official **winappcli v0.7.1**. It runs two real MWB endpoints in a dedicated Windows test VM and its run-owned Windows Sandbox, without using the development machine as a peer. Closes #40678 Address the [review findings](https://github.com/microsoft/PowerToys/pull/51041#issuecomment-6228571883), remove the temporary MWB diagnostics after verified green owner reruns, and resolve the merge with `main`. Follow-up validation replaces the unstable average-hash visual metric with full-image structural comparison at the normal 95% threshold, and fixes Screen Ruler's ambiguous app-name targeting with an exact toolbar HWND. **Validation: current-source public CI succeeded.** The latest executed platform jobs passed **279/279 active UI cases**, including **24/24 MWB**, plus exactly 15 approved quarantines. Both architecture infrastructure gates passed **628/628** (1,256 executions). The shared execution/cleanup flow, child-console output and failure-only diagnostic publication are verified. The Windows 11 foreground failures were reproduced and fixed by recognizing shell-cloaked windows without extending the timeout. One unrelated native Windows 10 Sandbox startup failure passed on an unchanged retry of only that job; its original evidence is retained. Local outcomes and approved environment limitations are recorded below. Full physical-device/module sign-off is not claimed. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: none; partial automation toward #40678, not completion of the module checklist <!-- - [ ] 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 - [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; the new executable and isolated MWB variant are test-only - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - N/A: no new shipped binary - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - N/A: no new installer payload - [x] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - registered in the v2 build/dispatch flow - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - N/A: no new shipped binary - [ ] **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: N/A, developer/test documentation only <!-- 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 ### Review corrections and runtime boundaries - Exercise real Settings New key / Connect, acknowledged persistence, bidirectional TCP transport, physical keyboard/mouse routing, clipboard isolation/transfer, and failure recovery. - Restore settings and clipboard ownership; stop only run-owned processes and remove only owned provisioning resources. - Shipping Release builds **ignore** hidden non-console opt-ins. Sandbox validation uses an isolated `MwbUiTestBuild=true` Release variant with test-only compilation and same-source metadata; shipping output is not overwritten. - Preserve service/System, secure-desktop, authentication, peer verification, and existing policy restrictions. Companion signing applies only to the private test cohort; private keys never enter payloads. - Derive MWB execution from module selection, without an independent enable/disable checkbox. The owner-requested follow-up defaults automation to `buildNow`. Implicit all-module official runs still skip unsupported MWB with a warning; explicit unsupported MWB selection still blocks. - Gate costly MWB packaging on resolved affected modules, preserving ordinary non-PR builds. - Sequence immutable settings snapshots and reject stale writes after a newer successful write, including retry/reordering tests. Reuse one settings serializer. - Bound Settings RPC responses to 15 seconds, release owned channels, retain user input, and do not replay ambiguous commands. Use the shared process-lifetime semaphore, localized assertive error announcements, and two-second socket polling. - Reuse Windows argument escaping for PS5.1 recovery children; expose recording failures and document final-status timing. - Replace reflection-based persistence fixtures with a deterministic scheduler and update related documentation. - Advanced Paste OCR acceptance activates the actual WinUI owner and sends real Enter. Peek single-file visuals use isolated folders without changing multi-file/pinning coverage. ### Shared UI execution and failure-only diagnostics At the owner's request, `81433384f275d6211233a22a0ade171bbff1b4c8` folds MWB into the existing **Run UI Tests** step, after the other selected suites and inside its normal per-suite log group. Its specialized executor retains isolated child processes, the original 12/15/103-minute setup/prepare/run deadlines, standard-user MTP dispatch and strict complete-suite TRX validation. Ordinary suite failures are aggregated without suppressing MWB. The always-running **Restore UI-test prerequisites** step independently attempts MWB recovery, privileged cleanup, allowlisted diagnostic collection and Light Switch restoration. The existing 6/5/2-minute MWB cleanup/export bounds and 15-minute cancellation budget remain. Cleanup failures cannot become successful runs. The separate MWB step template and per-job selection artifacts are removed. Selection, unsupported-source and ARM64 reasons remain explicit in logs. Prerequisite diagnostics upload only for selected MWB execution that is failed, canceled or incomplete, including failures before TRX exists. This small sanitized artifact is published before potentially lengthy test attachment uploads; raw protected logs and authentication state remain excluded. Successful jobs retain the normal build artifacts and test-result attachments, without additional selection/prerequisite artifacts. No product code, UI-test assertions, source-provenance checks, signing, ownership or privilege boundaries changed. The new 31-case fixture suite executes the real YAML scripts and isolated child-process dispatch against inert phase fixtures, exercises mixed/MWB-only/unsupported/ARM64 paths, verifies environment isolation and owned timeout termination, and proves cleanup continuation and failure-only publication. One obsolete wiring-only contract was replaced by this behavioral coverage. CI16 passed all tests and produced only the two normal build artifacts, but inspection of the actual common execution log caught a remaining regression: inherited child console handles did not forward MWB output into Azure's PowerShell log. `82b322fa364b8907f36c55f70ac1ecb74d474c9b` explicitly drains both redirected streams concurrently on the parent runspace, retaining the phase deadline, owned process termination and bounded output completion. Seven stdout/stderr assertions fail against the CI16 helper and pass after the fix. An additional real-process test writes a one-MiB unterminated prefix to each pipe before either newline, proving both streams drain without deadlock. Final acceptance requires the actual MWB full-suite sign-off to appear inside the common **Run UI Tests** log, not merely a green pipeline status. ### Automatic MWB wiring follow-up At the owner's request, `d15fe299ff` removes the separate `mwbSandboxExperiment` parameter and its `ExplicitlyDisabled` selection path. Manual x64 runtime preparation derives from the selected modules; affected-PR preparation retains its exact resolved `hasMwbUiTests` guard. MWB test steps remain runtime-gated by selection and platform, with the same strict results, provenance, signing, recovery and cleanup requirements. The default is now **`buildNow`**. The build-source UI label states that **`latestMainOfficialBuild` and `specificBuildId` do not support MWB**. ARM64 skipping and implicit-versus-explicit official-source handling are unchanged. Saved REST/queue requests must omit the removed parameter. No product or UI-test code changed in this follow-up. Existing local UI-suite evidence remains applicable; pipeline behavior was checked with: - **295/295 focused Pester contracts passed**, zero skipped. - **Nine exact-source Azure YAML previews passed**: omitted-source defaults with mixed modules, MWB only, unrelated modules and all modules; slim; explicit/implicit official; explicit specific-build; ARM64 only. The default resolves to `buildNow` without supplying an override, and MWB preparation appears only for selected x64 current-source builds. - The optional affected-PR inline-YAML override preview was denied because it requires `EditBuild`. No permissions were bypassed. A normal access preflight recheck passed; affected-PR wiring is covered by the local contracts, not a live PR-triggered run. Exact contract command, **PASS: 295 passed, 0 failed, 0 skipped**: ```powershell Invoke-Pester -Script @( '.pipelines\tests\mwbUiTestSelection.Tests.ps1', '.pipelines\tests\mwbPilotResults.Tests.ps1', '.pipelines\tests\mwbSandboxCiPreparation.Tests.ps1', '.pipelines\tests\mwbSandboxClientSetup.Tests.ps1' ) -PassThru -Quiet ``` ### Grouped scripts and enforced infrastructure tests `c2eac99159` groups the seven remaining MWB pipeline scripts under `.pipelines/mwb`, leaving the shared CLI helper at the pipeline root. The separate 64-line TRX helper is consolidated into the MWB common library; its token/literal stream and all result checks are unchanged. YAML, local-controller, test and current documentation callers are updated. Historical links pinned to old commits are preserved. The protected client setup still uses its original flat directory, identity and ACL model. It now stages only its three required scripts, without the unused portable-CLI helper dependency. A real isolated-staging subprocess test covers this layout. Seven duplicate, obsolete or directory-layout-only tests were removed, along with a comment-text assertion. Real UI binding/staging, signing, ownership, recovery, failure-handling and redaction coverage remains. Five tests exercise the actual new CI result guard, and an additional case covers the isolated client payload. Full builds with `buildTests=true` and UI-tests-only builds now execute the fast MWB/shared CLI Pester suites before compilation and always publish NUnit results. Empty, failed or skipped selected tests fail the build. Pester 3.4.0 was already present on the CI agents; no framework installation was needed. - **596/596 fast tests passed locally**, zero skipped; the edited shared-signing consumer separately passed **48/48**. - Five normal Azure previews passed, checking the gate and publishers on full, tests-only, unrelated-module, specific-build and ARM64 paths. - Six native compiler integration cases remain available under the explicit `NativeCompiler` tag and are excluded from the fast gate. They are not deleted or counted as passing. - CI12 correctly stopped both builds at **595/596** when the large-output fixture exceeded its 30-second deadline. `15761bcc7b` changes only the test producer to write directly to the redirected OS streams, avoiding console-host text rendering. It retains the one-MiB unterminated prefixes, over-five-MiB output per stream, completion markers, exit code and the same 30-second limit. The production provisioning wrapper is unchanged. - CI13 passed both 596-case gates and all generic UI tests, but exposed a missed shared-dispatcher path introduced by the grouping. `feb526baf0` resolves one canonical parent-directory launcher for both Run and Recover, preserving exact scheduled-task identity checks. Two dispatch regressions failed before the fix and pass afterward; the final local fast gate is **598/598**. - CI14's x64 build exposed an existing lease-publisher unit race: readers could observe a truncated, in-place status JSON update. `edec893923` atomically replaces only the controller-local publisher status, leaving mapped immutable lease generations, schemas, identities and deadlines unchanged. A deterministic open-reader snapshot test fails before the fix and passes afterward; all **6 publisher lifecycle cases**, both architecture builds and the **598-case fast gate** pass locally. ### Diagnostic rollback and merge - `7d22de9d70` reverts only `d93fe7086f` and `51e82fb54f`; there is no history rewrite. Its complete repository tree matched the verified green `78ceb8c880` tree. - The owner reruns of builds [160920795](https://dev.azure.com/microsoft/Dart/_build/results?buildId=160920795) and [161000191](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161000191) were independently verified **Succeeded, 339/339 active passed each**. - Merge `bed0eed863` incorporates `main` at `3d6827a53a`. Conflict resolution preserves #51305 service-mode key protection and typed RPC behavior alongside ordered persistence, timeouts, and accessible errors. - Temporary Defender/runtime diagnostic collection is no longer in the branch. No Defender settings, signature checks, ownership rules, or recovery assertions were weakened. ### Visual comparison root fix `aa19b7da58` replaces the `.Next` harness's coarse 64-bit average hash with pixel-weighted local structural similarity (8x8 blocks, including partial edge blocks and every pixel). RGB and alpha are checked independently; image dimensions must match. - Restore **95% for every Peek case**, including ARM64 PNG; remove the former 93% exception. - Keep all baseline images, capture geometry, and captured pixels unchanged: no crop, border mask, resize, or baseline refresh. - Exact production-method checks: actual CI7 image **98.898443%**; removed PNG preview **91.561796%**; blank image **85.289191%**. The real capture passes, both negative controls fail at 95%. - **35 visual/capture-bound unit cases passed**; the legacy harness remains unchanged. Remove the unused CoenM dependency without adding a dependency. - All **45 Peek cases passed in CI8**, across Windows 10, Windows 11 and ARM64. ### Screen Ruler targeting root fix CI8's Windows 10 failure had a visible toolbar but four `PowerToys.MeasureToolUI` processes. A deterministic two-process local reproduction proved that `winapp ui search ... -a PowerToys.MeasureToolUI` fails with an ambiguous-process error; it was not a missing toolbar or stale cached PID. `bd8babb5d4` changes the test helper to discover the toolbar through Win32 and pin its exact HWND. A new regression opens an additional real ruler, invokes Close through the original session, and requires the original process to exit while the additional toolbar remains visible. UIA Invoke deliberately isolates target ownership from foreground-dependent clicks on overlapping windows. The normal Bounds case still performs a real 100x100 drag and verifies its clipboard measurement. Lookup failures retain the actual error message. ### Deliberate exclusions - The owner requested delivery in this existing PR. Optional PR splitting and extracting linked pure test helpers into a core library remain follow-ups. A direct test-project reference was not retained because it produced `NETSDK1150`. - No live ARM64 MWB/Sandbox sign-off; ARM64 builds and generic UI suites are separate coverage. - Five pre-existing Advanced Paste clipboard-history cases remain quarantined with explicit owner approval. No clipboard-history sign-off is claimed. - Physical two-PC behavior, installed per-user/per-machine flows, service/System, secure/locked desktops, and the remaining manual checklist are not signed off. - Human review and sanitized Settings evidence remain readiness work. Recordings containing generated pairing keys stay private. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ### Current-head cloaked-window correction and validation Source: `bd3c8d38b5c8e6ca11fcb46f150923b1b2e2e9d0`. The prior public failure was reproduced with the same hidden-launcher behavior in a local Windows 11 VM: after twelve successful Start-menu cycles, closing a receiver restored foreground to a `Windows.UI.Core.CoreWindow` with **Win32 visibility still true but `DWMWA_CLOAKED = 2` (shell-cloaked)**. That explains the absence of a visible menu in the failure screenshots. A normal visible console masked the problem by providing another foreground window. The C# 5-compatible payload now queries DWM cloaking before classifying the verified shell window as actionable. Cloaked windows receive no Escape; DWM query failures are explicit errors. Exact OS image/class/session/identity checks, modifier checks, the single-Escape rule and the three-second dismissal deadline remain. The existing focus test now also requires the dismissed menu to stop being classified as actionable. No mouse/Alt shortcut, privilege bypass, foreground-activation hack or weaker assertion was added. The normal, automatically triggered [PowerToys CI_2610.23002 / build 391666](https://dev.azure.com/shine-oss/PowerToys/_build/results?buildId=391666) tests PR merge `9d987064ecc45390d531e697e7398d71cd844d80`, with source commit `bd3c8d38b5c8e6ca11fcb46f150923b1b2e2e9d0`: **Succeeded**, finishing 2026-10-23 at 05:44:15 UTC. No additional internal UI Test Automation run was manually queued. | Current executed job | Attempt | Passed | Approved quarantines | Published test run | |---|---|---|---|---| | Infrastructure, ARM64 | 1 | 628/628 | 0 | 936468 | | Infrastructure, x64 | 1 | 628/628 | 0 | 936470 | | UI, ARM64 | 1 | 85/85 | 5 | 936686 | | UI, Windows 11 x64 | 1 | 97/97 | 5 | 936860 | | UI, Windows 10 x64 | 2 | 97/97 | 5 | 936876 | The Windows 11 job passed every MWB test on its first attempt, including all five formerly failing foreground cases. Windows 10's first attempt failed only `AbortedSandboxStartupRefusesUnownedInstance`: the inspected recording shows the native Sandbox splash for the entire unchanged three-minute deadline, with no viewer HWND or guest acknowledgement. Only that failed Windows 10 job was retried, unchanged, through `Build_x64` with `forceRetryAllJobs=false`; successful builds, ARM64 and Windows 11 jobs were not rerun. The retry passed all 97 active cases. The original failed test run 936862 remains historical evidence, not a passing run. All current jobs have one common **Run UI Tests**, one successful **Restore UI-test prerequisites** and one shared result publisher. Both x64 common execution logs contain the **12/12 MWB** sign-off. Diagnostic publication is skipped by every successful current job. The build retains the two normal build artifacts plus the **original** Windows 10 failure's diagnostic report; its unchanged artifact identity/size was verified, and the successful retry did not upload another report. Retaining that historical failure artifact is intentional. No selection artifacts or separate MWB execution flow remain. No prior antivirus/PUA error pattern appeared in the successful logs. Local evidence uses the rebuilt test payload with the unchanged prepared Release test runtime: | Local validation | Result | |---|---| | UI-test project, Release x64 and ARM64 | Both builds passed | | Complete fast infrastructure gate | 628/628 passed | | Actual seven-case infrastructure suite, Windows 10 and Windows 11, 4 CPU / 8 GiB | 7/7 passed on each | | Complete MWB suite, Windows 10, 8 CPU / 16 GiB | 12/12 passed | | Complete MWB suite, Windows 10, 2 CPU / 8 GiB | 12/12 passed | | Complete MWB suite, Windows 11, 8 CPU / 16 GiB | 11/12 passed; smoke blocked by guest bootstrap before the changed receiver code executed | | Actual infrastructure suite, Windows 11, 1 CPU / 4 GiB | 7/7 passed | All five formerly failing foreground/recovery cases pass locally. The Windows 11 smoke's first `LoadingReceiverTypes` bootstrap marker arrived after the unchanged 35-minute readiness deadline; this is retained as a startup limitation, not a passing test. No host-suspension overlap occurred. The previously documented full nested-Sandbox constrained-host exception remains; Windows 11 again lost host communication after its successful seven-case constrained run. Exported results were preserved before recovering that exact test VM. Exact validation entry points: ```powershell tools\build\build.cmd -Path src\modules\MouseWithoutBorders\MouseWithoutBorders.UITests -Platform x64 -Configuration Release tools\build\build.cmd -Path src\modules\MouseWithoutBorders\MouseWithoutBorders.UITests -Platform arm64 -Configuration Release $tests = @(Get-ChildItem .pipelines\tests\mwb*.Tests.ps1) + (Get-Item .pipelines\tests\winappCliRelease.Tests.ps1) Invoke-Pester -Script $tests.FullName -ExcludeTag NativeCompiler -PassThru -Quiet ``` **Results:** both builds passed; 628/628 selected Pester cases passed. The six opt-in compiler cases remain outside the fast gate. Real VM runs used `Invoke-LocalVmUiTest.ps1` with `-Filter 'TestCategory=MwbInfrastructure'`, and `Invoke-AutonomousLocalVm.ps1` without a filter for full suites, with the OS-specific configuration and Default/Constrained profiles above. Every provisioning cleanup receipt reports `Removed`. Both original non-elevated PTUser startup task definitions/enabled states were restored from their preserved, validated XML; both VMs are stopped at 4 CPU / 8 GiB. ### Previous shared-flow validation Source: `82b322fa364b8907f36c55f70ac1ecb74d474c9b`. - Internal [UI Test Automation 20261022.3 / build 161358211](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161358211): **Succeeded** at 2026-10-22 23:27:50 UTC. Both infrastructure gates passed **628/628** (1,256 executions). Windows 10 passed **118/118**, Windows 11 **118/118**, and ARM64 **106/106** active UI cases: **342/342**, plus exactly 15 approved quarantines. This includes **24/24 MWB, 18/18 Ruler and 45/45 Peek** cases. - Automatically triggered public [PowerToys CI_2610.22026 / build 391652](https://dev.azure.com/shine-oss/PowerToys/_build/results?buildId=391652): **Failed**. Its PR merge revision is `fd1ed3599f7a02e1216748fec0750cdc25d1295c`, with source commit `82b322fa364b8907f36c55f70ac1ecb74d474c9b`. Both 628-case infrastructure gates and both product builds passed. Its affected-project UI matrix passed **97/97 Windows 10**, **85/85 ARM64**, and **92/97 Windows 11** active cases: **274/279**, plus the same 15 approved quarantine records. This is a different selected-module matrix from the internal run; its totals are not combined with the internal 342. - **Flow and artifact shape verified:** each platform has one common execution step, one always-running prerequisite cleanup and one shared result publisher. MWB console output and full-suite sign-off now appear inside the common execution logs. The successful internal run publishes only the two normal build artifacts. The public run likewise publishes no selection artifacts; only its failed Windows 11 job adds the **14,219-byte allowlisted UI-test diagnostic artifact**. Both successful public jobs skip that publication. Cleanup succeeded on all three public platforms; the failed Windows 11 recovery reported settings and clipboard restored with an empty errors array. The public Windows 11 failures all report **"The identified Start menu did not release foreground after dismissal"**, in: - `StartMenuDismissalDoesNotActOnAnOrdinaryForegroundWindow` - `ReceiverInfrastructureRemainsResponsiveToUiAutomation` - `DesktopAndWindowVideosSurviveAnEarlyFailure` - `ControllerExitBeforePairingRestoresOriginalSettings` - `KilledClipboardOwnerRequiresBaselineReset` The ordered two-endpoint smoke and the other seven MWB cases passed on that public worker. The foreground-recovery code had not been changed by the wiring cleanup. Both available recovery screenshots were inspected: they show the receiver without a visible Start menu. The failures happen during input focus/bootstrap, before recording starts; the attached recording manifests are empty. Agent logs also warn of 95.48% memory usage, but this did not establish the cause. **No prior antivirus/PUA error pattern was found.** Subsequent local reproduction identified the shell-cloaking issue described above; the timeout was not extended. All three additional authorized internal runs (15-17) were used. The owner then requested autonomous continuation; the cloaking correction uses normal PR-triggered CI rather than another manually queued internal run. Local validation: - Complete enforced fast Pester gate: **628/628 passed**, zero failed/skipped selected cases; the six opt-in `NativeCompiler` cases remain outside this gate. - `Invoke-Pester -Script .pipelines\tests\uiTestSigningSelection.Tests.ps1,.pipelines\tests\configureLightSwitchLocation.Tests.ps1 -PassThru -Quiet`: **73/73 passed**, covering shared signing and Light Switch behavior. - The new pipeline fixture suite below passed **31/31 on each of four guest runs**: Windows 10 and Windows 11, each at 4 CPU / 8 GiB and 1 CPU / 4 GiB. Both guests used PowerShell 7.6.4. These are pipeline orchestration fixtures, not new full local product UI-suite runs. Both VMs were stopped and their original 4 CPU / 8 GiB settings restored. ```powershell $result = Invoke-Pester -Script "$env:FLOW_ROOT\.pipelines\tests\mwbUiTestFlow.Tests.ps1" ` -PassThru -Quiet -OutputFormat NUnitXml -OutputFile "$env:FLOW_ROOT\$env:FLOW_LABEL.xml" ``` `FLOW_ROOT` is the guest-local staging directory and `FLOW_LABEL` identifies its OS/resource profile. **Result: 124/124 fixture executions passed.** Eight normal exact-source Azure YAML previews passed: full mixed, MWB only, unrelated suites, ARM64-only MWB, slim mixed, official unrelated, official all and specific-build MWB. Every generated test job has one common execution step, one always-running prerequisite cleanup, one common result publisher and failure-only diagnostic publication. No inline YAML override or permission workaround was used. This follow-up uses CI16 and CI17, the remaining two of the owner's additional authorized runs 15-17. No further internal queue is authorized. The first public run, 391644, was automatically superseded/canceled after the corrected source was pushed; it is not counted as a passing validation. ### Previous validated consolidation head [UI Test Automation 20261022.1 / build 161319902](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161319902) completed **Succeeded** on 2026-10-22 at 16:19:53 UTC, testing exact source `edec8939230879c6cc6dabcbe9636423e7a4b3d1`. | Gate / platform | Passed | Approved quarantines | Azure test run | |---|---|---|---| | Infrastructure, x64 build | 598/598 | 0 | 1722115765 | | Infrastructure, ARM64 build | 598/598 | 0 | 1722115721 | | UI, Windows 10 x64 | 118/118 | 5 | 1722208994 | | UI, Windows 11 x64 | 118/118 | 5 | 1722213084 | | UI, ARM64 | 106/106 | 5 | 1722190620 | Infrastructure results are separate from the **342 active UI cases**. Both product builds and both relocated MWB execution/recovery paths passed; the UI totals include **24/24 MWB** cases. All 15 non-executed UI records exactly match the owner-approved Advanced Paste quarantine set. No selected infrastructure test was skipped or failed. Run ownership was verified through the respective infrastructure and UI publication logs. The final MWB logs contain none of the prior virus/PUA, `0x800700E1`, or Bearfoos errors. No signing, identity, lease-freshness, runtime assertion or deadline was weakened. The exact Pester invocation executed by both CI gates was: ```powershell $result = Invoke-Pester -Script $tests.FullName -ExcludeTag NativeCompiler -PassThru -Quiet ` -OutputFile "$(LogOutputDirectory)\pipeline-powershell-tests.xml" -OutputFormat NUnitXml ``` `$tests` contains the MWB test files and the shared CLI release test; the Azure log-directory macro is expanded by the task. **Result: 598 passed, zero failed/skipped, for each build architecture.** The selected matrix is `[MouseWithoutBorders.UITests, ScreenRuler.UITests.Next, AdvancedPaste.UITests.Next, Peek.UITests.Next, FancyZones.UITests.Next]`, x64/ARM64. **Neither `buildSource` nor the removed MWB flag was supplied**: the run validates the real `buildNow` default and automatic MWB selection. Caching, VS Preview and latest-WebView2 overrides are disabled. This was attempt 15 overall, the first of the three further owner-authorized runs (15-17). No further run was needed for that consolidation; the later owner-requested shared-flow follow-up uses CI16 above. With the new Ruler regression, the expected active count is **342**: Windows 10 **118**, Windows 11 **118**, ARM64 **106**, plus **15 exact approved quarantine records** (five Advanced Paste cases per platform). ### Historical CI evidence retained | Attempt | Build | Outcome | |---|---|---| | 1 | [160877925](https://dev.azure.com/microsoft/Dart/_build/results?buildId=160877925) | Peek PNG failures led to single-file fixture isolation. | | 2 | [160887683](https://dev.azure.com/microsoft/Dart/_build/results?buildId=160887683) | 338/339 active passed; ARM64 PNG average hash 93.75%. | | 3 | [160916177](https://dev.azure.com/microsoft/Dart/_build/results?buildId=160916177) | 338/339 active passed; Win10 native Sandbox startup failure. | | 4 | [160920795](https://dev.azure.com/microsoft/Dart/_build/results?buildId=160920795) | Initial antivirus/native-startup failures retained; latest owner rerun succeeded, 339/339. | | 5 | [160983500](https://dev.azure.com/microsoft/Dart/_build/results?buildId=160983500) | 333/339 active passed; Defender access denial and Sandbox/recovery failures. | | 6 | [161000191](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161000191) | Initial 337/339 antivirus-blocked result retained; latest owner rerun succeeded, 339/339. | | 7 | [161106387](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161106387) | Merged source: 336/339; Win10 MWB antivirus failures and ARM64 PNG hash 92.1875%. | | 8 | [161133682](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161133682) | Structural fix: all 45 Peek passed. 326/327 executed active passed; Win10 Ruler Bounds failed and its subsequent 12 MWB cases did not run. | | 9 | [161155440](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161155440) | All 18 Ruler and 45 Peek passed. 340/342 active passed; Win10 MWB cursor settling and Start-menu dismissal failed. All active cases executed; no antivirus errors. | | 10 | [161197747](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161197747) | **Succeeded, 342/342 active passed** on unchanged source. All 15 non-executed records exactly match the approved quarantine set. | | 11 | [161232122](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161232122) | **Succeeded, 342/342 active passed** with default `buildNow` and automatic MWB selection; neither control was supplied in the request. | | 12 | [161265853](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161265853) | New infrastructure gates blocked both builds at 595/596: the large-output fixture exceeded 30 seconds. NUnit failures published; no product compilation or UI tests ran. | | 13 | [161266859](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161266859) | Both 596-case gates and product builds passed. All 318 executed generic UI cases passed, plus 15 quarantines; 24 MWB cases did not run because of the missed dispatcher path. | | 14 | [161275806](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161275806) | Both 598-case gates passed. ARM64 product and 106 active UI cases passed, plus 5 quarantines. The x64 build failed the lease-status unit race; 236 x64 UI cases did not run. | | 15 | [161319902](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161319902) | **Succeeded:** 598/598 infrastructure cases on each build, both products, and 342/342 active UI cases passed. | | 16 | [161344209](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161344209) | **Succeeded:** 627/627 infrastructure cases on each build and 342/342 active UI cases passed; only the two normal build artifacts were published. Post-run log inspection nevertheless found missing MWB child stdout/stderr, corrected before CI17. | | 17 | [161358211](https://dev.azure.com/microsoft/Dart/_build/results?buildId=161358211) | **Succeeded:** 628/628 infrastructure cases on each build, 342/342 active UI cases and the exact common-step console/artifact checks passed. The separate public PR run's Windows 11 foreground failures are documented above. | CI8's missing Win10 MWB coverage could not establish antivirus resolution. CI9 executed the complete MWB suite on both Windows versions with no antivirus errors; both previously antivirus-blocked recovery cases passed. Its two separate Win10 input/focus failures are retained. ### Local, build and contract evidence - Diagnostic rollback: x64/ARM64 MWB test builds, 83 Pester checks and 15 visual-threshold cases passed. - Merge resolution: 183 MWB unit cases, 120 Settings MWB cases and 125 Pester contracts passed. - Merged default generic suites: **105/105 on each OS**. MWB default **8 CPUs / 16 GiB: 12/12 on each OS**. - Merged Win10 MWB pressure **2 CPUs / 8 GiB: 11/12**; native viewer startup timed out before the injected aborted-startup boundary. This remains the owner's accepted native-startup local exception, not a PASS. - Structural Peek follow-up: **15/15 Win10 default, 15/15 Win11 default, 15/15 final Win10 constrained**. Earlier OneDrive/Explorer activation failures are retained; unchanged repeats passed without changing OS preferences or assertions. - Earlier Win11 constrained guest hangs/lost control remain explicitly accepted local blockers, not successful full generic pressure coverage. - Ruler regression failed before the HWND fix with the exact CLI ambiguity error, then passed. Final x64 and ARM64 test builds passed. - Final Ruler closure: **6/6 on both OSes at default 4 CPUs / 8 GiB and constrained 1 CPU / 4 GiB**, zero skips/errors/export failures. The first final Win11 constrained run was 5/6 (Spacing clipboard empty); its unchanged full repeat passed 6/6. This is preserved as an intermittent pressure failure, not a claimed spacing root fix. - Retain earlier Ruler pressure failures: empty spacing clipboard results after toolbar/overlay readiness, plus the initial regression's foreground-dependent physical Close. These were not relabeled PASS; the final regression uses UIA Invoke. The local product payload is the retained merged private runtime: relevant merged MWB/Runner/Settings components were rebuilt; unchanged generic modules reused repository outputs. This is **not a clean full-product local build**. CI supplies fresh complete selected-platform builds. Exact final Ruler build commands, both **PASS (exit 0)**: ```powershell Set-Location C:\Develop\GitHub\PowerToys\src\modules\MeasureTool\Tests\ScreenRuler.UITests.Next & C:\Develop\GitHub\PowerToys\tools\build\build.cmd -Platform x64 -Configuration Release & C:\Develop\GitHub\PowerToys\tools\build\build.cmd -Platform ARM64 -Configuration Release ``` Final local invocation (repository root; expanded once per OS/profile below): ```powershell $exchange = 'C:\PowerToysUiTestVm\shared\PowerToysUiTests\Merge51041' & .\.github\skills\ui-tests-local-vm\scripts\Invoke-LocalVmUiTest.ps1 ` -VmName $vm -VmRoot C:\PowerToysUiTestVm ` -ConfigurationPath "$exchange\generic-$os.psd1" -ResourceProfile $profile ` -ExchangeRoot $exchange -TestExecutable ScreenRuler.UITests.Next.exe ` -TestsArchive ui-tests-ruler-final.zip -Platform $platform ` -BuildLabel aa19b7da58-ruler-final -SuiteTimeout 25m -TimeoutMinutes 40 ` -ReuseStagedPayload ``` | `$vm` / `$os` / `$platform` | `$profile` | Result | Run | |---|---|---|---| | `PowerToysUiTest-Win10` / `win10` / `x64Win10` | `Default` | PASS 6/6 | `localvm-20261021-025750-2a3848c0` | | `PowerToysUiTest-Win11` / `win11` / `x64Win11` | `Default` | PASS 6/6 | `localvm-20261021-030354-63e48d2b` | | `PowerToysUiTest-Win10` / `win10` / `x64Win10` | `Constrained` | PASS 6/6 | `localvm-20261021-030825-531b4cd9` | | `PowerToysUiTest-Win11` / `win11` / `x64Win11` | `Constrained` | FAIL 5/6, Spacing clipboard empty | `localvm-20261021-031458-9df461e5` | | Same Win11 constrained command, with `-BuildLabel aa19b7da58-ruler-final-unchanged-repeat` only | `Constrained` | PASS 6/6 | `localvm-20261021-032537-7a36fe71` | The labels identify the tested working diff subsequently committed as `bd8babb5d4`; the product archive was unchanged. Final Ruler test archive SHA-256: `F683C57F298CC42CC6D958A9B17EC46C7D5C24B710A70C97DF2FE04FADCDB604`. Both local VMs are stopped, restored to their original startup task state and **4 CPUs / 8 GiB**, and have no task-owned test signing trust. No host signing private keys were created for the Ruler follow-up; the earlier marked keys were removed. Failed-run evidence and reusable private payloads remain outside the repository. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: khmyznikov <6115884+khmyznikov@users.noreply.github.com>
Microsoft PowerToys
Microsoft PowerToys is a collection of utilities that help you customize Windows and streamline everyday tasks.
Installation · Documentation · Blog · Release notes
🔨 Utilities
PowerToys includes over 30 utilities to help you customize and optimize your Windows experience:
Advanced Paste
Always on Top
Awake
Color Picker
Command Not Found
Command Palette
Crop And Lock
Environment Variables
FancyZones
File Explorer Add-ons
File Locksmith
Grab And Move
Hosts File Editor
Image Resizer
Keyboard Manager
Light Switch
Mouse Utilities
Mouse Without Borders
New+
Peek
PowerDisplay
PowerRename
PowerToys Run
Quick Accent
Registry Preview
Screen Ruler
Shortcut Guide
Text Extractor
Window Hopper
Workspaces
ZoomIt📦 Installation
For detailed installation instructions and system requirements, visit the installation docs.
But to get started quickly, choose one of the installation methods below:
Download the .exe file from GitHub
Go to the PowerToys GitHub releases, scroll down and select Assets to reveal the installation files, and choose the one that matches your architecture and install scope. For most devices, that would be x64 per-user.
Microsoft Store
You can easily install PowerToys from the Microsoft Store:
WinGet
Download PowerToys from [WinGet](https://github.com/microsoft/winget-cli#installing-the-client). Updating PowerToys via winget will respect the current PowerToys installation scope. To install PowerToys, run the following command from the command line / PowerShell:
- User scope installer (default)
winget install Microsoft.PowerToys -s winget
- Machine-wide scope installer
winget install --scope machine Microsoft.PowerToys -s winget
Other methods
There are [community driven install methods](https://learn.microsoft.com/windows/powertoys/install#community-driven-install-tools) such as Chocolatey and Scoop. If these are your preferred install solutions, you can find the install instructions there.
✨ What's new?
To see what's new, check out the release notes.
🛣️ Roadmap
For v0.103, we're working on a new Awake flyout, improving Screen Ruler, and continuing to modernize more utilities with WinUI 3.
❤️ PowerToys Community
The PowerToys team is extremely grateful to have the support of an amazing active community. The work you do is incredibly important. PowerToys wouldn't be nearly what it is today without your help filing bugs, updating documentation, guiding the design, or writing features. We want to say thank you and take time to recognize your work. Your contributions and feedback improve PowerToys month after month!
Contributing
This project welcomes contributions of all types. Besides coding features / bug fixes, other ways to assist include spec writing, design, documentation, and finding bugs. We are excited to work with the power user community to build a set of tools for helping you get the most out of Windows. We ask that before you start work on a feature that you would like to contribute, please read our Contributor's Guide. We would be happy to work with you to figure out the best approach, provide guidance and mentorship throughout feature development, and help avoid any wasted or duplicate effort. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you grant us the rights to use your contribution and that you have permission to do so. For guidance on developing for PowerToys, please read the developer docs for a detailed breakdown. This includes how to setup your computer to compile.
Code of conduct
This project has adopted the Microsoft Open Source Code of Conduct.
Privacy statement
The application logs basic diagnostic data (telemetry). For more privacy information and what we collect, see our PowerToys Data and Privacy documentation.