PowerToys Dev Preview 0.103.3151: Awake Lock-Screen Control, CPU Card and Policy Fixes

The most useful change is also the easiest to misunderstand. Awake can now retain its request to keep the display illuminated while Windows is locked—but that is a request, not an unconditional override of Windows power management. Meanwhile, Command Palette’s improvements are about presenting useful information, not making the processor itself faster. Those distinctions matter more than the size of the version number.

Awake gets a separate lock-screen choice​

The new Awake setting is called Allow screen to turn off while locked, and Microsoft has added it to both Settings and the tray menu. Its wording deserves a moment’s attention: to retain the display-on request while Windows is locked, turn this option off. Leave it enabled to preserve the previous behavior, which allows the display to turn off after locking. That previous behavior remains the default.

This separates two choices that users can reasonably want to control independently:

• Whether Awake should request that the display remain on.
• Whether that request should continue after the Windows session is locked.

The implementation pull request, #51880, explains that disabling the new option keeps the Windows execution-state flag ES_DISPLAY_REQUIRED set while locked. The setting does not unlock Windows or make an authenticated desktop visible; it changes whether Awake continues making its display-power request.

Microsoft’s general Awake documentation provides useful background. Awake operates by making power-state requests rather than rewriting the Windows power plan. Keeping the computer awake and keeping its displays illuminated are separate functions: Keep screen on must be selected when the display itself needs to remain active. That option requires Awake to be enabled with a custom keep-awake mode selected.

How to test the new behavior​

For users deliberately evaluating v0.103.3151.0, the relevant sequence is:

1. Open PowerToys Settings and enable Awake.
2. Select an active keep-awake mode, such as Keep awake indefinitely, rather than leaving the computer governed solely by the selected power plan.
3. Enable Keep screen on.
4. Turn Allow screen to turn off while locked off.
5. Lock Windows with Win+L and observe the display behavior on that particular device.

The same new lock-screen preference is available through Awake’s tray menu. To restore the previous behavior, turn Allow screen to turn off while locked back on. This procedure combines Microsoft’s documented Awake prerequisites with the preview’s new setting.

There is a timing caveat worth knowing before experimenting. According to the implementation pull request, changing this setting during a timed or expirable Awake session restarts that session through the settings-processing path, resetting its timer to the configured duration. Indefinite mode has no timer to reset, and passive mode is unaffected. For a clean test, choose the lock-screen preference before starting a time-limited session.

Why the display might still switch off​

Modern Standby remains an explicit limitation. Microsoft’s release notes warn that Windows may still turn off the display on systems using it. A dark screen therefore does not, by itself, establish that the new toggle failed to save or that PowerToys ignored it. The preview does not promise to defeat every platform-level power decision.

There is also a separate Windows distinction that helps explain longstanding confusion. Microsoft’s support article KB 2835052 documents different display timeouts for an unlocked session and a locked console. Changing the ordinary idle-display timeout does not necessarily change what happens after locking. The article identifies VIDEOIDLE as the unlocked timeout and VIDEOCONLOCK as the locked-screen timeout; its PowerCfg procedures also distinguish AC-power settings from battery settings.

That is useful troubleshooting context, not a reason to start changing power settings indiscriminately. First confirm the preview version, Awake mode, Keep screen on state, and new lock-screen preference. If the machine uses Modern Standby, keep the documented limitation in view rather than expecting the toggle to be a universal “never darken” switch.

Command Palette’s CPU card gains useful context​

Command Palette’s Performance Monitor CPU card has been redesigned around four elements:

• A 60-second utilization history.
• Utilization for each logical processor.
• The five busiest processes.
• System details alongside the performance information.

Performance cards also show their first sample immediately, and CPU base-speed reporting has been adjusted to better handle processors with multiple clusters. Microsoft records the CPU-card work in pull request #51211.

The practical value is the combination. As an editorial assessment, a recent history, a processor-by-processor view, and a short list of busy processes provide a better starting point for investigating activity than an isolated utilization number. They let a user ask more useful questions: was that load sustained, was it concentrated, and which processes were prominent?

There are limits to what should be inferred. The release notes do not specify a sampling interval, so 60 seconds of history does not establish a particular refresh rate. Nor does improved base-speed reporting constitute a CPU performance improvement. It concerns how hardware information is reported, not how quickly applications execute. Microsoft supplies no benchmark or affected-processor list for that change.

For preview testers, a sensible assessment is therefore to inspect the first-sample behavior, history, logical-processor display, and process list—not to expect higher benchmark scores.

Native charts expand extension options​

Command Palette extensions supplying Adaptive Cards can now render native vertical bar charts, horizontal bar charts, and stacked horizontal bar charts. Microsoft tracks that work separately in pull request #51210. This is an extension-rendering capability, distinct from the redesigned CPU card.

For extension authors, the meaningful addition is the availability of those chart forms inside Command Palette. As a design consideration, a bar chart may communicate comparisons more clearly than another column of numbers. Whether that helps a particular extension depends on the information it presents.

