Technical Documentation: microsoft/PowerToys

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (README.md) Copy Section

Microsoft PowerToys

[Installation](#-installation) · [Documentation](https://aka.ms/powertoys-docs) · [Blog](https://aka.ms/powertoys-releaseblog) · [Release notes](#-whats-new)

🔨 Utilities Copy Chapter

PowerToys includes over 30 utilities to help you customize and optimize your Windows experience:

📦 Installation Copy Chapter

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. 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 such as Chocolatey and Scoop. If these are your preferred install solutions, you can find the install instructions there.

✨ What's new? Copy Chapter

To see what's new, check out the release notes.

🛣️ Roadmap Copy Chapter

For v0.102, we're working on modernizing several utilities with WinUI 3, expanding Command Palette with tabs and JavaScript/TypeScript extensions, and adding new productivity improvements across PowerToys.

❤️ PowerToys Community Copy Chapter

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 Copy Chapter

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 Copy Chapter

This project has adopted the Microsoft Open Source Code of Conduct.

Privacy statement Copy Chapter

The application logs basic diagnostic data (telemetry). For more privacy information and what we collect, see our PowerToys Data and Privacy documentation.

Doc Devdocs Website README (`doc/devdocs-website/README.md`) Copy Section

Dev Docs Website

This folder hosts the docmd project that turns the PowerToys developer
documentation in doc/devdocs into a static website.

Generated site Copy Chapter

The site/ folder is the docmd build output. It is not committed to the repository — it is
git-ignored and rebuilt on demand. You only need it locally when previewing your changes (see below).

Publishing is handled by the
Publish Dev Docs Website GitHub Action, which
runs whenever files under doc/devdocs (or this folder) change on the main branch — it can also
be triggered manually from the Actions tab. The action builds the site and deploys it straight to
GitHub Pages as an artifact, so nothing is written back to the repository.

[!NOTE]
The action requires GitHub Pages to be enabled with Source: GitHub Actions under the repository
Settings → Pages.

Editing the docs Copy Chapter

To change the documentation, edit the Markdown files under doc/devdocs. The remaining
files in this folder are maintained by hand and are safe to edit:

• docmd.config.json — docmd configuration (title, source, output, plugins)
• package.json — pins the docmd version used to build the site
• docmd-plugins/ — local build-time docmd plugins

[!TIP]
Link to repository files with repo-root-relative paths such as /src/modules/.../Foo.cpp.
VS Code resolves these against the workspace root (so they open the local file), and the
bundled github-source-links plugin rewrites them to
https://github.com/microsoft/PowerToys/blob/main/... on the published site.

Building locally Copy Chapter

Requires Node.js.

npm install      # install dependencies (first time only)
npm run dev      # start a local preview server at http://localhost:3000
npm run build    # generate the static site into ./site

Doc Devdocs Readme (`doc/devdocs/readme.md`) Copy Section

PowerToys Developer Documentation

Welcome to the PowerToys developer documentation. This documentation provides information for developers who want to contribute to PowerToys or understand how it works.

Getting Started Copy Chapter

Prerequisites Copy Section

1. Windows 10 April 2018 Update (version 1803) or newer
2. Visual Studio 2026 (recommended) or Visual Studio 2022 17.4+ with the following workloads/components:
   • Desktop Development with C++
   • WinUI application development
   • .NET desktop development
   • Windows 11 SDK (10.0.22621.0)
   • Windows 11 SDK (10.0.26100.3916)
3. .NET 8 SDK
4. Enable long paths in Windows (see Enable Long Paths for details)

Tip: You can install Visual Studio with all required workloads automatically using the WinGet configuration files in the repository:

powershell Copy

winget configure .config\configuration.winget

Pick the file that matches your VS edition (e.g., configuration.vsProfessional.winget or configuration.vsEnterprise.winget).

Fork, Clone, and Set Up Copy Section

1. Fork the repo on GitHub if you haven't already
2. Clone your fork locally
3. Run the automated setup script (recommended):

.\tools\build\setup-dev-environment.ps1

This script will:

• Enable Windows long path support (requires administrator privileges)
• Enable Windows Developer Mode (requires administrator privileges)
• Guide you through installing required Visual Studio components from .vsconfig
• Initialize git submodules

Run with -Help to see all available options.

Manual setup (if you prefer not to use the script)

Install Visual Studio dependencies

1. Open the PowerToys.slnx file.
2. If you see a dialog that says install extra components in the solution explorer pane, click install

Alternatively, import the .vsconfig file from the repository root using Visual Studio Installer to install all required workloads.

Initialize submodules

This is a one-time step required before you can compile most parts of PowerToys.

1. Open a terminal
2. Navigate to the folder you cloned PowerToys to.
3. Run git submodule update --init --recursive

Building Copy Section

Using Visual Studio

• Open PowerToys.slnx in Visual Studio.
• In the Solutions Configuration drop-down menu select Release or Debug.
• From the Build menu choose Build Solution, or press Control+Shift+b on your keyboard.
• The build process may take several minutes depending on your computer's performance. Once it completes, the PowerToys binaries will be in your repo under x64\Release\.
  • You can run x64\Release\PowerToys.exe directly without installing PowerToys, but some modules (i.e. PowerRename, ImageResizer, File Explorer extension etc.) will not be available unless you also build the installer and install PowerToys.

Using Command Line

You can also build from the command line using the provided scripts in tools\build\:

# Build the full solution (auto-detects platform)
.\tools\build\build.ps1

# Build with specific configuration
.\tools\build\build.ps1 -Platform x64 -Configuration Release

# Build only essential projects (runner + settings) for faster iteration
.\tools\build\build-essentials.ps1

# Build everything including the installer (Release only)
.\tools\build\build-installer.ps1

Debugging Copy Section

See Debugging for detailed debugging techniques, including Visual Studio setup, attaching to child processes, and troubleshooting build errors.

Creating a New PowerToy Copy Section

See Creating a New PowerToy for an end-to-end guide covering module architecture, settings integration, installer packaging, and testing.

Building Command Palette Extensions Copy Section

If you want to build your own extensions for Command Palette, check out the Command Palette extensibility documentation. It covers how to create, package, and distribute custom extensions that integrate with Command Palette.

Development Guidelines Copy Chapter

• Coding Guidelines - Development guidelines and best practices
• Coding Style - Code formatting and style conventions
• Logging and Telemetry - How to use logging and telemetry
• Localization - How to support multiple languages
• UI Testing - How to write UI tests for PowerToys
• Developing with VS Code - Build, debug, and contribute using VS Code

Rules Copy Chapter

• Follow the pattern of what you already see in the code.
• Coding style.
• Try to package new functionality/components into libraries that have nicely defined interfaces.
• Package new functionality into classes or refactor existing functionality into a class as you extend the code.
• When adding new classes/methods/changing existing code, add new unit tests or update the existing tests.

GitHub Workflow Copy Chapter

• Before starting to work on a fix/feature, make sure there is an open issue to track the work.
• Add the In progress label to the issue, if not already present. Also add a Cost-Small/Medium/Large estimate and make sure all appropriate labels are set.
• If you are a community contributor, you will not be able to add labels to the issue; in that case just add a comment saying that you have started work on the issue and try to give an estimate for the delivery date.
• If the work item has a medium/large cost, using the markdown task list, list each sub item and update the list with a check mark after completing each sub item.
• Before opening a PR, ensure your changes build successfully locally and functionality tests pass. This is especially important for AI-assisted (vibe coding) contributions—always verify AI-generated code works as intended. Exploratory PRs or draft PRs for discussion are exceptions.
• When opening a PR, follow the PR template.
• When you'd like the team to take a look (even if the work is not yet fully complete) mark the PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
• When the PR is approved, let the owner of the PR merge it. For community contributions, the reviewer who approved the PR can also merge it.
• Use the Squash and merge option to merge a PR. If you don't want to squash it because there are logically different commits, use Rebase and merge.
• Close issues automatically when referenced in a PR. You can use closing keywords in the body of the PR to have GitHub automatically link your PR to the issue.

Core Architecture Copy Chapter

• Architecture Overview - Overview of the PowerToys architecture and module interface
• Runner and System tray - Details about the PowerToys Runner process
• Settings - Documentation on the settings system
• Installer - Information about the PowerToys installer
• Modules - Documentation for individual PowerToys modules

Common Components Copy Chapter

• Context Menu Handlers - How PowerToys implements and registers Explorer context menu handlers
• Monaco Editor - How PowerToys uses the Monaco code editor component across modules

Tools Copy Chapter

• Tools Overview - Overview of tools in PowerToys
• Build Tools - Tools that help building PowerToys
• Bug Report Tool - Tool for collecting logs and system information
• Debugging Tools - Specialized tools for debugging
• Fuzzing Testing - How to implement and run fuzz testing for PowerToys modules

Processes Copy Chapter

• Release Process - How PowerToys releases are prepared and published
• Update Process - How PowerToys updates work
• GPO Implementation - Group Policy Objects implementation details

Other Resources Copy Chapter

• aka.ms links - List of short links
• Issue/PR commands - Special commands for managing issues and pull requests

Building the Installer Copy Chapter

Our installer is two parts, an EXE and an MSI. The EXE (Bootstrapper) contains the MSI and handles more complex installation logic.

• The EXE installs all prerequisites and installs PowerToys via the MSI. It has additional features such as the installation flags (see below).
• The MSI installs the PowerToys binaries.

The installer can only be compiled in Release mode; steps 1 and 2 must be performed before the MSI can be compiled.

1. Compile PowerToys.slnx. Instructions are listed above.
2. Compile BugReportTool.sln tool. Path from root: tools\BugReportTool\BugReportTool.sln (details listed below)
3. Compile StylesReportTool.sln tool. Path from root: tools\StylesReportTool\StylesReportTool.sln (details listed below)
4. Compile PowerToysSetup.slnx Path from root: installer\PowerToysSetup.slnx (details listed below)

See Installer for more details on building and debugging the installer.

Doc Dsc Overview (`doc/dsc/overview.md`) Copy Section

ms.date: 10/18/2025 ms.topic: overview title: PowerToys DSC Overview Copy Chapter

PowerToys DSC Overview

Synopsis Copy Chapter

PowerToys supports Desired State Configuration (DSC) v3 for declarative configuration management of PowerToys settings.

Description Copy Chapter

PowerToys includes Microsoft Desired State Configuration (DSC) support
through the PowerToys.DSC.exe command-line tool, enabling you to:

• Declare and enforce desired configuration states for PowerToys
  utilities.
• Automate PowerToys configuration across multiple systems.
• Integrate PowerToys configuration with WinGet and other DSC-compatible
  tools.
• Version control your PowerToys settings as code.

The PowerToys DSC implementation provides a settings resource that
manages configuration for all PowerToys utilities (modules). Each utility
can be configured independently, allowing granular control over your
PowerToys environment.

Usage methods Copy Chapter

PowerToys DSC can be used in three ways:

1. Direct execution with PowerToys.DSC.exe Copy Section

Execute DSC operations directly using the PowerToys.DSC.exe command-line
tool:

# Get current settings for a module
PowerToys.DSC.exe get --resource 'settings' --module Awake

# Set settings for a module
$input = '{"settings":{...}}'
PowerToys.DSC.exe set --resource 'settings' --module Awake --input $input

# Test if settings match desired state
PowerToys.DSC.exe test --resource 'settings' --module Awake --input $input

For detailed information, see PowerToys.DSC.exe command reference.

2. Microsoft Desired State Configuration (DSC) Copy Section

Use PowerToys DSC resources in standard DSC configuration documents:

# powertoys-config.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Configure Awake
    type: Microsoft.PowerToys/AwakeSettings
    properties:
      settings:
        properties:
          keepDisplayOn: true
          mode: 1
        name: Awake
        version: 0.0.1

3. WinGet Configuration Copy Section

Integrate PowerToys configuration with WinGet package installation:

# winget-powertoys.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor: dscv3
resources:
  - name: Install PowerToys
    type: Microsoft.WinGet.DSC/WinGetPackage
    properties:
      id: Microsoft.PowerToys
      source: winget
  
  - name: Configure FancyZones
    type: Microsoft.PowerToys/FancyZonesSettings
    properties:
      settings:
        properties:
          fancyzones_shiftDrag: true
          fancyzones_mouseSwitch: true
        name: FancyZones
        version: 1.0

Available resources Copy Chapter

PowerToys DSC provides the following resources:

For detailed information, see the Settings Resource Reference and the
Keyboard Manager Profile Resource Reference.

Available modules Copy Chapter

The settings resource supports configuration for the following PowerToys
utilities:

Common operations Copy Chapter

List all supported modules Copy Section

PowerToys.DSC.exe modules --resource 'settings'

Get current configuration Copy Section

# Get configuration for a specific module.
PowerToys.DSC.exe get --resource 'settings' --module FancyZones

# Export configuration (identical to get).
PowerToys.DSC.exe export --resource 'settings' --module FancyZones

Apply configuration Copy Section

# Set configuration for a module.
$input = '{"settings":{...}}'
PowerToys.DSC.exe set --resource 'settings' --module FancyZones --input $input

Validate configuration Copy Section

# Test if current state matches desired state.
$input = '{"settings":{...}}'
PowerToys.DSC.exe test --resource 'settings' --module FancyZones --input $input

Generate schema Copy Section

# Get JSON schema for a module's settings.
PowerToys.DSC.exe schema --resource 'settings' --module FancyZones

Generate DSC manifest Copy Section

# Generate manifest for a specific module.
$outputDir = "C:\manifests"
PowerToys.DSC.exe manifest --resource 'settings' --module FancyZones `
  --outputDir $outputDir

# Generate manifests for all modules.
PowerToys.DSC.exe manifest --resource 'settings' --outputDir $outputDir

Examples Copy Chapter

For complete examples, see:

• Settings Resource Examples
• Individual module documentation in the modules folder

See also Copy Chapter

• Settings Resource Reference
• PowerToys.DSC.exe Command Reference
• Module Documentation
• Microsoft DSC Documentation
• WinGet Configuration Documentation

Doc Gpo README (`doc/gpo/README.md`) Copy Section

Group Policies

Since version 0.64, PowerToys is released on GitHub with Administrative Templates that allows you to configure PowerToys using Group Policies. You can get the group policy files in each release of PowerToys over at https://github.com/microsoft/PowerToys/releases.

For detailed instructions and notes, head over to learn.microsoft.com and see the PowerToys Group Policy section.

Doc Specs Readme (`doc/specs/readme.md`) Copy Section

Specs

All approved specs are inside the Wiki spec section

Spec process Copy Chapter

1. A proposed item is either new or requesting additional design
2. Spec is written inside the Specs folder and a PR happens with feedback.
3. Once spec is signed off, we move it into the Wiki spec section.

Thought process behind this Copy Chapter

We want a single wholistic for PowerToys. This includes both source code, docs, and specs. At the same time, we want to ensure items have pull requests and feedback. Since the wiki cannot do PR's, we will do the process above.

This process will allow specs to be image rich but not impact the primary repository's size as more items come online.

Doc Devdocs Common Readme (`doc/devdocs/common/readme.md`) Copy Section

Common

The common folder contains projects with code, that is used in multiple projects.

[FilePreviewCommon](FilePreviewCommon.md) Copy Chapter

This project contains common code for file previewing.

Doc Devdocs Modules Readme (`doc/devdocs/modules/readme.md`) Copy Section

PowerToys Modules

This section contains documentation for individual PowerToys modules, including their architecture, implementation details, and debugging tools.

Available Modules Copy Chapter

Adding New Module Documentation Copy Chapter

When adding documentation for a new module:

1. Create a dedicated markdown file for the module (e.g., modulename.md)
2. If the module has specialized debugging tools, consider creating a separate tools document (e.g., modulename-tools.md)
3. Update this index with links to the new documentation
4. Follow the existing documentation structure for consistency

Doc Devdocs Tools Readme (`doc/devdocs/tools/readme.md`) Copy Section

PowerToys tools

Tools in PowerToys are standalone apps and scripts that run outside of the PowerToys runner. They help developers and users to debug and test PowerToys features.

The source code of the tools can be found in the tools folder. The compiled tools are saved under {PowerToysInstallPath}\tools.

Overview of the tools Copy Chapter

Following tools are currently available:

• BugReportTool - A tool to collect logs and system information for bug reports.
• Build tools - A set of scripts that help building PowerToys.
• Monitor info report - A small diagnostic tool which helps identifying WinAPI bugs related to the physical monitor detection.
• project template - A Visual Studio project template for a new PowerToys project.
• StylesReportTool - A tool to collect information about an open window.
• Verification scripts - A set of scripts that help verifying the PowerToys installation.

Doc Devdocs Core Settings Project Overview (`doc/devdocs/core/settings/project-overview.md`) Copy Section

Overview

Settings is Windows App Sdk WinUI3 .Net Unpackaged desktop application. More details about Windows App Sdk can be found in Windows App SDK - Calling all Windows developers!. More details about WinUI can be found in Build apps with WinUI.

Settings V2 Project structure Copy Chapter

The Settings project .Net WinUI3 based project which
follows the MVVM architectural pattern where the graphical user interface is separated from the view models.

[UI Components:](/src/settings-ui/Settings.UI/)

The UI Components are part of PowerToys.Settings project. It contains the xaml files for each of the UI components. It also contains the Hotkey logic for the settings control.

[Viewmodels:](/src/settings-ui/Settings.UI.Library)

The Settings.UI.Library project contains the data that is to be rendered by the UI components.

[Settings Runner:](/src/settings-ui/Settings.UI)

The function of the settings runner project is to communicate all changes that the user makes in the user interface, to the runner so that it can be dispatched and reflected in all the modules.

Doc Devdocs Core Settings Readme (`doc/devdocs/core/settings/readme.md`) Copy Section

PowerToys Settings System

PowerToys provides a comprehensive settings system that allows users to configure various aspects of the application and its modules. This document provides an overview of the settings system architecture and links to more detailed documentation.

Table of Contents

1. Settings overview
2. UI Architecture
3. ViewModels
4. Settings Implementation
5. Group Policy Integration
6. Data flow
   • Inter-Process Communication with runner
   • Communication with modules
7. Settings Utilities
8. Custom Hotkey control and keyboard hook handling
9. Compatibility with legacy settings and runner
10. XAML Island tweaks
11. Telemetry
12. DSC Configuration

Doc Devdocs Modules Keyboardmanager README (`doc/devdocs/modules/keyboardmanager/README.md`) Copy Section

Table of Contents

Public overview - Microsoft Learn

Quick Links Copy Chapter

All Issues
Bugs
Pull Requests

The devdocs for Keyboard Manager have been divided into the following modules:

1. Keyboard Manager Module
2. Keyboard Event Handlers
3. Keyboard Manager UI
4. Keyboard Manager Common
5. Debugging Guide

Doc Devdocs Modules Launcher Readme (`doc/devdocs/modules/launcher/readme.md`) Copy Section

Table of Contents

1. Architecture
2. Debugging
3. New Plugin Checklist
4. Project Structure
5. Telemetry
6. Plugins
   • Overview
   • Calculator
   • Folder
   • History
   • Indexer
   • OneNote
   • Program
   • Registry
   • Shell
   • Time and Date
   • Unit Converter
   • Uri
   • Value Generator
   • Web Search
   • Windows Settings
   • Windows System Commands
   • Window Walker

Doc Devdocs Modules Mouseutils Readme (`doc/devdocs/modules/mouseutils/readme.md`) Copy Section

Mouse Utilities

Public overview - Microsoft Learn

Quick Links Copy Chapter

All Issues
Bugs
Pull Requests

Mouse Utilities is a collection of tools designed to enhance mouse and cursor functionality on Windows. The module contains several sub-utilities that provide different mouse-related features.

Overview Copy Chapter

Mouse Utilities includes the following sub-modules:

• Find My Mouse: Helps locate the mouse pointer by creating a visual spotlight effect when activated
• Mouse Highlighter: Visualizes mouse clicks with customizable highlights
• Mouse Jump: Allows quick cursor movement to specific screen locations
• Mouse Pointer Crosshairs: Displays crosshair lines that follow the mouse cursor
• Mouse Button Lock: A ClickLock equivalent for the left, right, and middle mouse buttons - hold a button to lock it down for hands-free dragging, then click any button to release (left is optional and off by default)

Architecture Copy Chapter

Most of the sub-modules (Find My Mouse, Mouse Highlighter, Mouse Pointer Crosshairs, and Mouse Button Lock) run within the PowerToys Runner process as separate threads. Mouse Jump is more complex and runs as a separate process that communicates with the Runner via events.

Code Structure Copy Section

Settings UI

• MouseUtilsPage.xaml
• MouseJumpPanel.xaml
• MouseJumpPanel.xaml.cs
• MouseUtilsViewModel.cs
• MouseUtilsViewModel_MouseJump.cs

Runner and Module Implementation

• FindMyMouse
• MouseHighlighter
• MousePointerCrosshairs
• MouseJump
• MouseJumpUI
• MouseJump.Common
• MouseButtonLock

Community Contributors Copy Chapter

• Michael Clayton (@mikeclayton): Contributed the initial version of the Mouse Jump tool and several updates based on his FancyMouse utility
• Raymond Chen (@oldnewthing): Find My Mouse is based on Raymond Chen's SuperSonar

Known Issues Copy Chapter

• Mouse Highlighter has a reported bug where the highlight color stays on after toggling opacity to 0

UI Test Automation Copy Chapter

Mouse Utilities is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:

Mouse Utils UI Test Migration Progress

See Also Copy Chapter

For more detailed implementation information, please refer to the individual utility documentation pages linked above.

Activation Process

1. A keyboard hook detects the activation shortcut (typically double-press of Ctrl)
2. A WM_PRIV_SHORTCUT message is sent to the sonar window
3. StartSonar() is called to display a spotlight animation centered on the mouse pointer
4. The animation automatically fades or can be cancelled by user input

Mouse Highlighter Copy Section

Mouse Highlighter visualizes mouse clicks by displaying a highlight effect around the cursor when clicked.

Key Components

• Uses Windows Composition API for rendering
• Main implementation in MouseHighlighter.cpp
• Core logic handled by the WndProc function

Activation Process

1. When activated, it creates a transparent overlay window
2. A mouse hook monitors for click events
3. On click detection, the highlighter draws a circle or other visual indicator
4. The highlight effect fades over time based on user settings

Mouse Pointer Crosshairs Copy Section

Displays horizontal and vertical lines that intersect at the mouse cursor position.

Key Components

• Uses Windows Composition API for rendering
• Core implementation in InclusiveCrosshairs.cpp
• Main logic handled by the WndProc function

Activation Process

1. Creates a transparent, layered window for drawing crosshairs
2. When activated via shortcut, calls StartDrawing()
3. Sets a low-level mouse hook to track cursor movement
4. Updates crosshairs position on every mouse movement
5. Includes auto-hide functionality for cursor inactivity

Mouse Jump Copy Section

Allows quick mouse cursor repositioning to any screen location through a grid-based UI.

Key Components

• Runs as a separate process (PowerToys.MouseJumpUI.exe)
• Communicates with Runner process via events
• UI implemented in MainForm.cs

Activation Process

1. When shortcut is pressed, Runner triggers the shared event MOUSE_JUMP_SHOW_PREVIEW_EVENT
2. The MouseJumpUI process displays a screen overlay
3. User selects a destination point on the overlay
4. Mouse cursor is moved to the selected position
5. The UI process can be terminated via the TERMINATE_MOUSE_JUMP_SHARED_EVENT

Debugging Copy Chapter

Find My Mouse, Mouse Highlighter, and Mouse Pointer Crosshairs Copy Section

• Debug by attaching to the Runner process directly
• Set breakpoints in the respective utility code files (e.g., FindMyMouse.cpp, MouseHighlighter.cpp, InclusiveCrosshairs.cpp)
• Call the respective utility by using the activation shortcut (e.g., double Ctrl press for Find My Mouse)
• During debugging, visual effects may appear glitchy due to the debugger's overhead

Mouse Jump Copy Section

• Start by debugging the Runner process
• Then attach the debugger to the MouseJumpUI process
• Note: Debugging MouseJumpUI directly is challenging as it requires the Runner's process ID as a parameter

Known Issues Copy Chapter

• Mouse Highlighter has a reported bug where the highlight color stays on after toggling opacity to 0

Doc Devdocs Modules Peek Readme (`doc/devdocs/modules/peek/readme.md`) Copy Section

PowerToys Peek

Public overview - Microsoft Learn

Quick Links Copy Chapter

All Issues
Bugs
Pull Requests

Documentation is currently under construction

Dev file previewer Copy Chapter

The previewer for developer files uses the project in [FileExplorerCommon] common project to render monaco. You can find its documentation here: /doc/devdocs/common/FilePreviewCommon.md.

Doc Devdocs Modules Launcher Plugins Overview (`doc/devdocs/modules/launcher/plugins/overview.md`) Copy Section

Structural Overview

The following basic functions are common to each of the plugins. They perform some rudimentary operations such as initialization of the plugin, executing the query that has been entered, loading context menu icons, updating settings when configurations are altered in the settings UI, and updating the theme of the icons when the theme changed event is triggered.

IPlugin Interface Copy Chapter

Each plugin implements the IPlugin interface which comprises of the Init() and Query() functions.

`Init` Copy Section

• The Init() function initializes the context, storage and settings of each plugin. This is equivalent to a constructor and is the first function to be called in the Main.cs file for each plugin.

`Query` Copy Section

• For every query that the user enters into PT Run, the PluginManager.cs executes the Query() function in the Main.cs file corresponding to each Plugin.

Context Menu Icons Copy Section

• The ContextMenus are loaded for each result based on the type of the result.
• The various types of ContextMenu functionalities are:
  • Open containing folder
  • Run as Administrator
  • Open in console
  • Copy path

UpdateSettings Copy Section

• This function updates the settings of each plugin based on the changes made by the user in the settings UI.
• Eg: To disable drive detection in the indexer plugin, when the user checks or unchecks the drive detection check box, the UpdateSettings() function dispatches the changes in the check box to the plugin.

ThemeChanged Copy Section

• This function is invoked when there is a change in the theme of PT Run.
• It is used to update the IconPath for each plugin based on the theme.

Save Copy Section

• This function saves the configurations of each plugin so that they can be loaded the next time.

Score Copy Section

• The user query is executed against each of the plugins and the result list view is updated with results from each of the plugins.
• The ordering of the results is based on the Score of each Result.
• Each plugin assigns a score to a result based on its relevance. The results with higher scores are displayed higher in the list view and vice versa.

Plugin settings Copy Chapter

Plugin settings that are editable from the settings are stored in PowerToys Run\settings.json. In the very first run, those settings are populated from plugin' plugin.json file. Unlike Wox we do not support multiple action keywords. Instead, we have ActionKeyword and IsGlobal options.

Doc ThirdPartyRunPlugins (`doc/thirdPartyRunPlugins.md`) Copy Section

Third-Party plugins for PowerToy Run

This is a collection of third-party plugins for PowerToys Run created by the community.

Installing and upgrading third-party PowerToys Run plugins Copy Chapter

The recommended path for the plugins is %LOCALAPPDATA%\Microsoft\PowerToys\PowerToys Run\Plugins.

1. Close PowerToys.
2. Copy the plugin folder to %LOCALAPPDATA%\Microsoft\PowerToys\PowerToys Run\Plugins.
3. If you're upgrading a plugin, delete the previous version.
4. Open PowerToys.

Refer to plugin instruction for more details.

Disclaimer Copy Chapter

The following plugins are created and maintained by third-party and not officially supported or recognized by Microsoft. Users install and use these plugins at their own risk, and Microsoft takes no responsibility for their functionality or any potential issues they may cause.

Support Copy Chapter

Contact the developers of a plugin directly for assistance with a specific plugin.

General plugins Copy Chapter

Extending software plugins Copy Chapter

Below are community created plugins that target a website or software. They are created and maintained by a third-party and not officially supported or recognized by the website or software they extend.

Doc Devdocs AkaLinks (`doc/devdocs/akaLinks.md`) Copy Section

Full list of aka links

Doc Devdocs Cli Conventions (`doc/devdocs/cli-conventions.md`) Copy Section

CLI Conventions

This document describes the conventions for implementing command-line interfaces (CLI) in PowerToys modules.

PATH-Visible Command Naming and Location Copy Chapter

• Name module CLI command shims PowerToys.<ModuleName>.CLI.exe (for example, PowerToys.ImageResizer.CLI.exe).
• Install these shims in the bin subfolder of the PowerToys installation directory, which the installer adds to PATH.

Every command is the same PowerToys.CliShim.exe payload (tools/CliShim/) installed under a different name. The shim resolves which CLI to launch from its own file name, forwards the raw argument tail unchanged, shares the caller's console, and returns the CLI's exit code. The CLI runs in a job object owned by the shim, so killing the shim kills the CLI with it; processes the CLI itself starts (the Settings window, for example) break away and survive.

On a per-machine install the bin folder is created with a protected DACL (MachinePathFolderSddl in installer/PowerToysSetupVNext/Common.wxi) so that a custom installation root cannot leave a machine-PATH folder writable by standard users. Author that <CreateFolder> on the same component as the folder's <Environment> PATH entry, so the two cannot drift apart.

Adding a new shim Copy Section

1. Add a <CliShim> item to tools/CliShim/CliShimManifest.props with the command name and the target's path relative to bin. Write that path with / separators, and against the installed layout (see Signing and Deployment) - which is where the CLI ends up, not where it is built from.
2. Add the matching <Component> and <ComponentRef> to installer/PowerToysSetupVNext/CliShims.wxs, using the command name as the File/@Name.

CliShim.vcxproj fails the build if the command names in those two drift apart, build-installer.ps1 fails the build if a RelativeTarget does not resolve to a real executable, and CliShim.UnitTests generates its expectations from the same manifest, so there is no third list to update.

Shim exit codes Copy Section

The shim returns the target CLI's exit code unchanged. It substitutes one of its own codes only when the CLI never ran, using values outside the range the CLIs use themselves:

Library Copy Chapter

Use the System.CommandLine library for CLI argument parsing. The version is already defined in Directory.Packages.props:

<PackageVersion Include="System.CommandLine" Version="2.0.1" />

Add the reference to your project:

<PackageReference Include="System.CommandLine" />

Option Naming and Definition Copy Chapter

• Use --kebab-case for long form (e.g., --shrink-only).
• Use single -x for short form (e.g., -s, -w).
• Pass the long name first, then any aliases: new Option("--silent", "-s").
• Create options using Option<T> and set Description to descriptive help text.
• Add validators (option.Validators.Add(...), reporting failures with result.AddError(...)) for options that require range or format checking.

RootCommand Setup Copy Chapter

• Create a RootCommand with a brief description.
• Add all options and arguments to the command (rootCommand.Options.Add(...), rootCommand.Arguments.Add(...)).
• RootCommand includes the standard --help and --version options. Remove them from rootCommand.Options if the CLI renders its own help or reuses their aliases.

Parsing Copy Chapter

• Use rootCommand.Parse(args) to parse CLI arguments.
• Extract option values using parseResult.GetValue(option).
• To run a handler, register it with command.SetAction(parseResult => ...) and call parseResult.Invoke() or parseResult.InvokeAsync().

Parse/Validation Errors Copy Section

• On parse/validation errors, print error messages and usage, then exit with non-zero code.

Examples Copy Chapter

Reference implementations:

• Awake: src/modules/Awake/Awake/Program.cs
• ImageResizer: src/modules/imageresizer/ui/Cli/

Help Output Copy Chapter

• Provide a PrintUsage() method for custom help formatting if needed.

Best Practices Copy Chapter

1. Consistency: Follow existing module patterns.
2. Documentation: Always provide help text for each option.
3. Validation: Validate input and provide clear error messages.
4. Atomicity: Make one logical change per PR; avoid drive-by refactors.
5. Build/Test Discipline: Build and test synchronously, one terminal per operation.
6. Style: Follow repo analyzers (.editorconfig, StyleCop) and formatting rules.

Logging Requirements Copy Chapter

• Use ManagedCommon.Logger for consistent logging.
• Initialize logging early in Main().
• Use dual output (console + log file) for errors and warnings to ensure visibility.
• Reference: src/modules/imageresizer/ui/Cli/CliLogger.cs

Telemetry and Privacy Requirements Copy Chapter

• Every module CLI must record usage telemetry through the existing PowerToys telemetry infrastructure, respecting the user's diagnostic data consent.
• Record a fixed, allowlisted command category and a success flag based on the final exit code. Do not collect raw arguments, file paths, monitor IDs, profile values, or other user-provided content.
• Telemetry failures must not change command output, exit codes, or exception behavior.
• Add every new CLI telemetry event to DATA_AND_PRIVACY.md in the same PR, describing its purpose and collected data.
• Follow Telemetry Events for event naming, privacy tags, and implementation details.

Error Handling Copy Chapter

Exit Codes Copy Section

• 0: Success
• 1: General error (parsing, validation, runtime)
• 2: Invalid arguments (optional)

Exception Handling Copy Section

• Always wrap Main() in try-catch for unhandled exceptions.
• Log exceptions before exiting with non-zero code.
• Display user-friendly error messages to stderr.
• Preserve detailed stack traces in log files only.

Testing Requirements Copy Chapter

• Include tests for argument parsing, validation, and edge cases.
• Place CLI tests in module-specific test projects (e.g., src/modules/[module]/tests/*CliTests.cs).

Signing and Deployment Copy Chapter

• CLI executables are signed automatically in CI/CD.
• New CLI tools: Add your executable and dll to .pipelines/ESRPSigning_core.json in the signing list.
• CLI executables are deployed either to the installation root (e.g., C:\Program Files\PowerToys\FancyZonesCLI.exe) or, for WinUI 3 modules, next to their module in WinUI3Apps\ (e.g., C:\Program Files\PowerToys\WinUI3Apps\PowerToys.ImageResizerCLI.exe). PATH-visible shims are deployed to C:\Program Files\PowerToys\bin\, and a shim's RelativeTarget is resolved from that bin folder against the installed layout - not against the source tree.
• Use self-contained deployment (import Common.SelfContained.props).

Doc Devdocs Commands (`doc/devdocs/commands.md`) Copy Section

Issue/PR commands

The PowerToys repository uses some special keywords to help manage issues and pull requests. Here is a list of the most important commands you can use in issue and PR descriptions or comments.

Defining new commands Copy Chapter

Most of these commands are using the Microsoft GitHub Policy Service bot. Its commands are defined in the PowerToys policy configuration file.

Other automated tasks Copy Chapter

AI-assisted issue triage Copy Section

New and updated issues are processed by a GitHub Agentic Workflow that combines
deterministic checks with a bounded GitHub Copilot pass. It maintains one
triage comment, adds a matching primary Product-* label and version label,
requests blocking author information, recommends updating older PowerToys
versions, surfaces likely duplicates, and analyzes a sanitized subset of
attached PowerToys diagnostic reports.

Duplicate closure is submitted as a native GitHub suggestion. A maintainer must
accept or decline it. Accepting the suggestion closes the issue as a duplicate
and links it to the selected canonical issue.

The `Needs-Author-Feedback` label Copy Section

If an issue or pull request retains this label without activity for 7 days, the
bot closes it. An author comment removes the label from issues and pull
requests, and an author push removes it from pull requests. Removing the label
manually also disables scheduled closure.

Filtering users that want to contribute Copy Section

If a user utters their intention to contribute (e.g., by using the phrase "I want to contribute" in an issue or PR), the bot will add a comment with a link to the "Would you like to contribute to PowerToys?" thread.

Doc Devdocs Disk Usage Footprint (`doc/devdocs/disk-usage-footprint.md`) Copy Section

PowerToys disk usage footprint overview

As of the v0.66 of PowerToys, core runtime dlls are being shipped self-contained as a part of PowerToys. During the installation process, hard-links are being created for every module that needs any of these shared libraries.

Why do this work? Copy Chapter

Our main motivations for doing are the following:

1. Be able to install PowerToys without UAC elevation
2. PowerToys has a reduced disk space when components are shared.
3. Reduce additional downloads for dependencies

Current self-contained runtimes Copy Chapter

These dll's are installed in /dll/ folder structure.

• Windows Application SDK runtime
• .NET Desktop Runtime 7
• Microsoft Visual C++ Runtime

So why does PowerToys have a larger footprint now? Copy Chapter

Before the hard-link work was done, each of these runtimes had to be installed, so there were more items being installed outside just the PowerToys install directory. This space would not have been accounted.

File Explorer treats hard-links the same as "original"/regular files/directories (https://learn.microsoft.com/troubleshoot/windows-server/backup-and-storage/disk-space-problems-on-ntfs-volumes#other-ntfs-features-that-may-cause-file-allocation-confusion), not as links. This results in File Explorer reporting size of PowerToys installation directory bigger than it is (more than 2GB).

How much space is actually being used Copy Chapter

As of v0.66 of PowerToys, the installed footprint is ~660MB.

When we were prototyping and validating, here was our running table of results and why we took the route we did.

Our process to verify current install footprint Copy Chapter

We created a quick virtual machine. We chose to use our fresh Windows 10 test virtual machines here.

Empty disk details Copy Section

Install PowerToys to empty disk Copy Section

PowerToys installation directory size shown by File Explorer Copy Section

As mentioned above, File Explorer shows size of PowerToys installation dir as every hard-link is a regular file for itself

PowerToys size shown by App->Installed apps Copy Section

Disk usage with PowerToys installed Copy Section

Real disk usage of PowerToys is shown by inspecting disk usage after installing PowerToys. Used space is now 695MB, comparing to ~35MB used space for empty disk gives us the size of ~660MB for PowerToys installation dir.

PowerShell command calculating size of non-hardlinks files Copy Section

Size of regular files (non-hard-links) and hard-links can also be obtained by running following PowerShell command in PowerToys installation dir:

Regular files:
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -ne HardLink | Measure-Object -Property Length -Sum

Hard-links
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -e HardLink | Measure-Object -Property Length -Sum

Running these commands for PowerToys v0.66 shows that size of regular files is way less than size of hard-links pointing to some of those regular files because PowerShell (same as File Explorer) also takes the size of hard-links as of regular files.

Doc Devdocs Embedded Msix (`doc/devdocs/embedded-msix.md`) Copy Section

How to integrate new MSIX module with PowerToys Settings and WiX installer

issue_11705_with_example branch contains HelloWorld UWP C# MSIX application which reads its module settings and is installed along PowerToys.

Steps Copy Chapter

• uncomment everything near "TODO: Use to activate embedded MSIX" comments
• build PowerToys solution
• deploy HelloModule module and sign it with a self-signed certificate (don't forget to put it into a trusted store)
• build PowerToysSetup solution and install it

Type HelloModule into start search and observe that it was installed:

Open PowerToys settings and change the stub setting to something:

Open HelloModule:

First time you press "Load Settings", it'll detect that it doesn't have permissions to access local file system and open its system settings window, toggle it there:

(it's a known uwp limitation, see https://stackoverflow.com/a/53533414/657390)

HelloModule will close then, restart it, press "Load Settings" and you should see that the application was able to load the setting string which was set by the settings app:

Doc Devdocs Events (`doc/devdocs/events.md`) Copy Section

Telemetry Events

PowerToys collects limited telemetry to understand feature usage, reliability, and product quality. When adding a new telemetry event, follow the steps below to ensure the event is properly declared, documented, and available after release.

⚠️ Important: Telemetry must never include personal information, file paths, or user‑generated content.

Developer Effort Overview (What to Expect) Copy Chapter

Adding a telemetry event is a multi-step process that typically spans several areas of the codebase and documentation.

At a high level, developers should expect to:

1. Within one PR:
   1. Add a new telemetry event(s) to module
   2. Add the new event(s) DATA_AND_PRIVACY.md
2. Reach out to @carlos-zamora or @chatasweetie so internal scripts can process new event(s)

Privacy Guidelines Copy Section

NEVER log:

• User data (text, files, emails, etc.)
• File paths or filenames
• Personal information
• Sensitive system information
• Anything that could identify a specific user

DO log:

• Feature usage (which features, how often)
• Success/failure status
• Timing/performance metrics
• Error types (not error messages with user data)
• Aggregate counts

Event Naming Convention Copy Section

Follow this pattern: UtilityName_EventDescription

Examples:

• ColorPicker_Session
• FancyZones_LayoutApplied
• PowerRename_Rename
• AdvancedPaste_FormatClicked
• CmdPal_ExtensionInvoked

Adding Telemetry Events to PowerToys Copy Chapter

PowerToys uses ETW (Event Tracing for Windows) for telemetry in both C++ and C# modules. The telemetry system is:

• Opt-in by default (disabled since v0.86)
• Privacy-focused - never logs personal info, file paths, or user-generated content
• Controlled by registry - HKEY_CURRENT_USER\Software\Classes\PowerToys\AllowDataDiagnostics

C++ Telemetry Implementation Copy Section

Core Components

Pattern for C++ Modules

1. Create a Trace class inheriting from telemetry::TraceBase (src/common/Telemetry/TraceBase.h):

   c Copy

   // trace.h
   #pragma once
   #include <common/Telemetry/TraceBase.h>
   
   class Trace : public telemetry::TraceBase
   {
   public:
       static void MyEvent(/* parameters */);
   };

2. Implement events using TraceLoggingWriteWrapper:

   cpp Copy

   // trace.cpp
   #include "trace.h"
   #include <common/Telemetry/TraceBase.h>
   
   TRACELOGGING_DEFINE_PROVIDER(
       g_hProvider,
       "Microsoft.PowerToys",
       (0x38e8889b, 0x9731, 0x53f5, 0xe9, 0x01, 0xe8, 0xa7, 0xc1, 0x75, 0x30, 0x74),
       TraceLoggingOptionProjectTelemetry());
   
   void Trace::MyEvent(bool enabled)
   {
       TraceLoggingWriteWrapper(
           g_hProvider,
           "ModuleName_EventName",           // Event name
           TraceLoggingBoolean(enabled, "Enabled"),  // Event data
           ProjectTelemetryPrivacyDataTag(ProjectTelemetryTag_ProductAndServicePerformance),
           TraceLoggingBoolean(TRUE, "UTCReplace_AppSessionGuid"),
           TraceLoggingKeyword(PROJECT_KEYWORD_MEASURE));
   }

Key C++ Telemetry Macros

C# Telemetry Implementation Copy Section

Core Components

Pattern for C# Modules

1. Create an event class inheriting from EventBase and implementing IEvent:

   csharp Copy

   using System.Diagnostics.CodeAnalysis;
   using System.Diagnostics.Tracing;
   using Microsoft.PowerToys.Telemetry;
   using Microsoft.PowerToys.Telemetry.Events;
   
   namespace MyModule.Telemetry
   {
       [EventData]
       [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicProperties)]
       public class MyModuleEvent : EventBase, IEvent
       {
           // Event properties (logged as telemetry data)
           public string SomeProperty { get; set; }
           public int SomeValue { get; set; }
   
           // Required: Privacy tag
           public PartA_PrivTags PartA_PrivTags => PartA_PrivTags.ProductAndServiceUsage;
   
           // Optional: Set EventName in constructor (defaults to class name)
           public MyModuleEvent(string prop, int val)
           {
               EventName = "MyModule_EventName";
               SomeProperty = prop;
               SomeValue = val;
           }
       }
   }

2. Log the event:

PowerToysTelemetry.Log.WriteEvent(new MyModuleEvent("value", 42));

Privacy Tags (C#)

Update DATA_AND_PRIVACY.md file Copy Section

Add your new event(s) to DATA_AND_PRIVACY.md.

Launch Product Version Containing the new events Copy Chapter

Events do not become active until they ship in a released PowerToys version. After your PRs are merged:

• The event will begin firing once users install the version that includes it
• In order for PowerToys to process these events, you must complete the next section

Next Steps Copy Chapter

Reach out to @carlos-zamora or @chatasweetie so internal scripts can process new event(s).

Summary Copy Chapter

Required steps:

1. In one PR:
   • Add the event(s) in code
   • Document event(s) in DATA_AND_PRIVACY.md
2. Ship the change in a PowerToys release
3. Reach out for next steps

Doc Devdocs Guidance (`doc/devdocs/guidance.md`) Copy Section

Coding Guidance

Working With Strings Copy Chapter

In order to support localization YOU SHOULD NOT have hardcoded UI display strings in your code. Instead, use resource files to consume strings.

For CPP Copy Section

Use StringTable resource to store the strings and resource header file(resource.h) to store Id's linked to the UI display string. Add the strings with Id's referenced from the header file to the resource-definition script file. You can use Visual Studio Resource Editor to create and manage resource files.

• resource.h:

XXX must be a unique int in the list (mostly the int ID of the last string id plus one):

#define IDS_MODULE_DISPLAYNAME                    XXX

• StringTable in resource-definition script file validmodulename.rc:

STRINGTABLE
BEGIN
    IDS_MODULE_DISPLAYNAME               L"Module Name"
END

• Use the GET_RESOURCE_STRING(UINT resource_id) method to consume strings in your code.

#include <common.h>

std::wstring GET_RESOURCE_STRING(IDS_MODULE_DISPLAYNAME)

For C# Copy Section

Use XML resource file(.resx) to store the UI display strings and Resource Manager to consume those strings in the code. You can use Visual Studio to create and manage XML resources files.

• Resources.resx

<data name="ValidUIDisplayString" xml:space="preserve">
    <value>Description to be displayed on UI.</value>
    <comment>This text is displayed when XYZ button clicked.</comment>
  </data>

• Use Resource Manager to consume strings in code.

System.Resources.ResourceManager manager = new System.Resources.ResourceManager(baseName, assembly);
string validUIDisplayString = manager.GetString("ValidUIDisplayString", resourceCulture);

In case of Visual Studio is used to create the resource file. Simply use the Resources class in auto-generated Resources.Designer.cs file to access the strings which encapsulate the Resource Manager logic.

string validUIDisplayString = Resources.ValidUIDisplayString;

More On Coding Guidance Copy Chapter

Please review these brief docs below relating to our coding standards, etc.

• Coding Style
• Code Organization

Doc Devdocs Logging (`doc/devdocs/logging.md`) Copy Section

Logging

Logging plays an important part in determining bugs in our code. It provides context for the developers about where and when errors occur.

Where are the logs saved Copy Chapter

• Most of the logs are saved under %LOCALAPPDATA%/Microsoft/PowerToys.
• For low-privilege processes (like preview handlers) the logs are saved under %USERPROFILE%/AppData/LocalLow/Microsoft/PowerToys.

Logs are normally in a subfolder with the module name as title.

The BugReportTool will take logs from both locations when executed.

Using a logger in a project Copy Chapter

Spdlog Copy Section

In C++ projects we use the awesome spdlog library for logging as a git submodule under the deps directory. To use it in your project, just include spdlog.props in a .vcxproj like this:

<Import Project="..\..\..\deps\spdlog.props" />

It'll add the required include dirs and link the library binary itself.

PowerToys Logger in ManagedCommon Copy Section

For C# projects there is a static logger class in Managed Common called Logger.

To use it, add a project reference to ManagedCommon and add the following line of code to all the files using the logger:

using ManagedCommon;

In the Main function (or a function with a similar meaning (like App in a App.xaml.cs file)) you have to call InitializeLogger and specify the location where the logs will be saved (always use a path scheme similar to this example):

Logger.InitializeLogger("\\FancyZones\\Editor\\Logs");

For a low-privilege process you have to set the optional second parameter to true:

Logger.InitializeLogger("\\FileExplorer\\Monaco\\Logs", true);

The Logger class contains the following logging functions:

// Logs an error that the utility encountered
Logger.LogError(string message);
Logger.LogError(string message, Exception ex);
// Logs an error that isn't that grave
Logger.LogWarning(string message);
// Logs what the app is doing at the moment
Logger.LogInfo(string message);
// Like LogInfo just with infos important for debugging
Logger.LogDebug(string message);
// Logs the current state of the utility.
Logger.LogTrace();

Doc Devdocs Run As Admin Detection (`doc/devdocs/run-as-admin-detection.md`) Copy Section

This file has been moved

PowerToys and running as Administrator

Doc Devdocs Watson Queries (`doc/devdocs/watson-queries.md`) Copy Section

Watson queries [msft only]

Catch all Copy Chapter

• Catch all

[!NOTE]
Update the AppScope_AppVersion (and the installer file names below) to the current release version when triaging.

EXE name Copy Chapter

• Machine installer (x64)
• Machine installer (arm64)
• User installer (x64)
• User installer (arm64)
• Main exe
• PT Run / example

DLL based Copy Chapter

• KBM
• Power Preview
• SVG Thumbnail
• SVG Preview Pane
• Markdown Preview Pane

Doc Dsc Profile Resource (`doc/dsc/profile-resource.md`) Copy Section

ms.date: 07/20/2026 ms.topic: reference title: Keyboard Manager Profile Resource Copy Chapter

Keyboard Manager Profile Resource

Synopsis Copy Chapter

Manages the Keyboard Manager remapping profile — key remappings and shortcut
remappings — declaratively through DSC v3.

Description Copy Chapter

The profile resource deploys Keyboard Manager key and shortcut remappings.
While the settings resource manages a module's settings (for
KeyboardManager: the enabled state and editor options), the profile
resource manages the remapping profile itself, which Keyboard Manager stores
separately from its settings.

Keys are written with friendly names instead of virtual-key codes, so
configurations are easy to author and review:

profile:
  keys:
    - { from: CapsLock, to: Esc }
  shortcuts:
    - { from: "Ctrl+Shift+A", to: "Ctrl+V" }

The only supported module is KeyboardManager. The DSC resource type is
Microsoft.PowerToys/KeyboardManagerProfile.

Important — replace semantics: Applying the resource replaces the
whole remapping profile with the declared state. Remappings created in
the Keyboard Manager editor that are not part of the configuration are
removed. Use export to capture the current remappings before switching a
machine to declarative management.

When the profile is applied while PowerToys is running, the Keyboard Manager
engine reloads it immediately; otherwise the profile takes effect the next
time PowerToys starts. Note that the remappings are only active when the
Keyboard Manager utility is enabled (see the KeyboardManager module).

Profile schema Copy Chapter

The profile object is required and has two entry lists. An empty profile
(profile: {}) removes every remapping:

`keys[]` — single-key remappings Copy Section

Exactly one of to or toText must be set.

`shortcuts[]` — shortcut remappings Copy Section

Exactly one of to, toText, runProgram, or openUri must be set. A
shortcut from requires at least one modifier plus one action key, and may
add a chord second key after a comma ("Win+O, K"). Win+L and
Ctrl+Alt+Delete are handled by Windows before any application and are
rejected, as in the Keyboard Manager editor.

`runProgram` object Copy Section

Key names Copy Chapter

Key names are case-insensitive and independent of the active keyboard
layout. Shortcut parts are joined with +; a chord second key follows after
a comma.

Note: Punctuation names refer to the key's physical position on a US
layout (Semicolon is the VK_OEM_1 key), so profiles behave identically
regardless of the machine's keyboard layout.

Common operations Copy Chapter

# Get or export the current remapping profile
PowerToys.DSC.exe get --resource 'profile' --module KeyboardManager
PowerToys.DSC.exe export --resource 'profile' --module KeyboardManager

# Apply a remapping profile
$input = '{"profile":{"keys":[{"from":"CapsLock","to":"Esc"}]}}'
PowerToys.DSC.exe set --resource 'profile' --module KeyboardManager --input $input

# Test whether the current remappings match the desired state
PowerToys.DSC.exe test --resource 'profile' --module KeyboardManager --input $input

# Get the JSON schema of the resource
PowerToys.DSC.exe schema --resource 'profile' --module KeyboardManager

Examples Copy Chapter

Example 1 - Deploy remappings with DSC Copy Section

dsc config set --file keyboardmanager-profile.dsc.yaml

# keyboardmanager-profile.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Deploy key remappings
    type: Microsoft.PowerToys/KeyboardManagerProfile
    properties:
      profile:
        keys:
          - { from: CapsLock, to: Esc }
          - { from: Insert, to: Disable }
          - { from: F2, toText: "[email protected]" }
        shortcuts:
          - { from: "Ctrl+Shift+A", to: "Ctrl+V" }
          - { from: "Win+O, K", toText: "chord-triggered text" }
          - { from: "Ctrl+Alt+N", to: "Ctrl+S", targetApp: "notepad.exe", exactMatch: true }
          - from: "Ctrl+Alt+T"
            runProgram:
              filePath: "%WINDIR%\\System32\\cmd.exe"
              args: "/k echo hello"
          - { from: "Ctrl+Alt+B", openUri: "https://github.com/microsoft/PowerToys" }

Example 2 - Install PowerToys and deploy remappings with WinGet Copy Section

winget configure winget-kbm-profile.yaml

# winget-kbm-profile.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor: dscv3
resources:
  - name: Install PowerToys
    type: Microsoft.WinGet.DSC/WinGetPackage
    properties:
      id: Microsoft.PowerToys
      source: winget

  - name: Enable Keyboard Manager
    type: Microsoft.PowerToys/KeyboardManagerSettings
    properties:
      settings:
        properties:
          Enabled: true
        name: KeyboardManager
        version: 1.0

  - name: Deploy key remappings
    type: Microsoft.PowerToys/KeyboardManagerProfile
    properties:
      profile:
        keys:
          - { from: CapsLock, to: LCtrl }
        shortcuts:
          - { from: "Ctrl+Shift+V", toText: "Best regards,\nContoso IT" }

Example 3 - Capture existing remappings Copy Section

Export the current remappings on a reference machine, then reuse them in a
configuration document:

PowerToys.DSC.exe export --resource 'profile' --module KeyboardManager
# {"profile":{"keys":[{"from":"CapsLock","to":"Esc"}],"shortcuts":[]}}

See also Copy Chapter

• KeyboardManager Module
• Settings Resource Reference
• PowerToys DSC Overview

Doc Dsc Settings Resource (`doc/dsc/settings-resource.md`) Copy Section

ms.date: 10/18/2025 ms.topic: reference title: Settings Resource Copy Chapter

Settings Resource

Synopsis Copy Chapter

Manages configuration settings for PowerToys utilities (modules).

Description Copy Chapter

The settings resource provides Microsoft Desired State Configuration (DSC)
support for managing PowerToys configuration. It enables declarative
configuration of PowerToys utilities, allowing you to define, test, and
enforce desired states for each module.

Each PowerToys utility (module) has its own configurable properties that can
be managed through this resource. The settings resource supports standard DSC
operations: get, set, test, export, schema, and manifest generation.

Supported modules Copy Chapter

The settings resource supports the following PowerToys modules:

• App - General application settings (enable/disable utilities, run at
  startup, theme, etc.).
• AdvancedPaste - Advanced clipboard and paste operations.
• AlwaysOnTop - Window pinning configuration.
• Awake - Keep-awake timer settings.
• ColorPicker - Color picker activation and format settings.
• CropAndLock - Window cropping settings.
• EnvironmentVariables - Environment variable editor settings.
• FancyZones - Window layout and zone configuration.
• FileLocksmith - File lock detection settings.
• FindMyMouse - Mouse locator settings.
• Hosts - Hosts file editor settings.
• ImageResizer - Image resize configuration.
• KeyboardManager - Key remapping and shortcut settings.
• MeasureTool - Screen measurement tool settings.
• MouseButtonLock - Hands-free mouse button drag-lock settings.
• MouseHighlighter - Mouse highlighting configuration.
• MouseJump - Mouse jump navigation settings.
• MousePointerCrosshairs - Crosshair display settings.
• Peek - File preview settings.
• PowerAccent - Accent character selection settings.
• PowerOCR - Text extraction settings.
• PowerRename - Bulk rename configuration.
• RegistryPreview - Registry file preview settings.
• ShortcutGuide - Keyboard shortcut overlay settings.
• Workspaces - Application workspace settings.
• ZoomIt - Screen zoom and annotation settings.

For detailed property information for each module, see the individual module
documentation.

Operations Copy Chapter

List supported modules Copy Section

List all modules that can be configured with the settings resource.

Direct execution:

# List all configurable modules.
PowerToys.DSC.exe modules --resource 'settings'

Get current state Copy Section

Retrieve the current configuration state for a module.

Direct execution:

# Get current settings for a module.
PowerToys.DSC.exe get --resource 'settings' --module <ModuleName>

DSC configuration:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Get Awake settings
    type: Microsoft.PowerToys/AwakeSettings
    properties: {}

WinGet configuration:

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor: dscv3
resources:
  - name: Get FancyZones settings
    type: Microsoft.PowerToys/FancyZonesSettings
    properties: {}

Export current state Copy Section

Export the current configuration state. The output is identical to the get
operation.

Direct execution:

# Export current settings for a module.
PowerToys.DSC.exe export --resource 'settings' --module <ModuleName>

Set desired state Copy Section

Apply a configuration to a module, updating only the properties that differ
from the desired state.

Direct execution:

# Set desired configuration for a module.
$input = '{
  "settings": {
    "properties": {
      "keepDisplayOn": true,
      "mode": 1
    },
    "name": "Awake",
    "version": "0.0.1"
  }
}'
PowerToys.DSC.exe set --resource 'settings' --module Awake --input $input

DSC configuration:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Configure Awake
    type: Microsoft.PowerToys/AwakeSettings
    properties:
      settings:
        properties:
          keepDisplayOn: true
          mode: 1
        name: Awake
        version: 0.0.1

WinGet configuration:

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor: dscv3
resources:
  - name: Install and configure PowerToys
    type: Microsoft.WinGet.DSC/WinGetPackage
    properties:
      id: Microsoft.PowerToys
      source: winget
  
  - name: Configure FancyZones
    type: Microsoft.PowerToys/FancyZonesSettings
    properties:
      settings:
        properties:
          fancyzones_shiftDrag: true
          fancyzones_mouseSwitch: true
          fancyzones_displayOrWorkAreaChange_moveWindows: true
        name: FancyZones
        version: 1.0

Test desired state Copy Section

Verify whether the current configuration matches the desired state.

Direct execution:

# Test if current state matches desired state.
$input = '{
  "settings": {
    "properties": {
      "keepDisplayOn": true,
      "mode": 1
    },
    "name": "Awake",
    "version": "0.0.1"
  }
}'
PowerToys.DSC.exe test --resource 'settings' --module Awake --input $input

The output includes an _inDesiredState property indicating whether the
configuration matches (true) or differs (false).

DSC configuration:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Test Awake configuration
    type: Microsoft.PowerToys/AwakeSettings
    properties:
      settings:
        properties:
          keepDisplayOn: true
          mode: 1
        name: Awake
        version: 0.0.1

Get schema Copy Section

Generate the JSON schema for a module's settings, describing all configurable
properties and their types.

Direct execution:

# Get JSON schema for a module.
PowerToys.DSC.exe schema --resource 'settings' --module Awake

# Format for readability.
PowerToys.DSC.exe schema --resource 'settings' --module Awake `
  | ConvertFrom-Json | ConvertTo-Json -Depth 10

Generate manifest Copy Section

Create a DSC resource manifest file for one or all modules.

Direct execution:

# Generate manifest for a specific module.
$outputDir = "C:\manifests"
PowerToys.DSC.exe manifest --resource 'settings' --module Awake `
  --outputDir $outputDir

# Generate manifests for all modules.
PowerToys.DSC.exe manifest --resource 'settings' --outputDir $outputDir

# Print manifest to console (omit --outputDir).
PowerToys.DSC.exe manifest --resource 'settings' --module Awake

Examples Copy Chapter

Example 1 - Enable and configure FancyZones Copy Section

This example enables FancyZones and configures window dragging behavior using
direct execution.

# Get current FancyZones settings.
$current = PowerToys.DSC.exe get --resource 'settings' --module FancyZones `
  | ConvertFrom-Json

# Modify settings.
$desired = @{
    settings = @{
        properties = @{
            fancyzones_shiftDrag = $true
            fancyzones_mouseSwitch = $true
            fancyzones_displayOrWorkAreaChange_moveWindows = $true
        }
        name = "FancyZones"
        version = "1.0"
    }
} | ConvertTo-Json -Depth 10 -Compress

# Apply configuration.
PowerToys.DSC.exe set --resource 'settings' --module FancyZones `
  --input $desired

Example 2 - Configure multiple utilities with DSC Copy Section

This example configures multiple PowerToys utilities in a single DSC
configuration.

# powertoys-multi.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Enable PowerToys utilities
    type: Microsoft.PowerToys/AppSettings
    properties:
      settings:
        properties:
          Enabled:
            Awake: true
            FancyZones: true
            PowerRename: true
            ColorPicker: true
        name: App
        version: 1.0
  
  - name: Configure Awake
    type: Microsoft.PowerToys/AwakeSettings
    properties:
      settings:
        properties:
          keepDisplayOn: true
          mode: 1
        name: Awake
        version: 0.0.1
  
  - name: Configure ColorPicker
    type: Microsoft.PowerToys/ColorPickerSettings
    properties:
      settings:
        properties:
          changecursor: true
          copiedcolorrepresentation: "HEX"
        name: ColorPicker
        version: 1.0

Example 3 - Install and configure with WinGet Copy Section

This example installs PowerToys and applies configuration using WinGet.

# winget-powertoys-setup.yaml
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor: dscv3
resources:
  - name: Install PowerToys
    type: Microsoft.WinGet.DSC/WinGetPackage
    properties:
      id: Microsoft.PowerToys
      source: winget
      ensure: Present
  
  - name: Configure general settings
    type: Microsoft.PowerToys/AppSettings
    properties:
      settings:
        properties:
          run_elevated: true
          startup: true
          theme: "dark"
        name: App
        version: 1.0
  
  - name: Configure FancyZones
    type: Microsoft.PowerToys/FancyZonesSettings
    properties:
      settings:
        properties:
          fancyzones_shiftDrag: true
          fancyzones_zoneSetChange_moveWindows: true
        name: FancyZones
        version: 1.0
  
  - name: Configure ImageResizer
    type: Microsoft.PowerToys/ImageResizerSettings
    properties:
      settings:
        properties:
          ImageResizerSizes:
            - Name: Small
              Width: 854
              Height: 480
              Unit: Pixel
              Fit: Fit
            - Name: Medium
              Width: 1920
              Height: 1080
              Unit: Pixel
              Fit: Fit
        name: ImageResizer
        version: 1.0

Apply the configuration:

winget configure winget-powertoys-setup.yaml

Example 4 - Test configuration drift Copy Section

This example tests whether the current configuration matches the desired
state.

# Define desired state.
$desired = @{
    settings = @{
        properties = @{
            keepDisplayOn = $true
            mode = 1
        }
        name = "Awake"
        version = "0.0.1"
    }
} | ConvertTo-Json -Depth 10 -Compress

# Test for drift.
$result = PowerToys.DSC.exe test --resource 'settings' --module Awake `
  --input $desired | ConvertFrom-Json

if ($result._inDesiredState) {
    Write-Host "Configuration is in desired state"
} else {
    Write-Host "Configuration has drifted from desired state"
    
    # Apply configuration.
    PowerToys.DSC.exe set --resource 'settings' --module Awake `
      --input $desired
}

Example 5 - Export all module configurations Copy Section

This example exports configuration for all modules.

# Get list of all modules.
$modules = PowerToys.DSC.exe modules --resource 'settings'

# Export each module's configuration.
$configurations = @{}
foreach ($module in $modules) {
    $config = PowerToys.DSC.exe export --resource 'settings' `
      --module $module | ConvertFrom-Json
    $configurations[$module] = $config
}

# Save to file.
$configurations | ConvertTo-Json -Depth 10 `
  | Out-File "powertoys-backup.json"

See also Copy Chapter

• PowerToys DSC Overview
• Module Documentation
• WinGet Configuration

Doc Specs FancyZones DCR (`doc/specs/FancyZones-DCR.md`) Copy Section

FancyZones library brief overview Copy Section

1. Zone - Class which is basically wrapper around rectangle structure, representing one zone inside applied zone layout. ZoneSet is holding array of these which represent zone layout.

2. ZoneSet - Class implementing actual zone layout applied. What this means is that ZoneSet is responsible for actual calculation of rectangle coordinates (whether is grid or canvas layout) and moving window through them. WorkArea holds ZoneSet structure which represents currently active zone set.

3. WorkArea - Class representing work area, which is defined by monitor and current virtual desktop. For an example, if You have two monitors connected and two virtual desktops, You have 4 work areas available, and each of them can have separate zone layout. WorkArea is describing single work area. As mentioned before it holds active ZoneSet.

4. FancyZones - Top level entity and entry point for all user actions (which goes through actual module interface). Some of the main responsibilities of FancyZones class:

   text Copy

   1. Starting FancyZones Editor (C#) with appropriate command line arguments on user request.
    2. Keeping track of WorkArea per monitor (currently active work area on each connected monitor).
    3. Keeping track of active virtual desktops. This is performed in separate thread by polling VirtualDesktopIDs registry key and parsing its content.
    4. Detecting every change in work environment, such as creating / destroying / switching between virtual desktops, closing FancyZones Editor, changing display settings and handling those changes.

Proposal for modifications of handling described in 4.4: Copy Section

Currently after each of the mentioned changes in work environment we are calling EnumDisplayMonitors windows API, and passing callback function to it. EnumDisplayMonitors works asynchronous and triggers that callback for each work area available (as mentioned in previous example, for two monitors and two virtual desktops, we have this callback triggered four times). As mentioned previously, we have WorkArea class as our representation of this work area. And what we do, every time this callback is triggered we destroy previous WorkArea object for that work area and create new one, even though that it is most likely that nothing has changed (e.g. just switching back and forth between virtual desktops). This constant creation and deletion of WorkArea has caused some problems in the past and it's not ideal for some other fixes we would like to make in the multi-monitor/multi-desktop scenario.

As mentioned in 4.3 we already have tracker of virtual desktops implemented. Idea is to use this functionality and to extend it bit more, so we can track if work area (WorkArea) is new one, or already processed and skip creating new WorkArea objects and deleting old ones every time, even if nothing changed in it. We will keep map, where virtual desktop id is the key, and values are already processed monitors (virtual desktop exists across all monitors). Once we receive callback from EnumDisplayMonitors, indicating work area (defined by virtual desktop id and monitor) we can check if it’s new or not, and act accordingly (create new WorkArea for it or not). Deleting virtual desktop (which is also registered in 4.3), will trigger updates in this map, and also updates in our JSON storage.

Doc Specs SCOOBE (`doc/specs/SCOOBE.md`) Copy Section

PowerToys SCOOBE Dialog

• What is it: Post-upgrade prompted dialog that walks users through the latest additions to PowerToys utilities and functionalities
• Author: Deondre Davis
• Spec Status: Draft

1. Overview Copy Chapter

1.1. Executive Summary Copy Section

To expand on our end-user on-boarding efforts, we seek to resolve the critical issue of informing users of new additions and improvements to PowerToys during upgrade scenarios. We currently list release notes on the main repository, in addition to affiliated information on Microsoft Docs. However, neither of these mediums are internal to the application, and thus requires users to proactively seek out information on what's been updated, or merely notice by chance what's been changed from their regular usage. As these are not ideal experiences, this document describes the inclusion of a post-upgrade 'SCOOBE' prompt that launches the previously developed OOBE dialog loaded with new information related to upgrade improvements and additions.

1.2. Key-Definitions/Concepts Copy Section

Here are definitions for words and acronyms found throughout this document to ensure clarity:

• OOBE: Out of box experience – The users' initial interactions with the product immediately after installing the product and/or launching the product for the first time.
• SCOOBE: Second chance out of box experience - The users' initial interactions with the product immediately after upgrading the product and/or launching the product for the first time after upgrading.

1.3. Goals and Non-Goals Copy Section

Goals:

• Create a guided prompt that exposes the user to a brief overview of the new features and/or improvements included with the latest version of PowerToys.

Non-Goals:

• Present a copy-and-paste replica of the repository release notes. This information needs to be readily consumable, often requiring visual demonstrations of the new behavior and/or functionality that's either not possible or not necessary to depict on the repository release notes.

2. Definition of Success Copy Chapter

2.1. Customers

The PowerToys SCOOBE is for existing and new power users and developers who are looking to tune and streamline their Windows experience for greater productivity and enhanced user experience. As the PowerToys customer base tends to be particularly biased against SCOOBE prompts in general, we need to present the PowerToys SCOOBE dialog in such a way that it provides immediate value to end-users to improve the likelihood of users discovering all the additions to PowerToys by making their way through the prompt.

2.2. Expected Impact: Customer, and Technology Outcomes

• High Reliability : Less than 0.1% crash rate.
• Increased Activation : 50% or more adoption rate of new feature/utilities among PowerToys users who already utilize associated tools.
• High User Retention: 25% or more active PowerToys users after 28 days of upgrade.

3. Requirements Copy Chapter

The SCOOBE dialog builds off the currently implemented OOBE dialog originally drafted by Niels's mock-up.

3.1. Functional Requirements

3.1.1. Functional Requirements Overview

* - By storing the content for SCOOBE externally from the application, the PowerToys team can update/adjust information without being constrained to PowerToys' release cycles. This is critical in the event of errors or miscommunications that would otherwise be difficult, if not impossible, to correct if stored locally to the app and shipped with the version of PowerToys being released. The content will likely be stored in an archive maintained in the PowerToys GitHub Wiki.

3.1.2. Page Content

4. Measure Requirements Copy Chapter

5. Appendix Copy Chapter

5.1. Mock-ups Copy Section

5.1.1. SCOOBE Dialog Layout

5.1.2. OOBE Welcome Page

5.1.3. Example Textual Descriptions for Updates

v0.29 -> v0.31:

• New Features & Improvements
  • FancyZones
    • Dark mode for the editor
    • Certain settings (e.g. number of zones, spacing settings) can now be set on individual layouts.
  • PowerToys Run
    • Service management plugin (Start, stop, …)
    • Registry key plugin
    • System action plugin (Reboot, lock, ...)
• Bug fixes Highlights
  • Fixed OneDrive SVG Bug (#9999)
  • SVG are scaled appropriately when view box is provided (#9999)

v0.31 -> v0.33:

• New Features & Improvements
  • General
    • Added a 'First time load' experience. The hope is a quick, light way to learn about basic functionality
  • FancyZones
    • New options to change zone activation algorithm
  • PowerToys Run
    • Plugin Manager now is in settings. You can directly turn on / off, include items in general search, and change the action key
    • Improved support for additional window managers by abstracting out shell process calls
    • ~ will now act as the user home directory in Folder plugin
• Bug fixes Highlights
  • Fix for PT Run registering the hotkey on non-supported OS versions (#9999)

v0.33 -> v0.35:

• New Features & Improvements
  • Color Picker
    • Esc can now be used to exit the editor
  • FancyZones
    • Added hotkeys and quick swap functionality for custom layouts! Users can now assign a hotkey in the editor and use it to quickly set a desktop's zones with Ctrl + Win + Alt + NUMBER key binding, or by pressing the hotkey while dragging a window.
  • PowerToys Run
    • Users can specify where to show the launcher window
    • New plugin added to support opening previously used Visual Studio Code workspaces, remote machines (SSH or Codespaces), and containers! When enabled, use { to query for available workspaces. Please note, this plugin is off by default.
    • Shell history now saves the raw command instead of the resolved command. A command like %appdata% would now save in the Shell history as is instead of C:\Users\YourUserName\AppData\Roaming.
• Bug fixes Highlights
  • PowerToys will start requiring Windows 10 v1903 or greater after 0.35.x release. (#9999)
  • Fixed FancyZones placement algorithm for when the Taskbar is vertical (#9999)

Doc Specs WinGet Manifest Keyboard Shortcuts Schema (`doc/specs/WinGet Manifest Keyboard Shortcuts schema.md`) Copy Section

WinGet Manifest Keyboard Shortcuts schema

1 What this spec is about Copy Chapter

This spec provides an extension to the existing WinGet manifest schema in form of an additional yaml file, that describes keyboard shortcuts the application provides.

These yaml files are saved on a per-user base and so called manifest interpreters can then display these manifests in a human-friendly version.

1.1 What this spec is not about Copy Section

This spec does not provide a way to back up or save user-defined keyboard shortcuts.

2 Save location of manifests Copy Chapter

2.1 WinGet Copy Section

These files are saved online along with the other manifest files in the WinGet Package repository.

2.2 Locally Copy Section

All manifests and one index file are saved locally under %LocalAppData%/Microsoft/WinGet/KeyboardShortcuts. All apps are allowed to add their manifest files there. In addition Package Managers (like WinGet) and manifest interpreters (like PowerToys Shortcut Guide) can control and add other manifests themselves.

2.2.1 Downloading manifests

When WinGet or other package managers download a package, they should also download the corresponding keyboard shortcuts manifest file and save it in the local directory, given such a file exists in the WinGet repository.

The downloader is also responsible for updating the local index.yaml file, which contains all the information about the different manifest files that are saved in the same directory.

2.2.2 Updating manifests

When a manifest interpreter starts, it should download the latest version of the manifests from the WinGet repository and save them in the local directory. If a manifest interpreter is not able to download the manifests or they do not exist, it should use the locally saved manifests.

The updater is also responsible for updating the local index.yaml file, which contains all the information about the different manifest files that are saved in the same directory.

Note: WinGet must provide a way to update the keyboard shortcuts manifests given a package id.

2.3 File names Copy Section

The file name of a keyboard shortcuts file is the WinGet package identifier, plus the locale of the strings of the file and at last the .KBSC.yaml file extension.

For example the package "test.bar" saves its manifest with en-US strings in test.bar.en-US.KBSC.yaml.

2.3.1 No winget package available

If an application has no corresponding WinGet package its name starts with a plus (+) symbol.

2.4 Reserved namespaces Copy Section

Every name starting with +WindowsNT is reserved for the Windows OS and its components.

3 File syntax Copy Chapter

All relevant files are written in YAML.

Note: A JSON schema will be provided as soon as the spec reaches a further step

3.1 Manifest Schema vNext Keyboard Shortcuts File Copy Section

PackageName:                # The package unique identifier
WindowFilter:               # The filter of window processes to which the shortcuts apply to
BackgroundProcess:          # Optionally allows applying WindowFilter to background processes
Shortcuts:                  # List of sections with keyboard shortcuts
  - SectionName:            # Name of the category of shortcuts
    Properties:             # List of shortcuts in the category
      - Name:               # Name of the shortcut
        Description:        # Optional description of the shortcut
        AdditionalInfo:     # Optional additional information about the shortcut
        Recommended:        # Optionally determines if the shortcut is displayed in a designated recommended area
        Shortcut:           # An array of shortcuts that need to be pressed
          - Win:            # Determines if the Windows Key is part of the shortcut
            Ctrl:           # Determines if the Ctrl Key is part of the shortcut
            Shift:          # Determines if the Shift Key is part of the shortcut
            Alt:            # Determines if the Alt Key is part of the shortcut
            Keys:           # Array of keys that need to be pressed

Per Application/Package one or more Keyboard manifests can be declared. Every manifest must have a different locale and the same PackageName, WindowFilter and BackgroundProcess fields.

PackageName - The package unique identifier

Package identifier (see 2.1 for more information on the package identifier).

WindowFilter - The filter of window processes to which the shortcuts apply to

This field declares for which process name the shortcuts should be shown (To rephrase: For which processes the shortcut will have an effect if pressed). The value can be either an exact process executable name, for example explorer.exe or chrome.exe, or a single asterisk (*) to apply to any process. No other wildcard patterns are supported by this specification.

BackgroundProcess - Optionally allows applying WindowFilter to background processes.

Optional field

Defaults to False. Determines if WindowFilter should apply to background processes as well (Rephrased: When the process is running, the shortcuts will apply).

Shortcuts - List of sections with keyboard shortcuts

List of different section (also called categories) of shortcuts.

SectionName - Name of the category of shortcuts

Name of the section of shortcuts. Use sentence case, the same convention described under Name below.

Special sections:

Special sections start with an identifier enclosed between < and >. This declares the category as a special display. If the interpreter of the manifest file can't understand the content this section should be left out.

Properties - List of shortcuts in the category

Name - Name of the shortcut

Name of the shortcut. This is the name that will be displayed in the interpreter.

Casing:

By convention, shortcut names (and SectionName values) use sentence case: capitalize only the first word plus any proper nouns or product/feature names. For example, prefer Reopen last closed tab over Reopen Last Closed Tab, but keep Open History, Quit Slack, and Show Quick Access capitalized because those are application feature names. Match the casing the application uses for its own features rather than copying the title-case styling some apps apply to their entire shortcut list.

Description - Optional description of the shortcut

Optional description of the shortcut. This is the description that will be displayed by the interpreter.

AdditionalInfo - Optional additional information about the shortcut

Array of additional information about the shortcut. This is the additional information that will be displayed by the interpreter and are not part of this manifest.

Example:

For example, if the shortcut is only available on a certain Windows version, this information could be added here.

AdditionalInfo:
   - MinWindowsVersion: "10.0.19041.0"

Shortcut - An array of shortcuts that need to be pressed

An array of shortcuts that need to be pressed. This allows defining sequential shortcuts that need to be pressed in order to trigger the action.

Win - Determines if the Windows Key is part of the shortcut

Refers to the left Windows Key on the keyboard.

Ctrl - Determines if the Ctrl Key is part of the shortcut

Refers to the left Ctrl Key on the keyboard.

Shift - Determines if the Shift Key is part of the shortcut

Refers to the left Shift Key on the keyboard.

Alt - Determines if the Alt Key is part of the shortcut

Refers to the left Alt Key on the keyboard.

Recommended - Optionally determines if the shortcut is displayed in a designated recommended area

Optional field

Defaults to False. Determines if the shortcut should be displayed in a designated recommended area. This is a visual hint for the user that this shortcut is important.

Keys - Array of keys that need to be pressed

A string array of all the keys that need to be pressed. If a number is supplied, it should be read as a KeyCode and displayed accordingly (based on the Keyboard Layout of the user).

Literal digit keys:

Because a bare number is interpreted as a virtual-key code, a literal digit key must be authored using the <N> notation (the digit enclosed between < and >), where N is 0–9. For example, <9> represents the literal 9 key (as in the "switch to the last tab" shortcut), not the virtual-key code 9 (which is Tab). The interpreter strips the brackets and displays just the digit.

This applies only to a single literal digit. A range such as 1 - 8 is a free-form label, not a key, and is supplied verbatim (the brackets would only be trimmed from the ends, so <1> - <8> would not render as intended).

Special keys:

Special keys are enclosed between < and > and correspond to a key that should be displayed in a certain way. If the interpreter of the manifest file can't understand the content, the brackets should be left out.

By convention these tokens are written as double-quoted strings in the YAML (for example "<Enter>" and "<9>"), matching the quoting used for punctuation key values. YAML treats the quoted and unquoted forms identically, so quoting is for consistency rather than a strict requirement for bracketed tokens.

3.2.2 Example

PackageName: Microsoft.PowerToys
WindowFilter: "*"
BackgroundProcess: True
Shortcuts:
  - SectionName: General
    Properties:
      - Name: Advanced Paste
        Shortcut:
          - Win: True
            Ctrl: False
            Alt: False
            Shift: False
            Keys:
              - 86
        Description: Open Advanced Paste window
      - Name: Advanced Paste
        Shortcut:
          - Win: True
            Ctrl: True
            Alt: True
            Shift: False
            Keys:
              - 86
        Description: Paste as plain text directly

3.2 `index.yaml` file Copy Section

The index.yaml file is a file that contains all the information about the different manifest files that are saved in the same directory. This file is only available locally and is not saved in the WinGet repository as it is specific to the user.

DefaultShellName:           # The package identifier of the default shell used in Windows
Index:                      # List of all manifest files
  - WindowFilter:           # The filter of window processes to which the shortcuts apply to
    BackgroundProcess:      # Optionally allows applying WindowFilter to background processes
    Apps:                   # List of all manifest files for the filter

DefaultShellName - The package identifier of the default shell used in Windows

This declares the package identifier of the default shell used in Windows. Most commonly it is +WindowsNT.Shell. Although not enforced, only the shell declared in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell should be used here.

Index - List of all manifest files

WindowFilter - The filter of window processes to which the shortcuts apply to

See the WindowFilter field in the manifest file for more information.

BackgroundProcess - Optionally allows applying WindowFilter to background processes

Optional field

See the BackgroundProcess field in the manifest file for more information.

Apps - List of all the package identifiers applying for the filter

3.2.1 Example

DefaultShellName: "+WindowsNT.Shell"
Index:
  - Filter: "*"
    BackgroundProcess: True
    Apps: ["+WindowsNT.Shell", "Microsoft.PowerToys"]
  - Filter: "explorer.exe"
    Apps: ["+WindowsNT.WindowsExplorer"]
  - Filter: "taskmgr.exe"
    Apps: ["+WindowsNT.TaskManager"]
  - Filter: "msedge.exe"
    Apps: ["+WindowsNT.Edge"]

Doc Specs Power Display Adaptive Brightness (`doc/specs/power-display-adaptive-brightness.md`) Copy Section

Power Display – Ambient-Light (ALS) Adaptive Brightness for External Monitors

Tracking issue: microsoft/PowerToys#49038
Behaviour discussion: #49038 (with @moooyo)
Related: #47480 (schedule-based auto-brightness), #42566 (Light Switch ALS → theme), #35564 (manual multi-monitor brightness), #1052 (Quick Display adjustment umbrella, completed)

1. Overview Copy Chapter

Windows can auto-adjust the built-in laptop panel from the device's ambient light sensor (ALS), but
external monitors have no such capability — they almost never carry an ALS, and Windows will not pipe the
laptop's ALS reading to an external display. Today's PowerToys covers the two halves separately:

• Light Switch already reads the device ALS (Windows.Devices.Sensors.LightSensor → IlluminanceInLux) to drive theme.
• Power Display already writes external-monitor brightness over DDC/CI (SetMonitorBrightness, VCP 0x10).

This feature wires them together: a per-monitor Adaptive (ambient light) mode in Power Display that continuously
maps the device's ambient lux to each external monitor's brightness. It is the continuous, sensor-driven counterpart
to the time/schedule-based request tracked in #47480 — and it is what most users actually mean by "auto-brightness".

2. Goals / Non-goals Copy Chapter

Goals Copy Section

• Per-external-monitor opt-in adaptive brightness driven by the device ALS.
• A per-monitor calibration curve (lux → %), so differently-behaving panels can be matched.
• A per-monitor offset for manual/CLI nudges that rides on top of the curve (iOS-style personalization).
• Correct, safe behaviour when the sensor can't be trusted (e.g. laptop lid closed).
• Smooth, flicker-free, DDC/CI-friendly updates (smoothing + hysteresis + rate limiting).
• Coexist cleanly with manual brightness changes and the existing schedule/profile features.

Non-goals Copy Section

• Driving the built-in laptop panel (Windows already does this).
• Bundling external/USB ambient sensors (possible future extension).
• Content-adaptive / gamma-overlay dimming (a different, software-only approach).
• Colour-temperature / Night-Light behaviour.

3. Scenarios Copy Chapter

1. A laptop is docked to one or two external monitors. As the room darkens through the evening, the externals dim
   automatically to track the room — today only the built-in panel does this.
2. A light-sensitive user wants externals to follow ambient light continuously, without manual sliders or rigid schedules.
3. Two different external panels are calibrated so they look equally bright across the whole ambient range.
4. Clamshell (lid closed): the sensor is blocked, so brightness holds steady instead of dimming to black.
5. A non-DDC/CI monitor: adaptive is greyed out for that monitor with a clear "not supported" reason.

4. Fit with existing modules Copy Chapter

[ Device ALS ]
 LightSensor.ReadingChanged (lux)        <-- already consumed by Light Switch (#42566)
        │
        ▼
[ Adaptive Brightness engine ]  (new glue, lives in Power Display)
   smoothing (EMA) → hysteresis/deadband → curve(lux) + offset (per monitor) → rate limit
        │
        ▼
[ Power Display DDC/CI writer ]          <-- already exists (SetMonitorBrightness, VCP 0x10)
   per external monitor

No new module. The ALS reader can be refactored into a small shared helper so both Light Switch and Power Display
consume one sensor source (avoids two sensor subscriptions). On #47480 a maintainer noted Light Switch can already
link to a Power Display profile on a scheduler; this design adds an ambient-light trigger alongside the existing
time/sun trigger and addresses the "apply a Power Display profile without forcing a theme change" limitation raised there.

5. Core model — adaptive curve + per-monitor offset Copy Chapter

The whole feature reduces to a single formula, applied independently per external monitor:

target%(lux) = clamp( curve(lux) + offset, minPercent, maxPercent )

5.1 The loop Copy Section

Continuously: read device ALS (lux) → smooth → map through the monitor's curve → add the monitor's offset →
clamp → write via DDC/CI. One shared sensor subscription drives an independent engine per external monitor.

5.2 Per-monitor calibration curve — the multi-monitor sync mechanism Copy Section

Each monitor has its own editable lux → % curve. This is what keeps multiple monitors looking equally bright:
panels differ in nits and have non-linear backlight response, so the same ambient lux should map to a different
percentage on different panels. A per-monitor curve corrects this across the entire ambient range — something a
single scalar value cannot do (a uniform shift would keep them matched at one light level but drift apart at others).

5.3 Per-monitor offset — live personalization Copy Section

A signed per-monitor offset% added on top of the curve. Manual/CLI nudges adjust it, so the system learns the
user's preference (iOS-style) instead of overriding them. The curve does calibration; the offset does live,
personal fine-tuning (and is the quick way to nudge one screen to match the others without editing its curve).

5.4 Manual / CLI interaction while adaptive is ON Copy Section

When the user changes brightness (slider or CLI increase/decrease) with adaptive on, per-monitor manualBehavior:

• offset (default): the delta becomes a persistent offset; adaptation keeps tracking ambient, just shifted.
  A CLI "brightness +10" makes the monitor 10% brighter than the curve would pick, and tracking continues.
• pause: adaptation suspends for that monitor (hard manual override) until the user re-enables it.

6. UX / Settings design Copy Chapter

Per-monitor (WinUI3 SettingsCard/SettingsExpander):

• Brightness source: Manual (default) | Adaptive (ambient light). Adaptive is disabled with a reason string
  when (a) no ALS is present, or (b) the monitor has no DDC/CI brightness control.
• Default (zero-config): on/off + a single Responsiveness slider (Calm ↔ Snappy). A sensible default curve
  ships out of the box so most users touch nothing else.
• Advanced (collapsible): editable calibration curve (anchor points, e.g. 0 lx→20%, 50→40%, 300→70%, 1000→100%
  with a "Reset"), min/max clamps, and the manualBehavior choice.
• Live slider: when adaptive is on, the brightness slider becomes live — it reflects the current computed
  target and moves on its own as ambient changes, with an "Auto" badge and a readout (Ambient 240 lx → 65%).
  Dragging it applies the offset (§5.3); it does not silently disable adaptive.

Global: a module-level toggle and an enable/disable hotkey (consistent with other Power Display shortcuts, e.g. #48784).

7. Sensor trust & lifecycle Copy Chapter

The ALS reading is used only when it can be trusted.

7.1 ALS / DDC-CI availability Copy Section

LightSensor.GetDefault() null → adaptive unavailable everywhere (e.g. a desktop). Per monitor, if DDC/CI brightness
is unsupported → adaptive is disabled for that monitor with a reason.

7.2 Lid closed / clamshell (sensor blocked) Copy Section

When the lid is closed the ALS faces the keyboard deck and reads ~darkness, so we must not drive brightness from it.

• Detect: lid state via RegisterPowerSettingNotification(GUID_LIDSWITCH_STATE_CHANGE) (0 = closed, 1 = open),
  corroborated by QueryDisplayConfig(QDC_ONLY_ACTIVE_PATHS) for an active internal panel
  (DISPLAYCONFIG_OUTPUT_TECHNOLOGY_INTERNAL). Lid position is the true determinant — a user may have the lid open
  but the internal display disabled, and there the sensor still sees the room.
• Behaviour: on lid-close → pause adaptation and hold the last known-good brightness (never dim-to-black),
  surface a status ("Adaptive paused — lid closed / ambient sensor blocked"), and resume live on reopen.

7.3 Honest boundary + fallbacks Copy Section

Clamshell-docked is a primary scenario for this feature, yet it's exactly where the laptop ALS can't see the room.
Therefore:

• v1: full ALS adaptive when the lid is open; hold/pause when closed.
• Optional fallback: when the ALS is untrusted, fall back to time/schedule-based brightness (the #47480
  mechanism) so clamshell users still get some automation.
• Future: an external ambient sensor (monitor-integrated or USB) for true clamshell tracking (deferred).

8. Technical design Copy Chapter

8.1 ALS acquisition Copy Section

• LightSensor.GetDefault(); subscribe to ReadingChanged; set ReportInterval = max(minimumReportInterval, ~500ms)
  to limit churn/battery. Value: LightSensorReading.IlluminanceInLux (double).

8.2 Smoothing + hysteresis (anti-flicker, anti-wear) Copy Section

• EMA on lux: s_t = α·lux + (1−α)·s_{t−1} (α from the Responsiveness slider).
• Deadband: ignore changes whose mapped target moves < ~2–3% from the last applied value.
• Min update interval per monitor (~1–2 s) and optional ramping (step toward target).
• Rationale: DDC/CI writes are slow (tens–hundreds of ms) and excessive writes can flicker or wear some panels.

8.3 Mapping Copy Section

• Piecewise-linear interpolation over the anchor points; add offset; clamp to per-monitor min/max.
• Curve + offset stored per monitor (keyed by stable monitor id, as Power Display already does for profiles).

8.4 Brightness write Copy Section

• Reuse Power Display's DDC/CI path (GetPhysicalMonitorsFromHMONITOR → SetMonitorBrightness, VCP 0x10).
• Capability probe per monitor (GetMonitorBrightness / VCP support); if unsupported, disable adaptive for it.

8.5 Concurrency Copy Section

• One engine per external monitor, one shared ALS subscription. Serialize DDC/CI writes per monitor on a worker;
  never block the sensor callback. Handle monitor hotplug / dock connect-disconnect (Power Display already tracks add/remove).

9. Settings persistence Copy Chapter

Extend Power Display's settings.json per-monitor entry, e.g.:

{
  "monitors": [{
    "id": "<stable-monitor-id>",
    "brightnessSource": "adaptive",          // "manual" | "adaptive"
    "adaptive": {
      "curve": [[0,20],[50,40],[300,70],[1000,100]],  // [lux, percent] calibration, per monitor
      "offsetPercent": 0,                    // signed live nudge added on top of the curve
      "minPercent": 15,
      "maxPercent": 100,
      "responsiveness": 0.4,                 // 0..1 → EMA α / update cadence
      "manualBehavior": "offset",            // "offset" (default) | "pause"
      "deadbandPercent": 3,
      "minUpdateMs": 1500
    }
  }]
}

target = clamp( interpolate(curve, lux) + offsetPercent, minPercent, maxPercent ).

10. Telemetry Copy Chapter

Per doc/devdocs/development/logging.md, emit (privacy-respecting, counts only):

• Adaptive mode enabled/disabled per monitor; ALS-present; DDC/CI-supported; manualBehavior chosen.
• Apply-rate (writes/min), deadband/clamp suppression counts, and lid-close pause events (to validate anti-wear tuning).
• No raw lux series or PII.

11. Performance & reliability Copy Chapter

• Sensor at ~0.5–2 s cadence; writes throttled per §8.2 → negligible CPU and few DDC/CI writes.
• Worker isolates slow DDC/CI calls from the UI/sensor thread.
• Graceful degradation: no ALS → mode hidden/disabled; no DDC/CI → mode disabled per monitor with reason; lid closed → hold last-good.

12. Accessibility / Localization Copy Chapter

• All new strings via .resw + x:Uid (and discoverable by the settings search index, settings-search.md).
• Curve editor keyboard-navigable; the live slider value, "Auto" badge, and ambient readout exposed to narrator.

13. Risks & open questions Copy Chapter

• Manual-vs-adaptive arbitration — resolved: default offset (iOS-style), with pause opt-in (direction agreed in #49038).
• ALS placement — chassis lux ≠ panel-facing lux; mitigated by the per-monitor curve; documented as a limitation.
• Clamshell — laptop ALS is blind when the lid is closed; handled via hold/pause + optional time fallback; external sensor is future work.
• DDC/CI variance across docks/USB-C/adapters (cf. #47577) — robust capability probing + clear unsupported messaging.
• Shared ALS source — refactor Light Switch's reader into a shared helper (preferred) vs. two subscriptions.
• Open (tune during implementation): exact default curve values and the Responsiveness → (α, min-update-interval) mapping.

14. Phased delivery Copy Chapter

1. Engine + per-monitor adaptive (curve + offset) + default curve + DDC/CI write reuse + sensor-trust gating (JSON-config; minimal UI).
2. Settings UX: source dropdown, live slider + "Auto" badge/readout, curve editor, responsiveness, clamps, manualBehavior.
3. Shared ALS helper refactor (Light Switch + Power Display); precedence with schedule/profile; optional time-based fallback.
4. Telemetry + docs (doc/devdocs/modules/powerdisplay/…) + tests.

Doc Specs Settings Search (`doc/specs/settings-search.md`) Copy Section

PowerToys Settings – Search Index (Hard-sealed)

1. What to index Copy Chapter

This section describes the current structure of the settings pages in PowerToys. All user-facing settings are contained in the content of controls:SettingsPageControl. The logical and visual structure of settings follows a nested layout as shown below:

SettingsPageControl
 └─ SettingsGroup
     └─ [SettingsExpander]
         └─ SettingsCard

• Each SettingsGroup defines a functional section within a settings page.

• An optional SettingsExpander may be used to further organize related settings inside a group.

• Each actual setting is represented by a SettingsCard, which contains one user-tweakable control or a group of closely related controls.

Note: Not all SettingsCard are necessarily wrapped in a SettingsExpander; they can exist directly under a SettingsGroup.

For indexing purposes, we are specifically targeting all SettingsCard elements. These are the smallest units of user interaction and correspond to individual configurable settings.

There could be setting item in expander, so we also need to index expander items as well.

Module Copy Section

Module is a primary type that needs to be indexed, for modules, we need to index the 'ModuleTitle' and the 'ModuleDescription'.
So these two should be passed in by x:Uid and binding with a key.

SettingsCard/SettingsExpander Copy Section

Each SettingsCard/SettingsExpander should have an x:Uid for localization and indexing. The associated display strings are defined in the .resw files:

{x:Uid}.Header – The visible label/title of the setting.
{x:Uid}.Description – (optional) The tooltip or explanatory text.

The index should be built around these SettingsCard elements and their x:Uid-bound resources, as they represent the actual settings users will search for.

2. How to Navigate Copy Chapter

Entry Copy Section

enum EntryType
{
    SettingsPage,
    SettingsCard,
    SettingsExpander,
}

public class SearchableElementMetadata
{
    public string PageName { get; set; }    // Used to navigate to a specific page
    public EntryType Type { get; set; }     // Used to know how should we navigate(As a page, a settingscard or an expander?)
    public string ParentElementName { get; set; }
    public string ElementName { get; set; }
    public string ElementUid { get; set; }
    public string Icon { get; set; }
}

Navigation Copy Section

The steps for navigate to an item:

• Navigate among pages
• [optional] Expand the expander if setting entry is inside an expander
• [optional] Navigate within page

Use page name for navigation:

Type GetPageTypeFromPageName(string PageName)
{
    var assembly = typeof(GeneralPage).Assembly;
    return assembly.GetType($"Microsoft.PowerToys.Settings.UI.Views.{PageName}");
}

NavigationService.Navigate(PageType, ElementName，ParentElementName);

Use ElementName and ParentElementName for in page navigation:

Page.OnNavigateTo(ElementName， ParentElementName){
    var element = this.FindName(name) as FrameworkElement;
    var parentElement = this.FindName(ParentElementName) as FrameworkElement;

    if(parentElement) {
        expander = (Expander)parentElement;
        if(expander){
            expander.Expand();
        }

        // https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.startbringintoview?view=winrt-26100        
        element.StartBringIntoView();
    }
}

3. Runtime Search Copy Chapter

When user start typing for an entry, e.g. shortcut or 快捷键(cn version of shortcut),
we need to go through all the entries to see if an entry matches the search text.

A naive approach will be try to match all the localized text one by one and see if they match.
Total entry is within thousand(To fill in an exact number), performance is acceptable now.

// Match
query = UserInput();
matched = {};

indexes = BuildIndex();

foreach(var entry in indexes) {
    if(entry.Match(query)) {
        matched.Add(entry);
    }
}

And we don't intend to introduce complexity on the match algorithm discussion, so let's use powertoys FuzzMatch impl for now.

MatchResult Match(this Entry entry, string query) {
    return FuzzMatch(entry.DisplayedText, query);
}

struct MatchResult{
    int Score;
    bool Result;
}

4. Search Result Page Copy Chapter

After we got matched items, map these items to a search result page according to spec.

ObservableCollection<SettingEntry> ModuleResult;
ObservableCollection<SettingsGroup> GroupedSettingsResults;

public class SettingsGroup : INotifyPropertyChanged
{
    private string _groupName;
    private ObservableCollection<SettingEntry> _settings;
    public string GroupName
    {
        get => _groupName;
        set
        {
            _groupName = value;
            OnPropertyChanged();
        }
    }
    public ObservableCollection<SettingEntry> Settings
    {
        get => _settings;
        set
        {
            _settings = value;
            OnPropertyChanged();
        }
    }
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

5. How to do Index Copy Chapter

Runtime index or build time index? Copy Section

Now We need to build all the entries in our settings.

Most of the entry properties are static, and in runtime, the SettingsCard is compiled into native winUI3 controls (I suppose, please correct here if it's wrong), it's hard to locate all the SettingsCard, and performance is terrible if we do search for all the pages' elements.

Build time indexing Copy Section

We can rely on xaml file parsing to get all the SettingsCard Entries.
And we don't want xaml file to be brought into production bundle.
Use a project for parsing and bring that index file into production bundle is a solution.

<Target Name="GenerateSearchIndex" BeforeTargets="BeforeBuild">
    <PropertyGroup>
      <BuilderExe>$(MSBuildProjectDirectory)\..\Settings.UI.XamlIndexBuilder\bin\$(Configuration)\net8.0\XamlIndexBuilder.exe</BuilderExe>
      <XamlDir>$(MSBuildProjectDirectory)\Views</XamlDir>
      <GeneratedJson>$(MSBuildProjectDirectory)\Services\searchable_elements.json</GeneratedJson>
    </PropertyGroup>
    <Exec Command="&quot;$(BuilderExe)&quot; &quot;$(XamlDir)&quot; &quot;$(GeneratedJson)&quot;" />
  </Target>

for(xamlFile in xamlFiles){
    var doc = Load(xamlFile);
    var elements = doc.Descendants();

    foreach(var element in elements){
        if(element.Name == "SettingsCard") {
            var entry = new Entry{
                ElementName = element.Attribute["Name"],
                PageName = FileName,
                Type = "SettingsCard",
                ElementUid = element.Attribute["Uid"],
                DisplayedText = "",
            }

            var parent = element.GetParent();
            if(parent.Name == "SettingsExpander"){
                entry.ParentElementName = parent.Attribute["Name"];
            }
        }
    }
}

Runtime index loading:

var entries = LoadEntriesFromFile();
foreach(var entry in entries){
    entry.DisplayedText = ResourceLoader.GetString(entry.Uid);
}

So now we have all the entries and entry properties.

Overall flow: Copy Chapter

6. Corner cases - that have not addressed yet Copy Chapter

1. CmdPal page is not in scope of this effort, that needs additional effort&design to launch and search within cmdpal settings page.

2. Go back button

3. Dynamic constructed settings page

• Shortcut guide, with visibility converter
• advanced paste dynamically configured setting items
• powertoys run's extensions

Doc Devdocs Common FilePreviewCommon (`doc/devdocs/common/FilePreviewCommon.md`) Copy Section

[FilePreviewCommon](/src/common/FilePreviewCommon)

This project contains common code used for previewing and displaying files.

Monaco preview Copy Chapter

Monaco preview enables to display developer files. It is based on Microsoft's Monaco Editor which is maintained by the Visual Studio Code team.

This previewer is used for the File Explorer Dev File Previewer, as well as PowerToys Peek.

For a general overview of how Monaco is used in PowerToys, see the Monaco Editor documentation.

Update Monaco Editor Copy Section

1. Download Monaco editor with npm: Run npm i monaco-editor in the command prompt.
2. Delete everything except the min folder (the minimised code) from the downloaded files.
3. Copy the min folder into the /src/Monaco/monacoSRC folder of the PowerToys project.
4. Generate the JSON file as described in the generate monaco_languages.json file section.

Add a new language definition Copy Section

As an example on how to add a new language definition you can look at the one for registry files.

1. Add the new language definition (written with Monarch) as a new file to the folder containing Monaco custom languages (Remember the file name and the string you used for "idDefinition" as you need it later.). The file should be formatted like in the example below. (Please change idDefinition to the name of your language.)

export function idDefinition() {
    return {
        ...
    }
}

2. Add the following line to the monacoSpecialLanguages.js file, after the other import statements:

import { idDefinition } from './customLanguages/file.js';

Replace file.js with the name of your definition file from step 1. Please replace idDefinition with the string you used in step 1.

3. In the monacoSpecialLanguages.js file add the following line into the registerAdditionalLanguages function:

registerAdditionalNewLanguage("id", [".fileExtension"], idDefinition(), monaco)

Replace id and idDefinition with your id and string used in step 1. Replace fileExtension with a set of file extensions you want the language to register to.

• The id can be anything. Recommended is one of the file extensions. For example "php" or "reg".

4. In case you wish to add a custom color for a token, you can do so by adding the following line to customTokenThemeRules.js:

{token: 'token-name', foreground: 'ff0000'}

Replace token-name with the name of the token and ff0000 with the hex code of the desired color.
Note: you can also specify a background and a fontStyle attribute for your token.

• Keep in mind that these rules apply to all languages. Therefore, you should not change the colors of any default tokens. Instead, create new tokens specific to the language you are adding.

5. Execute the steps described in the monaco_languages.json section.

Add a new file extension to an existing language Copy Section

1. In the monacoSpecialLanguages.js file add the following line to the registerAdditionalLanguages function. (existingId is the id of the language you want to add the extension to. You can find these id's in the monaco_languages.json file):

registerAdditionalLanguage("id", [".fileExtension"], "existingId", monaco)

• If for instance you want to add more extensions to the php language set the id to phpExt and the existingId to php.

2. Copy the existing language definition into the languageDefinitions function in the same file. You can find the existing definitions in the following folder: /src/Monaco/monacoSRC/min/vs/basic-languages/.

3. Execute the steps described in the monaco_languages.json section.

monaco_languages.json Copy Section

monaco_languages.json contains all extensions and IDs for the languages supported by Monaco. The MonacoHelper class and the installer are using this file to register preview handlers for the defined extensions.

After updating Monaco Editor and/or adding a new language you should update the monaco_languages.json file.

1. Run the generateLanguagesJson.html file on a local webserver (as webbrowsers will block certain needed features when running the file locally.)

• This can for example be achieved by using the Preview Server extension for Visual Studio Code: Open the file in Visual Studio Code, right click in the code editor and select vscode-preview-server: Launch on browser. The file will be opened in a browser.

2. The browser will download the new monaco_languages.json file
3. Replace the old file with the newly downloaded one in the source code folder.

Doc Devdocs Common Common (`doc/devdocs/common/common.md`) Copy Section

Classes and structures

This document is outdated and will soon be renewed.

class Animation: [header](/src/common/animation.h) [source](/src/common/animation.cpp)

Animation helper class with two easing-in animations: linear and exponential.

class AsyncMessageQueue: [header](/src/common/async_message_queue.h)

Header-only asynchronous message queue. Used by TwoWayPipeMessageIPC.

class TwoWayPipeMessageIPC: [header](/src/common/two_way_pipe_message_ipc.h)

Header-only asynchronous IPC messaging class. Used by the runner to communicate with the settings window.

class DPIAware: [header](/src/common/dpi_aware.h) [source](/src/common/dpi_aware.cpp)

Helper class for creating DPI-aware applications.

struct MonitorInfo: [header](/src/common/monitors.h) [source](/src/common/monitors.cpp)

Class for obtaining information about physical displays connected to the machine.

class Settings, class PowerToyValues, class CustomActionObject: [header](/src/common/settings_objects.h) [source](/src/common/settings_objects.cpp)

Classes used to define settings screens for the PowerToys modules.

class Tasklist: [header](/src/common/tasklist_positions.h) [source](/src/common/tasklist_positions.cpp)

Class that can detect the position of the windows buttons on the taskbar. It also detects which window will react to pressing WinKey + number.

struct WindowsColors: [header](/src/common/windows_colors.h) [source](/src/common/windows_colors.cpp)

Class for detecting the current Windows color scheme.

Helpers

Common helpers: [header](/src/common/common.h) [source](/src/common/common.cpp)

Various helper functions.

Settings helpers: [header](/src/common/settings_helpers.h)

Helper methods for the settings.

Start visible helper: [header](/src/common/start_visible.h) [source](/src/common/start_visible.cpp)

Contains function to test if the Start menu is visible.

Toast Notifications

Notifications API [header](/src/common/notifications.h) [source](/src/common/notifications.cpp)

To use UWP-style toast notifications, simply include the header and call one of these functions:

void show_toast(std::wstring_view message);       // #1
    
    void show_toast_background_activated(             // #2
      std::wstring_view message,
      std::wstring_view background_handler_id,
      std::vector<std::wstring_view> button_labels);

We might add more functions in the future if the need arises, e.g. show_toast_xml which will accept raw XML for rich customization.

• #1 is for sending simple notifications without any callbacks or buttons
• #2 is capable of showing a toast with multiple buttons and background activation
• message is a plain-text argument

Implement a toast activation handler/callback as a function in handler_functions.cpp and register its background_handler_id via handlers_map, e.g.:

// Your .cpp where you'd like to show a toast

#include <common/notifications.h>

void some_func() {
// ...
  notifications::show_toast_background_activated(
    L"Toast message!",                                                  // text displayed in a toast
    L"awesome_toast",                                                   // activation handler id
    {L"Press me!", L"Also could press me!", L"I'm here to be pressed!"} // buttons in a toast
  );

// handler_functions.cpp
void awesome_toast_handler(IBackgroundTaskInstance, const size_t button_id)
{
  switch(button_id)
  {
    case 0:
      // handle "Press me!" button click
    case 1:
      // handle "Also could press me!" button click
    case 2:
      // handle "I'm here to be pressed!" button click
  }
}

namespace
{
  const std::unordered_map<std::wstring_view, handler_function_t> handlers_map = {
    // ...other handlers...
    {L"awesome_toast", awesome_toast_handler}
  };}

Note: since background activation implies that your toast handler will be invoked in a separate process, you can't share data directly from within a handler and your PT process. Also, since PT is currently a Desktop Bridge app, foreground activation is handled the same as background, therefore we don't make a dedicated API for it. You can read more on the rationale of the current design.

Doc Devdocs Common Context Menus (`doc/devdocs/common/context-menus.md`) Copy Section

PowerToys Context Menu Handlers

This document describes how context menu handlers are implemented in PowerToys, covering both Windows 10 and Windows 11 approaches.

Context Menu Implementation Types Copy Chapter

PowerToys implements two types of context menu handlers:

1. Old-Style Context Menu Handlers

   • Used for Windows 10 compatibility
   • Registered via registry entries
   • Implemented as COM objects exposing the IContextMenu interface
   • Registered for specific file extensions

2. Windows 11 Context Menu Handlers

   • Implemented as sparse MSIX packages
   • Exposing the IExplorerCommand interface
   • Located in PowerToys\x64\Debug\modules\<module>\<module>.msix
   • Registered for all file types and filtered in code
   • Requires signing to be installed

Context Menu Handler Registration Approaches Copy Chapter

PowerToys modules use two different approaches for registering context menu handlers:

1. Dual Registration (e.g., ImageResizer, PowerRename) Copy Section

• Both old-style and Windows 11 context menu handlers are registered
• Results in duplicate entries in Windows 11's expanded context menu
• Ensures functionality even if Windows 11 handler fails to appear
• Old-style handlers appear in the "Show more options" expanded menu

2. Selective Registration (e.g., NewPlus) Copy Section

• Windows 10: Uses old-style context menu handler
• Windows 11: Uses new MSIX-based context menu handler
• Avoids duplicates but can cause issues if Windows 11 handler fails to register

Windows 11 Context Menu Handler Implementation Copy Chapter

Package Registration Copy Section

• MSIX packages are defined in AppManifest.xml in each context menu project
• Registration happens in DllMain of the module interface DLL when the module is enabled
• Explorer restart may be required after registration for changes to take effect
• Registration can be verified with Get-AppxPackage PowerShell command:
  powershell Copy

  Get-AppxPackage -Name *PowerToys*

Technical Implementation Copy Section

• Handlers implement the IExplorerCommand interface
• Key methods:
  • GetState: Determines visibility based on file type
  • Invoke: Handles the action when the menu item is clicked
  • GetTitle: Provides the text to display in the context menu
• For selective filtering (showing only for certain file types), the logic is implemented in the GetState method

Example Implementation Flow Copy Section

1. Build generates an MSIX package from the context menu project
2. When the module is enabled, PowerToys installs the package using PackageManager.AddPackageAsync
3. The package references the DLL that implements the actual context menu handler
4. When the user right-clicks, Explorer loads the DLL and calls into its methods

Debugging Context Menu Handlers Copy Chapter

Debugging Old-Style (Windows 10) Handlers Copy Section

1. Update the registry to point to your debug build
2. Restart Explorer
3. Attach the debugger to explorer.exe
4. Set breakpoints and test by right-clicking in File Explorer

Debugging Windows 11 Handlers Copy Section

1. Build PowerToys to get the MSIX packages
2. Sign the MSIX package with a self-signed certificate
3. Replace files in the PowerToys installation directory
4. Use PowerToys to install the package
5. Restart Explorer
6. Run Visual Studio as administrator
7. Set breakpoints in relevant code
8. Attach to DllHost.exe process when context menu is triggered

Debugging Challenges Copy Section

• Windows 11 handlers require signing and reinstalling for each code change
• DllHost loads the DLL only when context menu is triggered and unloads after
• For efficient development, use logging or message boxes instead of breakpoints
• Consider debugging the Windows 10 handler by removing OS version checks

Common Issues Copy Chapter

• Context menu entries not showing in Windows 11
  • Usually due to package not being removed/updated properly on PowerToys update
  • Fix: Uninstall and reinstall the package or restart Explorer
• Registering packages requires signing
  • For local testing, create and install a signing certificate
• Duplicate entries in Windows 11 context menu
  • By design for some modules to ensure availability if Windows 11 handler fails

Doc Devdocs Common Monaco Editor (`doc/devdocs/common/monaco-editor.md`) Copy Section

Monaco Editor in PowerToys

Overview Copy Chapter

Monaco is the text editor that powers Visual Studio Code. In PowerToys, Monaco is integrated as a component to provide advanced text editing capabilities with features like syntax highlighting, line numbering, and intelligent code editing.

Where Monaco is Used in PowerToys Copy Chapter

Monaco is primarily used in:

• Registry Preview module - For editing registry files
• File Preview handlers - For syntax highlighting when previewing code files
• Peek module - For preview a file

Technical Implementation Copy Chapter

Monaco is embedded into PowerToys' WinUI 3 applications using WebView2. This integration allows PowerToys to leverage Monaco's web-based capabilities within desktop applications.

Directory Structure Copy Section

The Monaco editor files are located in the relevant module directories. For example, in Registry Preview, Monaco files are bundled with the application resources.

Versioning and Updates Copy Chapter

Current Version Copy Section

The current Monaco version can be found in the loader.js file, specifically in the variable named versionMonaco.

Update Process Copy Section

Updating Monaco requires several steps:

1. Download the latest version of Monaco
2. Replace/override the main folder with the new version
3. Generate the new Monaco language JSON file
4. Override the existing JSON file

For detailed step-by-step instructions, see the FilePreviewCommon documentation.

Estimated Time for Update

The Monaco update process typically takes approximately 30 minutes.

Reference PRs

When updating Monaco, you can refer to previous Monaco update PRs as examples, as they mostly involve copy-pasting the Monaco source code with minor adjustments.

Customizing Monaco Copy Chapter

Adding New Language Definitions Copy Section

Monaco can be customized to support new language definitions for syntax highlighting:

1. Identify the language you want to add
2. Create or modify the appropriate language definition files
3. Update the Monaco configuration to recognize the new language

For detailed instructions on adding language definitions, see the FilePreviewCommon documentation.

Adding File Extensions to Existing Languages Copy Section

To make Monaco handle additional file extensions using existing language definitions:

1. Locate the language mapping configuration
2. Add the new file extension to the appropriate language entry
3. Update the file extension registry

For detailed instructions on adding file extensions, see the FilePreviewCommon documentation.

Example: If Monaco processes TXT files and you want it to preview LOG files the same way, you can add LOG extensions to the TXT language definition.

Installer Handling Copy Chapter

Monaco source files are managed via a script (Generate-Monaco-wxs.ps1) that:

1. Automatically generates the installer manifest to include all Monaco files
2. Avoids manually listing all Monaco files in the installer configuration

This approach simplifies maintenance and updates of the Monaco editor within PowerToys.

Doc Devdocs Core Architecture (`doc/devdocs/core/architecture.md`) Copy Section

PowerToys Architecture

Module Interface Overview Copy Chapter

Each PowerToys utility is defined by a module interface (DLL) that provides a standardized way for the PowerToys Runner to interact with it. The module interface defines:

• Structure for hotkeys
• Name and key for the utility
• Configuration management
• Enable/disable functionality
• Telemetry settings
• Group Policy Object (GPO) configuration

Types of Modules Copy Section

1. Simple Modules (like Mouse Pointer Crosshairs, Find My Mouse)

   • Entirely contained in the module interface
   • No external application
   • Example: Mouse Pointer Crosshairs implements the module interface directly

2. External Application Launchers (like Color Picker)

   • Start a separate application (e.g., WPF application in C#)
   • Handle events when hotkeys are pressed
   • Communication via named pipes or other IPC mechanisms

3. Context Handler Modules (like Power Rename)

   • Shell extensions for File Explorer
   • Add right-click context menu entries
   • Windows 11 context menu integration through MSIX

4. Registry-based Modules (like Power Preview)

   • Register preview handlers and thumbnail providers
   • Modify registry keys during enable/disable operations

Common Dependencies and Libraries Copy Chapter

• SPD logs for C++ (centralized logging system)
• CPP Win RT (used by most utilities)
• Common utilities in common folder for reuse across modules
• Interop library for C++/C# communication (converted to C++ Win RT)
• Common.UI library has WPF and WinForms dependencies

Resource Management Copy Chapter

• For C++ applications and module interfaces:

  • Resource files (.resx) need to be converted to .rc
  • Use conversion tools before building

• Different resource approaches:

  • WPF applications use .resx files
  • WinUI 3 apps use .resw files

• PRI file naming requirements:

  • Need to override default names to avoid conflicts during flattening

Implementation details Copy Chapter

[`Runner`](runner.md) Copy Section

The PowerToys Runner contains the project for the PowerToys.exe executable.
It's responsible for:

• Loading the individual PowerToys modules.
• Passing registered events to the PowerToys.
• Showing a system tray icon to manage the PowerToys.
• Bridging between the PowerToys modules and the Settings editor.

[`Interface`](../modules/interface.md) Copy Section

The definition of the interface used by the runner to manage the PowerToys. All PowerToys must implement this interface.

[`Common`](../common.md) Copy Section

The common lib, as the name suggests, contains code shared by multiple PowerToys components and modules, e.g. json parsing and IPC primitives.

[`Settings`](settings/readme.md) Copy Section

Settings v2 is our current settings implementation. Please head over to the dev docs that describe the current settings system.

Doc Devdocs Core Installer (`doc/devdocs/core/installer.md`) Copy Section

PowerToys Installer

Installer Architecture (WiX 5) Copy Chapter

• Uses a bootstrapper to check dependencies and close PowerToys
• MSI defined in product.wxs
• Custom actions in C++ for special operations:
  • Getting install folder
  • User impersonation
  • PowerShell module path retrieval
  • GPO checking
  • Process termination

Installer Components Copy Section

• Separate builds for machine-wide and user-scope installation
• Supports x64 and ARM64
• Custom actions DLL must be signed separately before installer build
• WXS files generated during build process for file components
• Localization handling for resource DLLs
• Firewall exceptions for certain modules

MSI Installer Build Process Copy Section

• First builds PowerToysSetupCustomActionsVNext DLL and signs it
• Then builds the installer without cleaning, to reuse the signed DLL
• Uses PowerShell scripts to modify .wxs files before build
• Restores original .wxs files after build completes
• Scripts (applyBuildInfo.ps1 and generateFileList.ps1) dynamically update files list for installer
  • Helps manage all self-contained dependencies (.NET, WinAppSDK DLLs, etc.)
  • Avoids manual maintenance of file lists

Special Build Processes Copy Section

• .NET applications need publishing for correct WebView2 DLL inclusion
• WXS files backed up and regenerated during build
• Monaco UI components (JavaScript/HTML) generated during build
• Localization files downloaded from server during CI release builds

Per-User vs Per-Machine Installation Copy Chapter

• Functionality is identical
• Differences:
  • Per-User:
    • Installed to %LOCALAPPDATA%\PowerToys
    • Registry entries in HKCU
    • Different users can have different installations/settings
  • Per-Machine:
    • Installed to Program Files\PowerToys
    • Registry entries in HKLM
    • Single installation shared by all users
• Default is now Per-User installation
• Guards prevent installing both types simultaneously

MSIX Usage in PowerToys Copy Chapter

• Context menu handlers for Windows 11 use sparse MSIX packages
• Previous attempts to create full MSIX installers were abandoned
• Command Palette will use MSIX when merged into PowerToys
• The main PowerToys application still uses MSI for installation

MSIX Packaging and Extensions Copy Section

• MSIX packages for extensions (like context menus) are included in the PowerToys installer
• The MSIX files are built as part of the PowerToys build process
• MSIX files are saved directly into the root folder with base application files
• The installer includes MSIX files but doesn't install them automatically
• Packages are registered when a module is enabled
• Code in package.h checks if a package is registered and verifies the version
• Packages will be installed if a version mismatch is detected
• When uninstalling PowerToys, the system checks for installed packages with matching display names and attempts to uninstall them

GPO Files (Group Policy Objects) Copy Chapter

• GPO files for x64 and ARM64 are identical
• Only one set is needed
• GPO files in pipeline are copies of files in source

Installer Debugging Copy Chapter

• Can only build installer in Release mode
• Typically debug using logs and message boxes
• Logs located in:
  • %LOCALAPPDATA%\Temp\PowerToys_bootstrapper_*.log - MSI tool logs
  • %LOCALAPPDATA%\Temp\PowerToys_*.log - Custom installer logs
• Logs in Bug Reports are useful for troubleshooting installation issues

Building PowerToys Locally Copy Section

One stop script for building installer

1. Open Developer PowerShell for VS.
2. Run tools\build\build-installer.ps1

For the first-time setup, please run the installer as an administrator. This ensures that the Wix tool can move wix.target to the desired location and trust the certificate used to sign the MSIX packages.

The following manual steps will not install the MSIX apps (such as Command Palette) on your local installer.

Prerequisites for building the MSI installer

PowerToys uses WiX v5 for creating installers. The WiX v5 tools are automatically installed during the build process via dotnet tool.

For manual installation of WiX v5 tools:

dotnet tool install --global wix --version 5.0.2

Note: As of release 0.94, PowerToys has migrated from WiX v3 to WiX v5. The WiX v3 toolset is no longer required.

Building prerequisite projects

From the command line

1. From the start menu, open a Developer Command Prompt for VS
2. Ensure nuget.exe is in your %path%
3. In the repo root, run these commands:

nuget restore .\tools\BugReportTool\BugReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\BugReportTool\BugReportTool.sln

nuget restore .\tools\StylesReportTool\StylesReportTool.sln
msbuild -p:Platform=x64 -p:Configuration=Release .\tools\StylesReportTool\StylesReportTool.sln

From Visual Studio

If you prefer, you can alternatively build prerequisite projects for the installer using the Visual Studio UI.

1. Open tools\BugReportTool\BugReportTool.sln
2. In Visual Studio, in the Solutions Configuration drop-down menu select Release
3. From the Build menu, choose Build Solution.
4. Open tools\StylesReportTool\StylesReportTool.sln
5. In Visual Studio, in the Solutions Configuration drop-down menu select Release
6. From the Build menu, choose Build Solution.

Locally compiling the installer

1. Open installer\PowerToysSetup.slnx
2. In Visual Studio, in the Solutions Configuration drop-down menu select Release
3. From the Build menu choose Build Solution.

The resulting installer will be available in the installer\PowerToysSetupVNext\x64\Release\ folder.

To build the installer from the command line, run Developer Command Prompt for VS in admin mode and execute the following commands. The generated installer package will be located at \installer\PowerToysSetupVNext\{platform}\Release\MachineSetup.

git clean -xfd  -e *exe -- .\installer\
MSBuild -t:restore  .\installer\PowerToysSetup.slnx -p:RestorePackagesConfig=true /p:Platform="x64" /p:Configuration=Release
MSBuild -t:Restore -m .\installer\PowerToysSetup.slnx /t:PowerToysInstallerVNext /p:Configuration=Release /p:Platform="x64"
MSBuild -t:Restore -m .\installer\PowerToysSetup.slnx /t:PowerToysBootstrapperVNext /p:Configuration=Release /p:Platform="x64"

Supported arguments for the .EXE Bootstrapper installer Copy Section

Head over to the wiki to see the full list of supported installer arguments.

Doc Devdocs Core Runner (`doc/devdocs/core/runner.md`) Copy Section

PowerToys Runner

The PowerToys Runner is the main executable (PowerToys.exe) that loads and manages all PowerToys modules.

Runner Architecture Copy Chapter

The Runner is responsible for:

• Managing the tray icon
• Loading and managing module interfaces
• Handling enabling/disabling modules
• Processing global hotkeys
• Managing updates and settings

Key Components Copy Section

• Main CPP file manages the tray icon and modules
• Creates a list of modules with DLL paths
• Special handling for WinUI 3 apps (separated in different folder)
• DLLs flattening for consistent versions
• Runs as part of the Windows message loop
• Creates a window handle with a specific class name
• Registers itself as the window handler for components requiring a window handler

Process Flow Copy Section

1. Initialize logger
2. Create single instance application mutex
3. Initialize common utility code
4. Parse command line arguments
5. Start the tray icon
6. Initialize low-level keyboard hooks
7. Load module interfaces from DLLs
8. Start enabled modules
9. Enter Windows message loop
10. On exit, stop modules and clean up resources

System Tray Icon Implementation Copy Chapter

The system tray icon is one of the first components that starts when calling the render_main function:

• Defined in tray_icon.h and tray_icon.cpp
• Creates a popup window and registers as window handler via start_tray_icon()
• Processes window messages through tray_icon_window_proc()
• Uses WM_COMMAND and tray icon notifications for handling menu options
• Handles left mouse clicks (distinguishes between single and double clicks)
• Monitors taskbar creation to re-register the icon if needed
• Uses shell_notify_icon to register with the system tray

Tray Icon Initialization and Message Processing Copy Section

• start_tray_icon() initializes the tray icon by:

  • Creating a window with the specified class name
  • Setting up the notification icon data structure (NOTIFYICONDATA)
  • Registering for taskbar recreate messages
  • Adding the icon to the system tray

• tray_icon_window_proc() processes window messages, including:

  • Handling wm_icon_notify messages from tray icon interactions
  • Distinguishing between left-click, double-click, and right-click actions
  • Showing context menus or opening Settings windows based on interaction type

Communication with Settings UI Copy Section

When the tray icon is clicked or a menu option is selected, the Runner communicates with the Settings UI:

• For quick access flyout (left-click):

  cpp Copy

  current_settings_ipc->send(L"{\"ShowYourself\":\"flyout\"}");

• For the main dashboard (menu option or double-click):

  cpp Copy

  current_settings_ipc->send(L"{\"ShowYourself\":\"Dashboard\"}");

IPC Communication Mechanism Copy Section

• The Runner and Settings UI communicate through Windows Named Pipes
• A two-way pipe (TwoWayPipeMessageIPC) is established between processes
• JSON messages are sent through this pipe to control UI behavior
• The Settings UI initializes the pipe connection on startup:
  csharp Copy

  ipcmanager = new TwoWayPipeMessageIPCManaged(cmdArgs[(int)Arguments.SettingsPipeName], 
                                              cmdArgs[(int)Arguments.PTPipeName], 
                                              (string message) => {
      if (IPCMessageReceivedCallback != null && message.Length > 0) {
          IPCMessageReceivedCallback(message);
      }
  });

Settings UI Message Processing Copy Section

The Settings UI processes incoming IPC messages through a callback chain:

1. Messages from the Runner are received through the IPC callback
2. Messages are parsed as JSON objects
3. Registered handlers in ShellPage.ShellHandler.IPCResponseHandleList process the messages
4. The ReceiveMessage method in ShellPage interprets commands:
   • For flyout display: "ShowYourself": "flyout"
   • For main window: "ShowYourself": "Dashboard" or other page names

When showing the flyout, the tray icon can also send position coordinates to place the flyout near the tray icon:

{
  "ShowYourself": "flyout",
  "x_position": 1234,
  "y_position": 567
}

The flyout window is then activated and brought to the foreground using native Windows APIs to ensure visibility.

Tray Icon Menu Copy Section

• Menus are defined in .RC files (Resource files)
• base.h defines IDs
• resources.resx contains localized strings
• The tray icon window proc handles showing the popup menu

Centralized Keyboard Hook Copy Chapter

• Located in "centralized_kb_hook.cpp"
• Handles hotkeys for multiple modules to prevent performance issues
• Contains optimizations to exit early when possible:
  • Ignores keystrokes generated by PowerToys itself
  • Ignores when no keys are actually pressed
  • Uses metadata to avoid re-processing modified inputs
• Performance consideration: handler must run very fast as it's called on every keystroke

Module Loading Process Copy Chapter

1. Scan module directory for DLLs
2. Create the module interface object for each module
3. Load settings for each module
4. Initialize each module
5. Check GPO policies to determine which modules can start
6. Start enabled modules that aren't disabled by policy

Finding and Messaging the Tray Icon Copy Chapter

The tray icon class is used when sending messages to the runner. For example, to close the runner:

// Find the window with the PowerToys tray icon class and send it a close message
WM_CLOSE

Key Files and Their Purposes Copy Chapter

[`main.cpp`](/src/runner/main.cpp)

Contains the executable starting point, initialization code and the list of known PowerToys. All singletons are also initialized here at the start. Loads all the powertoys by scanning the ./modules folder and enable()s those marked as enabled in %LOCALAPPDATA%\Microsoft\PowerToys\settings.json config. Then it runs a message loop for the tray UI. Note that this message loop also handles lowlevel_keyboard_hook events.

[`powertoy_module.h`](/src/runner/powertoy_module.h) and [`powertoy_module.cpp`](/src/runner/powertoy_module.cpp)

Contains code for initializing and managing the PowerToy modules. PowertoyModule is a RAII-style holder for the PowertoyModuleIface pointer, which we got by invoking module DLL's powertoy_create function.

[`tray_icon.cpp`](/src/runner/tray_icon.cpp)

Contains code for managing the PowerToys tray icon and its menu commands. Note that dispatch_run_on_main_ui_thread is used to
transfer received json message from the Settings window to the main thread, since we're communicating with it from a dedicated thread.

[`settings_window.cpp`](/src/runner/settings_window.cpp)

Contains code for starting the PowerToys settings window and communicating with it. Settings window is a separate process, so we're using Windows pipes as a transport for json messages.

[`general_settings.cpp`](/src/runner/general_settings.cpp)

Contains code for loading, saving and applying the general settings.

[`auto_start_helper.cpp`](/src/runner/auto_start_helper.cpp)

Contains helper code for registering and unregistering PowerToys to run when the user logs in.

[`unhandled_exception_handler.cpp`](/src/runner/unhandled_exception_handler.cpp)

Contains helper code to get stack traces in builds. Can be used by adding a call to init_global_error_handlers in WinMain.

[`trace.cpp`](/src/runner/trace.cpp)

Contains code for telemetry.

[`svgs`](/src/runner/svgs/)

Contains the SVG assets used by the PowerToys modules.

[`bug_report.cpp`](/src/runner/bug_report.cpp)

Contains logic to start bug report tool.

[`centralized_hotkeys.cpp`](/src/runner/centralized_hotkeys.cpp)

Contains hot key logic registration and un-registration.

[`centralized_kb_hook.cpp`](/src/runner/centralized_kb_hook.cpp)

Contains logic to handle PowerToys' keyboard shortcut functionality.

[`restart_elevated.cpp`](/src/runner/restart_elevated.cpp)

Contains logic for restarting the current process with different elevation levels.

[`RestartManagement.cpp`](/src/runner/RestartManagement.cpp)

Contains code for restarting a process.

[`settings_telemetry.cpp`](/src/runner/settings_telemetry.cpp)

Contains logic that periodically triggers module-specific setting's telemetry delivery and manages timing and error handling for the process.

[`UpdateUtils.cpp`](/src/runner/UpdateUtils.cpp)

Contains code to handle the automatic update checking, notification, and installation process for PowerToys.

Doc Devdocs Development Debugging (`doc/devdocs/development/debugging.md`) Copy Section

Debugging PowerToys

This document covers techniques and tools for debugging PowerToys.

Pre-Debugging Setup Copy Chapter

Before you can start debugging PowerToys, you need to set up your development environment:

1. Fork the repository and clone it to your machine
2. Navigate to the repository root directory
3. Run git submodule update --init --recursive to initialize all submodules
4. Change directory to .config and run winget configure .\configuration.vsEnterprise.winget (pick the configuration file that matches your Visual Studio distribution)

Optional: Building Outside Visual Studio Copy Section

You can build the entire solution from the command line, which is sometimes faster than building within Visual Studio:

1. Open Developer Command Prompt for VS
2. Navigate to the repository root directory
3. Run the following command(don't forget to set the correct platform):
   pwsh Copy

   msbuild -restore -p:RestorePackagesConfig=true -p:Platform=ARM64 -m PowerToys.slnx /tl /p:NuGetInteractive="true"

4. This process should complete in approximately 13-14 minutes for a full build

Debugging Techniques Copy Chapter

Visual Studio Debugging Copy Section

To debug the PowerToys application in Visual Studio, set the runner project as your start-up project, then start the debugger.

Some PowerToys modules must be run with the highest permission level if the current user is a member of the Administrators group. The highest permission level is required to be able to perform some actions when an elevated application (e.g. Task Manager) is in the foreground or is the target of an action. Without elevated privileges some PowerToys modules will still work but with some limitations:

• The FancyZones module will not be able to move an elevated window to a zone.
• The Shortcut Guide module will not appear if the foreground window belongs to an elevated application.

Therefore, it is recommended to run Visual Studio with elevated privileges when debugging these scenarios. If you want to avoid running Visual Studio with elevated privileges and don't mind the limitations described above, you can do the following: open the runner project properties and navigate to the Linker -> Manifest File settings, edit the UAC Execution Level property and change it from highestAvailable (level='highestAvailable') to `asInvoker (/level='asInvoker').

Shell Process Debugging Tool Copy Section

The Shell Process Debugging Tool is a Visual Studio extension that helps debug multiple processes, which is especially useful for PowerToys modules started by the runner.

Debugging Setup Process

1. Install "Debug Child Processes" Visual Studio extension
2. Configure which processes to debug and what debugger to use for each
3. Start PowerToys from Visual Studio
4. The extension will automatically attach to specified child processes when launched

Debugging Color Picker Example

1. Set breakpoints in both ColorPicker and its module interface
2. Use Shell Process Debugging to attach to ColorPickerUI.exe
3. Debug .NET and native code together
4. Runner needs to be running to properly test activation

Debugging DLL Main/Module Interface

• Breakpoints in DLL code will be hit when loaded by runner
• No special setup needed as DLL is loaded into runner process

Debugging Short-Lived Processes

• For processes with short lifetimes (like in Workspaces)
• List all processes explicitly in debugging configuration
• Set correct debugger type (.NET debugger for C# code)

Finding Registered Events Copy Section

1. Run WinObj tool from SysInternals as administrator
2. Search for event name
3. Shows handles to the event (typically runner and module)

Common Debugging Usage Patterns Copy Section

Debugging with Bug Report

1. Check module-specific logs for exceptions/crashes
2. Copy user's settings to your AppData to reproduce their configuration
3. Check Event Viewer XML files if logs don't show crashes
4. Compare installation_folder_structure.txt to detect corrupted installations
5. Check installer logs for installation-related issues
6. Look at Windows version and language settings for patterns across users

Installer Debugging

• Can only build installer in Release mode
• Typically debug using logs and message boxes
• Logs located in:
  • %LOCALAPPDATA%\Temp\PowerToys_bootstrapper_*.log - MSI tool logs
  • %LOCALAPPDATA%\Temp\PowerToys_*.log - Custom installer logs
• Logs in Bug Reports are useful for troubleshooting installation issues

Settings UI Debugging

• Use shell process debugging to connect to newly created processes
• Debug the PowerToys.Settings.exe process
• Add breakpoints as needed for troubleshooting
• Logs are stored in the local app directory: %LOCALAPPDATA%\Microsoft\PowerToys
• Check Event Viewer for application crashes related to PowerToys.Settings.exe
• Crash dumps can be obtained from Event Viewer

Debugging Command Palette Copy Section

Command Palette can be easily debugged using the solution filter in src/modules/cmdpal/Command Palette.slnf. This will open Command Palette as its own Visual Studio solution that can be run and debugged directly in Visual Studio without the need for the Shell Process Debugging Tool.

Troubleshooting Build Errors Copy Chapter

Missing Image Files or Corrupted Build State Copy Section

If you encounter build errors about missing image files (e.g., .png, .ico, or other assets), this typically indicates a corrupted build state. To resolve:

1. Clean the solution in Visual Studio: Build > Clean Solution

   Or from the command line (Developer Command Prompt for VS):

   pwsh Copy

   msbuild PowerToys.slnx /t:Clean /p:Platform=x64 /p:Configuration=Debug

2. Delete build output and package folders from the repository root:

   • x64/
   • ARM64/
   • Debug/
   • Release/
   • packages/

3. Rebuild the solution

Helper Script

A PowerShell script is available to automate this cleanup:

.\tools\build\clean-artifacts.ps1

This script will run MSBuild Clean and remove the build folders listed above. Use -SkipMSBuildClean if you only want to delete the folders without running MSBuild Clean.

After cleaning, rebuild with:

msbuild -restore -p:RestorePackagesConfig=true -p:Platform=x64 -m PowerToys.slnx

Doc Devdocs Development Dev With Vscode (`doc/devdocs/development/dev-with-vscode.md`) Copy Section

Developing PowerToys with Visual Studio Code Copy Chapter

This guide shows how to build, debug, and contribute to PowerToys using VS Code instead of (or alongside) full Visual Studio. It focuses on common inner‑loop tasks for C++, .NET, and mixed scenarios present in the solution.

PowerToys is a large mixed C++ / C# / WinAppSDK solution. VS Code works well for incremental development and quick module iterations, but occasionally you may still prefer full Visual Studio for designer tooling or specialized diagnostics.

VS Code extensions Needed:

Building in VS Code Copy Chapter

Configure Developer PowerShell for VS for more convenient development experience in VS Code Copy Section

1. Configure profile in settings, entry: terminal.integrated.profiles.windows
2. Add below config as entry (choose VS 2026 or VS 2022 based on your installation):

For Visual Studio 2026 (recommended):

"Developer PowerShell for VS": {
		// Configure based on your preference
        "path": "C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.5.2.0_arm64__8wekyb3d8bbwe\\pwsh.exe",
        "args": [
            "-NoExit",
            "-Command",
            "& {",
            "$orig = Get-Location;",
            // Adjust path based on your edition (Community/Professional/Enterprise)
            "& 'C:\\Program Files\\Microsoft Visual Studio\\18\\Enterprise\\Common7\\Tools\\Launch-VsDevShell.ps1';",
            "Set-Location $orig",
            "}"
        ]
    },

For Visual Studio 2022:

"Developer PowerShell for VS 2022": {
		// Configure based on your preference
        "path": "C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.5.2.0_arm64__8wekyb3d8bbwe\\pwsh.exe",
        "args": [
            "-NoExit",
            "-Command",
            "& {",
            "$orig = Get-Location;",
            // Adjust path based on your edition (Community/Professional/Enterprise)
            "& 'C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\Common7\\Tools\\Launch-VsDevShell.ps1';",
            "Set-Location $orig",
            "}"
        ]
    },

3. [Optional] Set your Developer PowerShell profile as the default, so that you can get a deep integration with vscode coding agent.

4. Now you can build with plain msbuild or configure tasks.json in below section.
   Or reach out to "tools\build\BUILD-GUIDELINES.md"

Sample plain msbuild command Copy Section

# Restore:
msbuild powertoys.slnx -t:restore -p:configuration=debug -p:platform=x64 -m

# Build powertoys slnx
msbuild powertoys.slnx -p:configuration=debug -p:platform=x64 -m

# dotnet project
msbuild src\settings-ui\Settings.UI\PowerToys.Settings.csproj -p:Platform=x64 -p:Configuration=Debug -m

# native project
msbuild "src\modules\MouseUtils\FindMyMouse\FindMyMouse.vcxproj" -p:Configuration=Debug -p:Platform=x64 -m

Debugging Copy Chapter

Existing launch configuration Copy Section

The repo provides .vscode/launch.json with:

• Run PowerToys.exe (no build): Launches the already-built executable at x64/Debug/PowerToys.exe using cppvsdbg.

Build first, then press F5. To switch configuration (Release / ARM64) either edit the path or create additional launch entries.

Attaching to a running instance Copy Section

If PowerToys is already running, you can attach to that process:

2. VS Code command palette: “C/C++: (Windows) Attach to Process”.
3. Filter for PowerToys.exe / module-specific processes.

Debugging managed components Copy Section

Many modules have a managed component loaded into the PowerToys process. cppvsdbg can debug mixed mode, but if you need richer .NET inspection you can create a second configuration using type: coreclr and processId attachment after the native launch, or just attach separately:

Similar for attach to managed code.

Note: In arm64 machine, can only debug arm64 code.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Run native executable (no build)",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "${workspaceFolder}\\x64\\Debug\\PowerToys.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "console": "integratedTerminal"
        },
        {
            "name": "C/C++ Attach to PowerToys Process (native)",
            "type": "cppvsdbg",
            "request": "attach",
            "processId": "${command:pickProcess}",
            "symbolSearchPath": "${workspaceFolder}\\x64\\Debug;${workspaceFolder}\\Debug;${workspaceFolder}\\symbols"
        },
        {
            "name": "Run managed code (managed, no build)",
            "type": "coreclr",
            "request": "launch",
            "program": "${workspaceFolder}\\arm64\\Debug\\WinUI3Apps\\PowerToys.Settings.exe",
            "args": [],
            "cwd": "${workspaceFolder}",
            "env": {},
            "console": "internalConsole",
            "stopAtEntry": false
        }
    ]
}

