PowerToys general settings lost on every restart unless manually exited from tray

Microsoft PowerToys version and release channel

v0.101.2362 - Stable

Installation method

WinGet

Area(s) with issue?

General, Settings, System tray interaction

Steps to reproduce

1. Have PowerToys running normally with custom General settings (specific modules enabled/disabled, enable_quick_access toggled, etc.) already saved to settings.json.
2. Restart or shut down Windows through any normal path (Start menu, shutdown.exe, etc.) without first manually exiting PowerToys via its tray icon's "Exit" command.
3. After the machine comes back up, inspect %LOCALAPPDATA%\Microsoft\PowerToys\settings.json.

Result: the file is frequently found reduced to an empty {} (or the runner logs apply_general_settings: {} on the next launch), and all General settings — including which modules are enabled — revert to PowerToys' compiled-in defaults.

This was narrowed down through the following controlled tests:

• Ruled out restart speed / OS shutdown timeout: raised HKCU\Control Panel\Desktop\WaitToKillAppTimeout and HungAppTimeout to 20000 (4x default). No effect — corruption still occurred. This indicates the app acknowledges the shutdown request quickly (so Windows never applies the hung-app wait at all) while an asynchronous settings save is still in flight, rather than PowerToys genuinely running out of time.
• Ruled out elevation/auto-elevation: reproduced with "Always run as administrator" disabled and PowerToys running non-elevated.
• Ruled out AV/EDR or external interference: no related entries in Windows Defender / EDR protection history. Task Scheduler's own history shows PowerToys' own startup task being deleted and recreated each boot, seemingly as routine self-managed housekeeping rather than external tampering, and this is independent of the settings corruption.
• Confirmed the corruption happens at shutdown of the previous session, not at the next startup: disabled "Run at startup" entirely, left PowerToys running, restarted, and checked settings.json before ever relaunching PowerToys — it was already empty.
• Confirmed a clean manual Exit (tray icon → Exit) never corrupts the file, across multiple repeated tests.
• Confirmed a "graceful" programmatic close does not reproduce the safety of a manual Exit: a Task Scheduler task triggered on Event ID 1074 (System log, source User32 — logged when a shutdown/restart is initiated, before the OS notifies applications) running taskkill /IM PowerToys.exe (no /F, i.e. a WM_CLOSE request rather than a forced kill) still corrupted settings.json on the very first test.

This suggests the tray menu's "Exit" command invokes a distinct, apparently-synchronous save-then-quit routine, while any other close signal (WM_CLOSE from taskkill, or the OS's own session-ending notification, visible in the runner log as Runner WM_DESTROY, system_session_ending=true) hits a different, race-prone save path.

Relevant runner log excerpt (from %LOCALAPPDATA%\Microsoft\PowerToys\Logs), showing a boot where settings were lost:

[...] [info] runner logger is initialized
[...] [info] apply_general_settings: {}
[...] [warning] apply_general_settings: show_theme_adaptive_tray_icon not found in config
[...] [info] Runner is starting. Elevated=true openOobe=false openScoobe=false showRestartNotificationAfterUpdate=false
[...] [info] start_enabled_powertoys: Enabling powertoy AlwaysOnTop
[...] (all modules reset to default enabled/disabled state)

And from the end of the preceding session:

[...] [info] Runner WM_DESTROY, system_session_ending=true

compared to a manually-triggered restart in the same log, which preserved settings correctly:

[...] [info] Runner WM_DESTROY, system_session_ending=false

✔️ Expected Behavior

settings.json (and the enabled/disabled state of all modules) should persist across a normal Windows restart/shutdown exactly as reliably as it does after a manual "Exit" from the tray icon.

❌ Actual Behavior

settings.json is intermittently truncated to an empty {} whenever PowerToys is closed by anything other than the tray icon's "Exit" command — including a normal OS restart/shutdown and a "graceful" external WM_CLOSE (e.g. via taskkill without /F) — causing all General settings to silently revert to defaults on the next launch. This is not fixed by increasing the OS shutdown timeout, is not related to elevation, and is not caused by antivirus/EDR interference.

Upload Bug Report ZIP-file

PowerToysReport_2026-09-17-14-10-16.zip

Additional Information

OS version: Windows 11 Pro 25H2 26200.9457 User or System Installation: happens with both installation types Running as admin: is_admin=true (account is an Administrator); is_elevated varies by launch — reproduced both elevated and non-elevated

AI was used to help write this bug report, but the investigation was done by myself.

Other Software

No response