The release announcement does not establish chart-data limits, a supported Adaptive Cards schema matrix, or automatic conversion of existing extension content. Developers should not interpret “native charts” as a promise that every previously unsupported card will now render correctly. A focused preview test would exercise the relevant chart orientation in the extension itself, rather than treating the feature announcement as a blanket compatibility guarantee.

Two fixes remove misleading behavior​

Win+Shift+C: the warning was wrong​

PowerToys no longer reports a false Windows system-shortcut conflict for Win+Shift+C on Windows 11. Microsoft’s pull request #51236 identifies this as a false-positive correction in the runner.

That scope matters. It is a correction to PowerToys’ conflict reporting, not an announcement that Windows has reassigned the shortcut or that all shortcut combinations are now unrestricted. Users who encountered this particular warning have a precise case to retest; unrelated shortcut problems should not be assumed fixed.

Mouse Without Borders: policy mappings stand alone​

Mouse Without Borders now applies administrator-defined IP mapping rules even when the user has no personal mapping rules. The fix also covers the case where user mappings are disabled by policy. Previously, the administrator’s configuration could be missed in those circumstances.

For administrators, the useful verification is correspondingly narrow: test the existing administrator-defined mapping with an account that has no user-defined mappings, and separately test the policy configuration that disables user mappings if that is how the environment operates.

This is not evidence of a general networking repair. The announcement does not document new policy names, mapping syntax, or precedence when rules conflict. Its value is more specific: administrator-supplied rules should no longer depend on user rules being present or permitted.

Build and test work goes beyond housekeeping​

The preview also contains several changes for PowerToys contributors and extension developers. These are not additional switches for ordinary users, but they address how the project is built, packaged, and tested.

Build consistency and packaging: Single-project builds now resolve the solution directory correctly so intermediate outputs match those produced by solution builds. The stated goal includes preventing those outputs from accidentally entering context-menu packages. The SDK build job also explicitly installs its required.NET SDK and signing runtime.

Dependency maintenance: Windows App SDK packages move to 2.6.5, and an unused dependency is removed from the Command Palette extension template. Separately, twelve shared C++ projects move from packages.config to centrally versioned PackageReference dependencies.

Interop compatibility: CsWinRT advances to 2.3.1, while the Windows SDK.NET reference pack advances to 10.0.26100.87. Microsoft also lists collection-projection compatibility fixes accompanying those updates. These are build dependency versions, not a new Windows operating-system version requirement announced by this release.

Testing and analysis: File Explorer thumbnail UI tests have been updated to recognize current initialization logs and check generation failures after visual captures. MSVC C++ code analysis moves into a parallel continuous-integration job to shorten the main build path. No measured build-time saving is supplied.

Taken together, these changes deserve attention from anyone building PowerToys or maintaining an extension against its tooling. They should not, however, be repackaged as promises of faster Windows performance or a broad File Explorer thumbnail fix. The thumbnail item specifically concerns tests.

Installer selection and an integrity check​

Microsoft lists four installer variants for this development preview, separating processor architecture from installation scope:

Before testing, choose the intended architecture and deployment scope rather than treating these filenames as interchangeable. For managed machines, my recommendation is to evaluate the preview within an approved test deployment, especially when validating the Mouse Without Borders policy correction.

A useful additional check is to calculate the downloaded installer’s SHA-256 value. Microsoft documents Get-FileHash in Windows PowerShell 5.1; SHA-256 is its default algorithm, although specifying it explicitly makes the check easier to audit.

For the per-user x64 installer, open PowerShell in the folder containing the download and run:

Get-FileHash `
  -LiteralPath ".\PowerToysUserSetup-0.103.3151.0-x64.exe" `
  -Algorithm SHA256

Compare the returned Hash value with Microsoft’s published value for that exact asset:

CB663FA04B2AAACEDE19CB35013545417A372A16D96A720C8352B411358692AB

That value applies only to the per-user x64 installer, not the other three packages. The command syntax follows Microsoft’s PowerShell documentation, and the expected value comes from the PowerToys release record.

If PowerShell cannot find the file, correct the path to its actual location. If the calculated value differs, do not proceed on the assumption that a matching filename is sufficient. Hash checking validates content against the expected value; it is not a substitute for obtaining the file and expected hash from a trusted publisher.

Who should evaluate this preview?​

My recommendation is to make the testing decision around a specific need. Awake users who want different locked-screen display behavior, Command Palette extension authors, and administrators affected by the Mouse Without Borders mapping issue have concrete scenarios to assess. Users whose existing setup works have less reason to leave a stable deployment merely to acquire another version number.

The central takeaway is straightforward: v0.103.3151.0 adds control and improves reporting, but its boundaries remain important. Awake retains a Modern Standby caveat, CPU reporting changes are not performance gains, and the shortcut and mapping fixes address defined cases. Treat it as the development preview Microsoft labels it, test the behavior that matters on the relevant hardware, and resist turning a useful collection of improvements into a promise the release never made.