6. Common tasks & tips Copy Chapter

Doc Devdocs Development Guidelines (`doc/devdocs/development/guidelines.md`) Copy Section

PowerToys Development Guidelines

Using Open Source Packages and Libraries Copy Chapter

License Considerations Copy Section

• MIT license is generally acceptable for inclusion in the project
• For any license other than MIT, double check with the PM team
• All external packages or projects must be mentioned in the notice.md file
• Even if a license permits free use, it's better to verify with the team

Safety and Quality Considerations Copy Section

• Ensure the code being included is safe to use
• Avoid repositories or packages that are not widely used
• Check for packages with significant downloads/usage and good ratings
• Important because our pipeline signs external DLLs with Microsoft certificate
• Unsafe code signed with Microsoft certificate can cause serious issues

Code Signing Copy Chapter

Signing JSON File Copy Section

• Modifications to the signing JSON file are typically done manually
• When adding new DLLs (internal PowerToys modules or external libraries)
• When the release pipeline fails with a list of unsigned DLLs/executables:
  • For PowerToys DLLs, manually add them to the list
  • For external DLLs, verify they're safe to sign before including

File Signing Requirements Copy Section

• All DLLs and executables must be signed
• New files need to be added to the signing configuration
• CI checks if all files are signed
• Even Microsoft-sourced dependencies are signed if they aren't already

Performance Measurement Copy Chapter

• Currently no built-in timers to measure PowerToys startup time
• Startup measurement could be added in the runner:
  • At the start of the main method
  • After all module interface DLLs are loaded
• Alternative: use profilers or Visual Studio profiler
• Startup currently takes some time due to:
  • Approximately 20 module interface DLLs that need to be loaded
  • Modules that are started during loading
• No dashboards or dedicated tools for performance measurement
• Uses System.Diagnostics.Stopwatch in code
• Performance data is logged to default PowerToys logs
• Can search logs for stopwatch-related messages to diagnose performance issues
• Some telemetry events contain performance information

Dependency Management Copy Chapter

WinRT SDK and CS/WinRT Copy Section

• Updates to WinRT SDK and CS/WinRT are done periodically
• WinRT SDK often requires higher versions of CS/WinRT or vice versa
• Check for new versions in NuGet.org or Visual Studio's NuGet Package Explorer
• Prefer stable versions over preview versions
• Best practice: Update early in the release cycle to catch potential regressions

WebView2 Copy Section

• Used for components like monotone file preview
• WebView2 version is related to the WebView runtime in Windows
• Previous issues with Windows Update installing new WebView runtime versions
• WebView team now includes PowerToys testing in their release cycle
• When updating WebView2:
  • Update the version
  • Open a PR
  • Perform sanity checks on components that use WebView2

General Dependency Update Process Copy Section

• When updating via Visual Studio, it will automatically update dependencies
• After updates, perform:
  • Clean build
  • Sanity check that all modules still work
  • Open PR with changes

C/C++ Runtime (Hybrid CRT) Copy Section

• Cpp.Build.props links the VC++ runtime and STL statically (/MT) and the Universal CRT from the in-box ucrtbase.dll, so no VC++ redistributable is needed.
• Every module in a process shares that UCRT, including WinUI 3 and .NET. Don't change process-wide CRT state:
  • No setlocale, std::locale::global or named std::locale objects; MSVC's STL calls setlocale while building them. Use _wcreate_locale with the _l functions, or NLS APIs such as LCMapStringEx.
  • No signal or _set_invalid_parameter_handler from a DLL.
  • Read environment variables with GetEnvironmentVariableW; the CRT's copy is a snapshot.
• If a project sets Link IgnoreSpecificDefaultLibraries or AdditionalOptions, keep the inherited %(...) value.
• A project that can't follow these rules sets <EnableHybridCRT>false</EnableHybridCRT> with a comment that says why. Today: PowerRename.exe and its tests (PowerRenameLib calls std::locale::global) and MeasureToolCore (installs a SIGABRT handler).
• Debug builds need ucrtbased.dll, which the Windows SDK installs. Use a Release build on machines without the SDK.

Testing Requirements Copy Chapter

Multiple Computers Copy Section

• Mouse Without Borders: Requires multiple physical computers for proper testing
  • Testing with VMs is not recommended as it may cause confusion between host and guest mouse input
  • At least 2 computers are needed, sometimes testing with 3 is done
  • Testing is usually assigned to team members known to have multiple computers

Multiple Monitors Copy Section

• Some utilities require multiple monitors for testing
• At least 2 monitors are recommended
• One monitor should be able to use different DPI settings

Fuzzing Testing Copy Section

• Security team requires fuzzing testing for modules that handle file I/O or user input
• Helps identify vulnerabilities and bugs by feeding random, invalid, or unexpected data
• PowerToys integrates with Microsoft's OneFuzz service for automated testing
• Both .NET (C#) and C++ modules have different fuzzing implementation approaches
• New modules handling file I/O or user input should implement fuzzing tests
• For detailed setup instructions, see Fuzzing Testing in PowerToys

Testing Process Copy Section

• For reporting bugs during the release candidate testing:
  1. Discuss in team chat
  2. Determine if it's a regression (check if bug exists in previous version)
  3. Check if an issue is already open
  4. Open a new issue if needed
  5. Decide on criticality for the release (if regression)

Release Testing Copy Section

• Team follows a release checklist
• Includes testing for WinGet configuration
• Sign-off process:
  • Teams sign off on modules independently
  • Regressions found in first release candidates lead to PRs
  • Second release candidate verified fixes
  • Command Palette needs separate sign-off
  • Final verification ensures modules don't crash with Command Palette integration

PR Management and Release Process Copy Chapter

PR Review Process Copy Section

• PM team typically tags PRs with "need review"
• Small fixes from community that don't change much are usually accepted
• PM team adds tags like "need review" to highlight PRs
• PMs set priorities (sometimes using "info.90" tags)
• PMs decide which PRs to prioritize
• Team members can help get PRs merged when there's flexibility

PR Approval Requirements Copy Section

• PRs need approval from code owners before merging
• New team members can approve PRs but final approval comes from code owners

PR Priority Handling Copy Section

• Old PRs sometimes "slip through the cracks" if not high priority
• PMs tag important PRs with "priority one" to indicate they should be included in release
• Draft PRs are generally not prioritized

Specific PR Types Copy Section

• CI-related PRs need review and code owner approval
• Feature additions (like GPO support) need PM decision on whether the feature is wanted
• Bug fixes related to Watson errors sometimes don't have corresponding issue links
• Command Palette is considered high priority for the upcoming release

Project Management Notes Copy Chapter

• Be careful about not merging incomplete features into main
• Feature branches should be used for work in progress
• PRs touching installer files should be carefully reviewed
• Incomplete features should not be merged into main
• Use feature branches (feature/name-of-feature) for work-in-progress features
• Only merge to main when complete or behind experimentation flags

Doc Devdocs Development Localization (`doc/devdocs/development/localization.md`) Copy Section

Localization

Table of Contents Copy Chapter

1. Localization on the pipeline (CDPX)
   1. UWP Special case
2. Enabling localization on a new project
   1. C++
   2. C#
   3. UWP
3. Lcl Files
4. Possible Issues in localization PRs (LEGO)
5. Enabling localized MSI for a new project

Localization on the pipeline (CDPX) Copy Chapter

The localization step is run on the pipeline before the solution is built. This step runs the build-localization script, which generates resx files for all the projects with localization enabled using the Localization.XLoc package.

The Localization.XLoc tool is run on the repo root, and it checks for all occurrences of LocProject.json. Each localized project has a LocProject.json file in the project root, which contains the location of the English resx file, list of languages for localization, and the output path where the localized resx files are to be copied to. In addition to this, some other parameters can be set, such as whether the language ID should be added as a folder in the file path or in the file name. When the CDPX pipeline is run, the localization team is notified of changes in the English resx files. For each project with localization enabled, a loc folder (see the loc folder in the Microsoft.Launcher module for example) is created in the same directory as the LocProject.json file. The folder contains language specific folders which in turn have a nested folder path equivalent to OutputPath in the LocProject.json. Each of these folders contain one lcl file. The lcl files contain the English resources along with their translation for that language. These are described in more detail in the Lcl files section. Once the .resx files are generated, they will be used during the Build PowerToys step for localized versions of the modules.

Since the localization script requires certain nuget packages, the restore-localization script is run before running build-localization to install all the required packages. This script must run in the restore step of pipeline because the host is network isolated at the build step. The Toolset package source is used for this.

The process and variables that can be tweaked on the pipeline are described in more detail on onebranch (account required) under Localization.

The localized resource dlls for C# projects are added to the MSI only for build on the pipeline. This is done by checking if the IsPipeline variable is defined, which gets defined before building the installer on the pipeline. This is done because the localized resx files are only present on the pipeline, and not having this check would result in the installer project failing to build locally.

Enabling localization on a new project Copy Chapter

To enable localization on a new project, the first step is to create a file LocProject.json in the project root.

For example, for a project in the folder src\path where the resx file is present in resources\Resources.resx, the LocProject.json file will contain the following:

{
    "Projects": [
        {
            "LanguageSet": "Azure_Languages",
            "LocItems": [
                {
                    "SourceFile": "src\\path\\resources\\Resources.resx",
                    "CopyOption": "LangIDOnName",
                    "OutputPath": "src\\path\\resources"
                }
            ]
        }
    ]
}

The rest of the steps depend on the project type and are covered in the sections below. The steps to add the localized files to the MSI can be found in Enabling localized MSI for a new project.

C++ Copy Section

C++ projects do not support resx files, and instead use rc files along with resource.h files. The CDPX pipeline however doesn't support localizing rc files and the other alternative they support is directly translating the resources from the binary which makes it harder to maintain resources. To avoid this, a custom script has been added which expects a resx file and converts the entries to an rc file with a string table and adds resource declarations to a resource.h file so that the resources can be compiled with the C++ project.

If you already have a .rc file, copy the string table to a separate txt file and run the convert-stringtable-to-resx.ps1 script on it. This script is not very robust to input, and requires the data in a specific format, where IDS_ResName L"ResourceValue" and any number of spaces can be present in between. The script converts this file to the format expected by resgen, which will convert it to resx. The resource names are changed from all uppercase to title case, and the IDS_ prefix is removed. Escape characters might have to be manually replaced, for example .rc files would have escaped double quotes as "", so this should be replaced with just " before converting to the resx files.

After generating the resx file, rename the existing rc and h files to ProjName.base.rc and resource.base.h. In the rc file remove the string table which is to be localized and in the .h file remove all #defines corresponding to localized resources. In the vcxproj of the C++ project, add the following build event:

<Target Name="GenerateResourceFiles" BeforeTargets="PrepareForBuild">
    <Exec LogStandardErrorAsError="false" Command="powershell -NonInteractive -executionpolicy Unrestricted -NoProfile $(SolutionDir)tools\build\convert-resx-to-rc.ps1 $(MSBuildThisFileDirectory) resource.base.h resource.h ProjName.base.rc ProjName.rc" />
</Target>

This event runs a script which generates a resource.h and ProjName.rc in the Generated Files folder using the strings in all the resx files along with the existing information in resource.base.h and ProjName.base.rc. The script is convert-resx-to-rc.ps1. The script uses resgen to convert the resx file to a string table expected in the .rc file format. When the resources are added to the rc file the IDS_ prefix is added and resource names are in uppercase (as it was originally). Any occurrences of " in the string resource is escaped as "" to prevent build errors. The string tables are added to the rc file in the following format:

#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US

STRINGTABLE
BEGIN
    strings
END

#endif

Since there is no API to identify the AFX_TARG_*, LANG_* or SUBLANG_* values from each langId from the pipeline, these are hardcoded in the script (for each language) as done in lines 50-77 of convert-resx-to-rc.ps1. If any other languages are added in the future, this script will have to be updated. In order to determine what are the language codes, you can open the rc file in Resource View, right click the string table and press Insert Copy and choose the corresponding language. This autogenerates the required code and can be used to figure out the language codes. The files also add the resource declarations to a resource.h file, starting from 101 by default(this can be changed by an optional argument). Since the output files will be generated in Generated Files, any includes in these two files will require an additional ..\ and wherever resource.h is used, it will have to be included as Generated Files\resource.h. While adding resource.base.h and ProjName.base.rc to the vcxproj, these should be modified to not participate in the build to avoid build errors:

<None Include="Resources.resx" />

Some rc/resource.h files might be used in multiple projects (for example, KBM). To ensure the projects build for these cases, the build event can be added to the entire directory so that the rc files are generated before any project is built. See Directory.Build.targets for an example.

Check this PR for an example for making these changes for a C++ project.

C# Copy Section

Since C# projects natively support resx files, the only step required here is to include all the resx files in the build. For .NET Core projects this is done automatically and the .csproj does not need to be modified. For other projects, the following line needs to be added:

<EmbeddedResource Include="Properties\Resources.*.resx" />

Note: Building with localized resources may cause a build warning Referenced assembly 'mscorlib.dll' targets a different processor which is a VS bug. More details can be found in PowerToys issue #7269.

Note: If a project needs to be migrated from XAML resources to resx, the easiest way to convert the resources would be to change to format to = separates resources by either manually (by Ctrl+H on a text editor), or by a script, and then running resgen on Developer Command Prompt for VS to convert it to resx format.

<system:String x:Key="wox_plugin_calculator_plugin_name">Calculator</system:String>
<system:String x:Key="wox_plugin_calculator_plugin_description">Allows to do mathematical calculations.(Try 5*3-2 in Wox)</system:String>
<system:String x:Key="wox_plugin_calculator_not_a_number">Not a number (NaN)</system:String>

to

wox_plugin_calculator_plugin_name=Calculator
wox_plugin_calculator_plugin_description=Allows to do mathematical calculations.(Try 5*3-2 in Wox)
wox_plugin_calculator_not_a_number=Not a number (NaN)

After adding the resx file to the project along with the resource generator, references to the strings will have to be replaced with Properties.Resources.resName rather than the custom APIs. Check this PR for an example of the changes required.

UWP Copy Section

UWP projects expect resw files rather than resx (the format is almost the same). Unlike other C# projects, the files are expected in the format fullLangId\Resources.resw. To include these files in the build, replace the following line in the csproj:

<PRIResource Include="Strings\en-us\Resources.resw" />

to

<PRIResource Include="Strings\*\Resources.resw" />

Lcl Files Copy Chapter

Lcl files contain all the resources that are present in the English resx file, along with a translation if it has been added.

For example, an entry for a resource in the lcl file looks like this:

<Item ItemId=";EditKeyboard_WindowName" ItemType="0;.resx" PsrId="211" Leaf="true">
    <Str Cat="Text">
        <Val><![CDATA[Remap keys]]></Val>
        <Tgt Cat="Text" Stat="Loc" Orig="New">
            <Val><![CDATA[Remapper des touches]]></Val>
        </Tgt>
    </Str>
    <Disp Icon="Str" />
</Item>

The <Tgt> element would not be present in the initial commits of the lcl files, as only the English version of the string would be present.

Note: The CDPX Localization system has a fail-safe check on the lcl files, where if the English string value which is present inside <Val><![CDATA[*]]></Val> does not match the value present in the English Resources.resx file then the translated value will not be copied to the localized resx file. This is present so that obsolete translations would not be loaded when the English resource has changed, and the English string will be used rather than the obsolete translation.

Possible Issues in localization PRs (LEGO) Copy Chapter

Since the LEGO PRs update some of the strings in LCL files at a time, there can be multiple PRs which modify the same files, leading to merge conflicts. In most cases this would show up on GitHub as a merge conflict, but sometimes a bad git merge may occur, and the file could end up with incorrect formatting, such as two <Tgt> elements for a single resource. These can be fixed by ensuring the elements follow the format described in this section. To catch such errors, the build farm should be run for every LEGO PR and if any error occurs in the localization step, we should check the corresponding resx/lcl files for conflicts.

Enabling localized MSI for a new project Copy Chapter

For C++ and UWP projects no additional files are generated with localization that need to be added to the MSI. For C++ projects all the resources are added to the dll/exe, while for UWP projects they are added to the resources.pri file (which is present even for an unlocalized project). To verify if the localized resources are added to the resources.pri file the following steps can be done:

• Open Developer Command Prompt for VS

• After navigating to the folder containing the pri file, run the following command:

  text Copy

  makepri.exe dump /if .\resources.pri

• Check the contents of the resources.pri.xml file that is generated from the command. The last section of the file will contain the resources with the strings in all the languages:

<NamedResource name="GeneralSettings_RunningAsAdminText" uri="ms-resource://f4f787a5-f0ae-47a9-be89-5408b1dd2b47/Resources/GeneralSettings_RunningAsAdminText">
    <Candidate qualifiers="Language-FR" type="String">
        <Value>Running as administrator</Value>
    </Candidate>
    <Candidate qualifiers="Language-EN-US" isDefault="true" type="String">
        <Value>Running as administrator</Value>
    </Candidate>
</NamedResource>

For C# projects, satellite dlls are generated when the project is built. For a project named ProjName, files are created in the format langId\ProjName.resources.dll where langId is in the same format as the lcl files. The satellite dlls need to be included with the MSI, but they must be added only if the solution is built from the build farm, as the localized resx files will not be present on local machines (and that could cause local builds of the installer to fail).
This can be done by adding the directory name of the project to Product.wxs near line 806 and a resource component for the project can be created in Product.wxs near lines 845-847 in this format:

<Component Id="ProjName_$(var.IdSafeLanguage)_Component" Directory="Resource$(var.IdSafeLanguage)ProjNameInstallFolder">
    <File Id="ProjName_$(var.IdSafeLanguage)_File" Source="$(var.BinX64Dir)modules\ProjName\$(var.Language)\ProjName.resources.dll" />
</Component>

We should also ensure the new dlls are signed by the pipeline. Currently all dlls of the form *.resources.dll are signed.

Note: The resource dlls should be added to the MSI project only after the initial commit with the lcl files has been done by the Localization team. Otherwise, the pipeline will fail as there wouldn't be any resx files to generate the dlls.

Working With Strings Copy Chapter

In order to support localization YOU SHOULD NOT have hardcoded UI display strings in your code. Instead, use resource files to consume strings.

For CPP Copy Section

Use StringTable resource to store the strings and resource header file(resource.h) to store Id's linked to the UI display string. Add the strings with Id's referenced from the header file to the resource-definition script file. You can use Visual Studio Resource Editor to create and manage resource files.

• resource.h:

XXX must be a unique int in the list (mostly the int ID of the last string id plus one):

#define IDS_MODULE_DISPLAYNAME                    XXX

• StringTable in resource-definition script file validmodulename.rc:

STRINGTABLE
BEGIN
    IDS_MODULE_DISPLAYNAME               L"Module Name"
END

• Use the GET_RESOURCE_STRING(UINT resource_id) method to consume strings in your code.

#include <common.h>

std::wstring GET_RESOURCE_STRING(IDS_MODULE_DISPLAYNAME)

For C# Copy Section

Use XML resource file(.resx) to store the UI display strings and Resource Manager to consume those strings in the code. You can use Visual Studio to create and manage XML resources files.

• Resources.resx

<data name="ValidUIDisplayString" xml:space="preserve">
    <value>Description to be displayed on UI.</value>
    <comment>This text is displayed when XYZ button clicked.</comment>
  </data>

• Use Resource Manager to consume strings in code.

System.Resources.ResourceManager manager = new System.Resources.ResourceManager(baseName, assembly);
string validUIDisplayString = manager.GetString("ValidUIDisplayString", resourceCulture);

In case of Visual Studio is used to create the resource file. Simply use the Resources class in auto-generated Resources.Designer.cs file to access the strings which encapsulate the Resource Manager logic.

string validUIDisplayString = Resources.ValidUIDisplayString;

Doc Devdocs Development Logging (`doc/devdocs/development/logging.md`) Copy Section

Logging and Telemetry in PowerToys

Logging Types in PowerToys Copy Chapter

PowerToys has several types of logging mechanisms:

1. Text file logs (application writes logs to files)
2. Telemetry/diagnostic data (sent to Microsoft servers)
3. Event Viewer logs (used by some utilities like Mouse Without Borders)
4. Watson reports (crash reports sent to Microsoft)

Log File Locations Copy Chapter

Regular Logs Copy Section

• Located at: %LOCALAPPDATA%\Microsoft\PowerToys\Logs
• Organized by utility and sometimes by version
• Examples: PowerToys Run logs, module interface logs
• C# and C++ components both write logs to these locations

Low-Privilege Logs Copy Section

• Some components (like preview handlers and thumbnail providers) are started by Explorer and have low privileges
• These components write logs to: %USERPROFILE%/AppData/LocalLow/Microsoft/PowerToys
• Example: Monaco preview handler logs

Module Logs Copy Section

• Logs always stored in user's AppData regardless of installation type
• Each module creates its own log
• Even with machine-wide installation, logs are per-user
• Different users can have different logs even with a machine-wide installation

Log Implementation Copy Chapter

C++ Logging Copy Section

In C++ projects we use the awesome spdlog library for logging as a git submodule under the deps directory. To use it in your project, just include spdlog.props in a .vcxproj like this:

<Import Project="..\..\..\deps\spdlog.props" />

It'll add the required include dirs and link the library binary itself.

• Projects need to include the logging project as a dependency
• Uses a git submodule for the actual logging library
• Logs are initialized in the main file:
  cpp Copy

  init_logger();

• After initialization, any file can use the logger
• Logger settings contain constants like log file locations

C# Logging Copy Section

For C# projects there is a static logger class in Managed Common called Logger.

To use it, add a project reference to ManagedCommon and add the following line of code to all the files using the logger:

using ManagedCommon;

In the Main function (or a function with a similar meaning (like App in a App.xaml.cs file)) you have to call InitializeLogger and specify the location where the logs will be saved (always use a path scheme similar to this example):

Logger.InitializeLogger("\\FancyZones\\Editor\\Logs");

For a low-privilege process you have to set the optional second parameter to true:

Logger.InitializeLogger("\\FileExplorer\\Monaco\\Logs", true);

The Logger class contains the following logging functions:

// Logs an error that the utility encountered
Logger.LogError(string message);
Logger.LogError(string message, Exception ex);
// Logs an error that isn't that grave
Logger.LogWarning(string message);
// Logs what the app is doing at the moment
Logger.LogInfo(string message);
// Like LogInfo just with infos important for debugging
Logger.LogDebug(string message);
// Logs the current state of the utility.
Logger.LogTrace();

Log File Management Copy Chapter

• Currently, most logs are not automatically cleaned up
• Some modules have community contributions to clean old logs, but not universally implemented
• By default, all info-level logs are written
• Debug and trace logs may not be written by default
• Log settings can be found in settings.json, but not all APIs honor these settings

Telemetry Copy Chapter

Implementation Copy Section

• Uses Event Tracing for Windows (ETW) for telemetry
• Different from the text file logging system
• Keys required to send telemetry to the right server
  • Keys are not stored in the repository
  • Obfuscated in public code
  • Replaced during the release process
  • Stored in private NuGet packages for release builds

C++ Telemetry Copy Section

• Managed through trace_base.h which:
  • Registers the provider
  • Checks if user has disabled diagnostics
  • Defines events
• Example from Always On Top:
  cpp Copy

  Trace::AlwaysOnTop::Enable(true);

C# Telemetry Copy Section

• Uses PowerToysTelemetry class
• WriteEvent method sends telemetry
• Projects add a reference to the PowerToys.Telemetry project
• Example:
  csharp Copy

  PowerToysTelemetry.Log.WriteEvent(new LauncherShowEvent(hotKey));

User Controls Copy Section

• Settings page allows users to:
  • Turn off/on sending telemetry
  • Enable viewing of telemetry data

Viewing Telemetry Data Copy Section

• When "Enable viewing" is turned on, PowerToys starts ETW tracing
• Saves ETL files for 28 days
• Located at: %LOCALAPPDATA%\Microsoft\PowerToys\ETL (for most utilities)
• Low-privilege components save to a different location
• Button in settings converts ETL to XML for user readability
• XML format chosen to follow approved compliance pattern from Windows Subsystem for Android
• Files older than 28 days are automatically deleted

Bug Report Tool Copy Chapter

The BugReportTool can be triggered via:

• Right-click on PowerToys tray icon → Report Bug
• Left-click on tray icon → Open Settings → Bug Report Tool

It creates a zip file on desktop named "PowerToys_Report_[date]_[time].zip" containing logs and system information.

See Bug Report Tool for more detailed information about the tool.

Doc Devdocs Development New Powertoy (`doc/devdocs/development/new-powertoy.md`) Copy Section

🧭 Creating a new PowerToy: end-to-end developer guide

First of all, thank you for wanting to contribute to PowerToys. The work we do would not be possible without the support of community supporters like you.

This guide documents the process of building a new PowerToys utility from scratch, including architecture decisions, integration steps, and common pitfalls.

1. Overview and prerequisites Copy Chapter

A PowerToy module is a self-contained utility integrated into the PowerToys ecosystem. It can be UI-based, service-based, or both.

Requirements Copy Section

Follow the Getting Started guide to set up your development environment, then validate that you are able to build and run PowerToys.slnx.

Optional:

• WiX v5 toolset for the installer

Folder structure Copy Section

src/
  modules/
    your_module/
      YourModule.sln
      YourModuleInterface/
      YourModuleUI/ (if needed)
      YourModuleService/ (if needed)

2. Design and planning Copy Chapter

Decide the type of module Copy Section

Think about how your module works and which existing modules behave similarly. You are going to want to think about the UI needed for the application, the lifecycle, whether it is a service that is always running or event based. Below are some basic scenarios with some modules to explore. You can write your application in C++ or C#.

• UI-only: e.g., ColorPicker
• Background service: e.g., LightSwitch, Awake
• Hybrid (UI + background logic): e.g., ShortcutGuide
• C++/C# interop: e.g., PowerRename

Write your module interface Copy Section

Begin by setting up the PowerToy module template project. This will generate boilerplate for you to begin your new module. Below are the key headers in the Module Interface (dllmain.cpp) and an explanation of their purpose:

1. This is where module settings are defined. These can be anything from strings, bools, ints, and even custom Enums.

struct ModuleSettings {};

2. This is the header for the full class. It inherits the PowerToyModuleIface

class ModuleInterface : public PowertoyModuleIface 
{
  private:
    // the private members of the class
    // Can include the enabled variable, logic for event handlers, or hotkeys.
  public:
    // the public members of the class
    // Will include the constructor and initialization logic.
}

[!NOTE]
Many of the class functions are boilerplate and need simple string replacements with your module name. The rest of the functions below will require bigger changes.

3. GPO stands for "Group Policy Object" and allows for administrators to configure settings across a network of machines. It is required that your module is on this list of settings. You can right click the powertoys_gpo object to go to the definition and set up the getConfiguredModuleEnabledValue for your module.

virtual powertoys_gpo::gpo_rule_configured_t gpo_policy_enabled_configuration() override
{
    return powertoys_gpo::getConfiguredModuleEnabledValue();
}

4. init_settings() initializes the settings for the interface. Will either pull from existing settings.json or use defaults.

void ModuleInterface::init_settings()

5. get_config retrieves the settings from the settings.json file.

virtual bool get_config(wchar_t* buffer, int* buffer_size) override

6. set_config sets the new settings to the settings.json file.

virtual void set_config(const wchar_t* config) override

7. call_custom_action allows custom actions to be called based on signals from the settings app.

void call_custom_action(const wchar_t* action) override

8. Lifecycle events control whether the module is enabled or not, as well as the default status of the module.

virtual void enable() // starts the module
virtual void disable() // terminates the module and performs any cleanup
virtual bool is_enabled() // returns if the module is currently enabled
virtual bool is_enabled_by_default() const override // allows the module to dictate whether it should be enabled by default in the PowerToys app.

9. Hotkey functions control the status of the hotkey.

// takes the hotkey from settings into a format that the interface can understand
void parse_hotkey(PowerToysSettings::PowerToyValues& settings) 

// returns the hotkeys from settings
virtual size_t get_hotkeys(Hotkey* hotkeys, size_t buffer_size) override 

// performs logic when the hotkey event is fired
virtual bool on_hotkey(size_t hotkeyId) override

Notes Copy Section

• Keep module logic isolated under /modules/<YourModule>
• Use shared utilities from common instead of cross-module dependencies
• init/set/get config use preset functions to access the settings. Check out the settings_objects.h in src\common\SettingsAPI

3. Bootstrapping your module Copy Chapter

1. Use the template to generate the module interface starter code.
2. Update all projects and namespaces with your module name.
3. Update GUIDs in .vcxproj and solution files.
4. Update the functions mentioned in the above section with your custom logic.
5. In order for your module to be detected by the runner you are required to add references to various lists. In order to register your module, add the corresponding module reference to the lists that can be found in the following files. (Hint: search other modules names to find the lists quicker)
   • src/runner/modules.h
   • src/runner/modules.cpp
   • src/runner/resource.h
   • src/runner/settings_window.h
   • src/runner/settings_window.cpp
   • src/runner/main.cpp
   • src/common/logger.h (for logging)
6. ModuleInterface should build your ModuleInterface.dll. This will allow the runner to interact with your service.

[!TIP]
Mismatched module IDs are one of the most common causes of load failures. Keep your ID consistent across manifest, registry, and service.

4. Write your service Copy Chapter

This is going to look different for every PowerToy. It may be easier to develop the application independently, and then link in the PowerToys settings logic later. But you have to write the service first, before connecting it to the runner.

Notes Copy Section

• This is a separate project from the Module Interface.
• You can develop this project using C# or C++.
• Set the service icon using the .rc file.
• Set the service name in the .vcxproj by setting the <TargetName>

<PropertyGroup>
  <OutDir>..\..\..\..\$(Platform)\$(Configuration)\$(MSBuildProjectName)\</OutDir>
  <TargetName>PowerToys.LightSwitchService</TargetName>
</PropertyGroup>

• To view the code of the .vcxproj, right click the item and select Unload project
• Use the following functions to interact with settings from your service

ModuleSettings::instance().InitFileWatcher();
ModuleSettings::instance().LoadSettings();
auto& settings = ModuleSettings::instance().settings();

These come from the ModuleSettings.h file that lives with the Service. You can copy this from another module (e.g., Light Switch) and adjust to fit your needs.

If your module has a user interface:

• Use the WinUI Blank App template when setting up your project
• Use Windows design best practices
• Use the WinUI 3 Gallery for help with your UI code, and additional guidance.

5. Settings integration Copy Chapter

PowerToys settings are stored per-module as JSON under:

%LOCALAPPDATA%\Microsoft\PowerToys\<module>\settings.json

Implementation steps Copy Section

• In src\settings-ui\Settings.UI.Library\ create <module>Properties.cs and <module>Settings.cs
• <module>Properties.cs is where you will define your defaults. Every setting needs to be represented here. This should match what was set in the Module Interface.
• <module>Settings.csis where your settings.json will be built from. The structure should match the following

public ModuleSettings()
{
    Name = ModuleName;
    Version = Assembly.GetExecutingAssembly().GetName().Version.ToString();
    Properties = new ModuleProperties(); // settings properties you set above.
}

• In src\settings-ui\Settings.UI\ViewModels create <module>ViewModel.cs this is where the interaction happens between your settings page in the PowerToys app and the settings file that is stored on the device. Changes here will trigger the settings watcher via a NotifyPropertyChanged event.
• Create a SettingsPage.xaml at src\settings-ui\Settings.UI\SettingsXAML\Views. This will be the page where the user interacts with the settings of your module.
• Be sure to use resource strings for user facing strings so they can be localized. (x:Uid connects to Resources.resw)

// LightSwitch.xaml
<ComboBoxItem
    x:Uid="LightSwitch_ModeOff"
    AutomationProperties.AutomationId="OffCBItem_LightSwitch"
    Tag="Off" />

// Resources.resw
<data name="LightSwitch_ModeOff.Content" xml:space="preserve">
  <value>Off</value>
</data>

[!IMPORTANT]
In the above example we use .Content to target the content of the Combobox. This can change per UI element (e.g., .Text, .Header, etc.)

Reminder: Manual changes via external editors (VS Code, Notepad) do not trigger the settings watcher. Only changes written through PowerToys trigger reloads.

Gotchas: Copy Section

• Only use the WinUI 3 framework, not UWP.
• Use DispatcherQueue when updating UI from non-UI threads.

6. Building and debugging Copy Chapter

Debugging steps Copy Section

1. If this is your first time debugging PowerToys, be sure to follow these steps first.
2. Set "runner" as the start up project and ensure your build configuration is set to match your system (ARM64/x64)
3. Select F5 or the Local Windows Debugger button to begin debugging. This should start the PowerToys runner.
4. To set breakpoints in your service, select Ctrl+Alt+P and search for your service to attach to the runner.
5. Use logs to document changes. The logs live at %LOCALAPPDATA%\Microsoft\PowerToys\RunnerLogs and %LOCALAPPDATA%\Microsoft\PowerToys\Module\Service\<version> for the specific module.

[!TIP]
PowerToys caches .nuget artifacts aggressively. Use git clean -xfd when builds behave unexpectedly.

7. Installer and packaging (WiX) Copy Chapter

Add your module to installer Copy Section

1. Install WixToolset.Heat for Wix5 via nuget
2. Inside installer\PowerToysInstallerVNext add a new file for your module: Module.wxs
3. Inside of this file you will need copy the format from another module (ie: Light Switch) and replace the strings and GUID values.
4. The key part will be `` which is a placeholder for code that will be generated by generateFileComponents.ps1.
5. Inside Product.wxs add a line item in the <Feature Id="CoreFeature" ... > section. It will look like a list of <ComponentGroupRef Id="ModuleComponentGroup" /> items.
6. Inside generateFileComponents.ps1 you will need to add an entry to the bottom for your new module. It will follow the following format. -fileListName <Module>Files will match the string you set in Module.wxs, <ModuleServiceName> will match the name of your exe.

# Module Name
Generate-FileList -fileDepsJson "" -fileListName <Module>Files -wxsFilePath $PSScriptRoot\<Module>.wxs -depsPath "$PSScriptRoot..\..\..\$platform\Release\<ModuleServiceName>"
Generate-FileComponents -fileListName "<Module>Files" -wxsFilePath $PSScriptRoot\<Module>.wxs -regroot $registryroot

8. Testing and validation Copy Chapter

UI tests Copy Section

• Place under /modules/<YourModule>/Tests
• Create a new WinUI Unit Test App
• Write unit tests following the format from previous modules (ie: Light Switch). This can be to test your standalone UI (if you're a module like Color Picker) or to verify that the Settings UI in the PowerToys app is controlling your service.

Manual validation Copy Section

• Enable/disable in PowerToys Settings
• Check initialization in logs
• Confirm icons, tooltips, and OOBE page appear correctly

Pro tips Copy Section

1. Validate wake/sleep and elevation states. Background modules often fail silently after resume if event handles aren’t recreated.
2. Use Windows Sandbox to simulate clean install environments
3. To simulate a "new user" you can delete the PowerToys folder from %LOCALAPPDATA%\Microsoft

Shortcut conflict detection Copy Section

If your module has a shortcut, ensure that it is properly registered following the steps listed in the documentation for conflict detection.

9. The final touches Copy Chapter

Out-of-Box experience (OOBE) page Copy Section

The OOBE page is a custom settings page that gives the user at a glance information about each module. This window opens before the Settings application for new users and after updates. Create OOBE<ModuleName>.xaml at src\settings-ui\Settings.UI\SettingsXAML\OOBE\Views. You will also need to add your module name to the enum at src\settings-ui\Settings.UI\OOBE\Enums\PowerToysModules.cs.

Module assets Copy Section

Now that your PowerToy is done you can start to think about the assets that will represent your module.

• Module Icon: This will be displayed in a number of places: OOBE page, in the README, on the home screen of PowerToys, on your individual module settings page, etc.
• Module Image: This is the image you see at the top of each individual settings page.
• OOBE Image: This is the header you see on the OOBE page for each module

[!NOTE]
This step is something that the Design team will handle internally to ensure consistency throughout the application. If you have ideas or recommendations on what the icon or screenshots should be for your module feel free to leave it in the "Additional Comments" section of the PR and the team will take it into consideration.

Documentation Copy Section

There are two types of documentation that will be required when submitting a new PowerToy:

1. Developer documentation: This will live in the PowerToys repo at /doc/devdocs/modules/ and should tell a developer how to work on your app. It should outline the module architecture, key files, testing, and tips on debugging if necessary.
2. Microsoft Learn documentation: When your new Module is ready to be merged into the PowerToys repository, an internal team member will create Microsoft Learn documentation so that users will understand how to use your module. There is not much work on your end as the developer for this step, but keep an eye on your PR in case we need more information about your PowerToy for this step.

Thank you again for contributing! If you need help, feel free to open an issue and use the Needs-Team-Response label so we know you need attention.

Doc Devdocs Development Style (`doc/devdocs/development/style.md`) Copy Section

Coding Style

Philosophy Copy Chapter

1. If it's inserting something into the existing classes/functions, try to follow the existing style as closely as possible.
2. If it's brand new code or refactoring a complete class or area of the code, please follow as Modern C++ of a style as you can and reference the C++ Core Guidelines as much as you possibly can.

Formatting Copy Chapter

• We use XamlStyler to format XAML files. You can use the Visual Studio Extension or apply formatting executing .\.pipelines\applyXamlStyling.ps1 -Main.
• We use .clang-format style file to enable automatic code formatting. You can easily format source files from Visual Studio. For example, CTRL+K CTRL+D formats the current document.
• If you prefer another text editor or have ClangFormat disabled in Visual Studio, you could invoke format_sources powershell script from command line. It gets a list of all currently modified files from git and invokes clang-format on them.
  Please note that you should also have clang-format.exe in %PATH% for it to work. The script can infer the path of clang-format.exe version which is shipped with Visual Studio at %VCINSTALLDIR%\Tools\Llvm\bin\, if you launch it from the Native Tools Command Prompt for VS.
• CI doesn't enforce code formatting yet, since we're gradually applying code formatting to the codebase, but please adhere to our formatting style for any new code.

Doc Devdocs Development Test Winget Install Locally (`doc/devdocs/development/test-winget-install-locally.md`) Copy Section

If for any reason, you'd like to test winget install scenario, you can follow this doc: Copy Chapter

Powertoys winget manifest definition: Copy Section

winget repository

How to test a winget installation locally: Copy Section

1. Get artifacts from release CI pipeline Pipelines - Runs for PowerToys Signed YAML Release Build, or you can build one yourself by execute the
   'tools\build\build-installer.ps1' script

2. Get the artifact hash, this is required to define winget manifest

cd /path/to/your/directory/contains/installer
Get-FileHash -Path ".\<Installer-name>.exe" -Algorithm SHA256

3. Host your installer.exe - Attention: staged github release artifacts or artifacts in release pipeline is not OK in this step
   You can self-host it or you can upload to a publicly available endpoint
   How to selfhost it (A extremely simple way):

python -m http.server 8000

4. Download a version folder from wingetpkgs like: version 0.92.1
   and you get a folder contains 3 yml files

note: Do not put any files other than these three in this folder

5. Modify the yml files based on your version and the self hosted artifact link, and modify the sha256 hash for the installer you'd like to use

6. Start winget install:

#execute as admin
winget settings --enable LocalManifestFiles
winget install --manifest "<folder_path_of_manifest_files>" --architecture x64 --scope user

Doc Devdocs Development Ui Tests (`doc/devdocs/development/ui-tests.md`) Copy Section

UI tests framework

PowerToys provides UI-test frameworks for modules and Settings. New tests should use
Microsoft.PowerToys.UITest.Next, which drives Windows UI Automation through winappcli and runs as
a Microsoft.Testing.Platform executable. The legacy Microsoft.PowerToys.UITest framework uses
WinAppDriver/Selenium and remains documented for existing suites and migration baselines.

Agent-assisted workflows Copy Chapter

Two repository skills cover the complete implementation and validation loop:

• UI-tests migration skill: create new
  .Next test projects, port legacy WinAppDriver tests, design stable selectors/waits/lifecycle, and
  prepare tests for CI.
• Local-VM UI-tests skill: create persistent
  Windows 10 and Windows 11 Hyper-V guests, stage current build/test artifacts, execute tests in a
  standard-user interactive desktop, and collect durable TRX/log/screenshot/video evidence.

For new or migrated tests, use both skills. Build first, then use the local VMs as the default live
agentic loop: run one deterministic test, diagnose and fix it, and finally widen to the complete
module suite on both supported Windows versions.

Module-specific constraints are documented with the module; for example, see the
PowerRename UI-test notes for command-line selection, Boost
engine lifetime, and signed shell-extension requirements.
Read the Environment Variables safety notes before
running that suite: it temporarily replaces the real User PATH and must run only in a disposable VM,
not on a working machine.

Before running tests Copy Chapter

`.Next` tests Copy Section

• Build the PowerToys runtime and .UITests.Next test executable.
• Install the pinned winappcli runtime or set WINAPP_CLI_PATH. The pipeline helper is
  .pipelines/InstallWinAppCli.ps1.
• Use a live interactive desktop. UIA, foreground input, Explorer, hotkeys, and rendering do not work
  in session 0.
• Exit an existing PowerToys instance before a host-desktop run. The harness owns the runner and
  module lifecycle.

Legacy tests Copy Section

• Install Windows Application Driver v1.2.1 from https://github.com/microsoft/WinAppDriver/releases/tag/v1.2.1 to the default directory (C:\Program Files (x86)\Windows Application Driver)

• Enable Developer Mode in Windows settings

Running tests Copy Chapter