Files
PowerToys/src
Subhrajyoti Singha deaf6dce03 [CmdPal] Add "Update and restart" / "Update and shut down" system com… (#49437)
## Summary of the Pull Request

Adds **Update and restart** and **Update and shut down** to the Windows
System Commands extension, matching what Windows shows in the Start menu
power flyout when updates are waiting for a reboot.

Both only show up while Windows Update is actually waiting on a restart.
When nothing is pending, the command list is exactly what it is today.

## PR Checklist

- [x] Closes: #48849
- [x] **Communication:** commented on the issue before starting;
zadjii-msft had greenlit the idea as long as the commands actually do
something rather than just report status
- [x] **Tests:** added and passing (27/27)
- [ ] **Localization:** 6 new resx strings, each with a translator
comment
- [ ] **Dev docs:** n/a
- [ ] **New binaries:** n/a

## Detailed Description of the Pull Request / Additional comments

**Detecting the pending update.**
`WindowsUpdateHelper.IsUpdatePending()` reads
`ISystemInformation::RebootRequired` from WUAPI, which is the same
signal the Start menu uses, so the commands appear exactly when Windows
would offer them itself.

A few notes on that file, since the interop is a bit unusual:

- I used `[GeneratedComInterface]` rather than `ComImport` to keep it
AOT-compatible.
- `ISystemInformation` is a dual interface, so its first four vtable
slots belong to `IDispatch`. They're declared as placeholder methods
that are never called, and the two real members follow in vtable order.
- The result is cached for 5 seconds. `GetItems()` runs on every
keystroke and would otherwise create a COM object each time — same
reasoning as the existing network info cache in this extension.
- If anything goes wrong (COM creation fails, an exception is thrown) it
falls back to "no update pending", so the commands stay hidden and the
extension behaves exactly as it does now. The failure is logged through
`ExtensionHost.LogMessage`.

**Running the command.** `InitiateShutdown` with
`SHUTDOWN_INSTALL_UPDATES` plus either `SHUTDOWN_RESTART` (0x44) or
`SHUTDOWN_POWEROFF` (0x48). That first flag is what makes this "update
and restart" instead of a plain restart. `SeShutdownPrivilege` is
disabled by default on the process token, so it gets enabled first.

**Wiring.** Both items use the existing `ExecuteCommandConfirmation`
flow, so they respect the "confirm system commands" setting like the
other commands here. They're registered on the System Commands page and
the top-level search fallback, with stable ids
(`...system.update_restart`, `...system.update_shutdown`).

## One question for reviewers

`ShowDialogToConfirmCommand` defaults to `false`, so out of the box
these run immediately when you press Enter, the same as the existing
Shutdown and Restart commands. I kept them consistent rather than
special-casing them, but I hit this myself while testing — I pressed
Enter and my machine started updating and rebooting straight away, which
was a bit of a surprise. Happy to force a confirmation for these two
regardless of the setting if you'd prefer that.

## Validation Steps Performed

27/27 unit tests pass. The 5 new test methods cover the commands being
present/absent in both states, query matching, stable ids, the 0x44 /
0x48 flag values, and that the real WUAPI call doesn't throw.

I also tested it on a machine with a genuine pending update, confirmed
via WUAPI `RebootRequired` and the Windows Update and CBS registry keys:

1. **Before** — the installed 0.11 build, same machine, same pending
update: no update commands.
2. **After** — this build: both commands show up, in the same situation
the Start menu offers them.
3. **Search** — typing `update` matches both, which is the
discoverability gap the issue is about.
4. **Actually ran it** — pressing Enter on "Update and restart"
installed the pending update (KB5121767) and restarted the machine.
After it came back up, `RebootRequired` was false and the two commands
were correctly gone from the list.

### Screenshots

**1. Before**
<img width="785" height="473" alt="Screenshot 2026-07-21 214038"
src="https://github.com/user-attachments/assets/27b12a4c-f636-4815-b8e2-fc918282959b"
/>

**After**
<img width="762" height="445" alt="Screenshot 2026-07-21 215452"
src="https://github.com/user-attachments/assets/80e1936d-af67-48ab-91b4-59b94fb56827"
/>
<img width="762" height="149" alt="pr48849-search-update"
src="https://github.com/user-attachments/assets/53b7f065-4b7c-4317-9e66-e621eed44e61"
/>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 7b3fb20d-6e9d-4fef-a5cd-f8921d28c220
2026-08-18 11:33:28 +08:00
..

PowerToys Source Code

Code organization

The PowerToys are split into DLLs for each PowerToy module (modules folder), and an executable (runner folder) that loads and manages those DLLs.

The settings window is a separate executable, contained in settings-ui folder. It utilizes a WebView to display an HTML-based settings window.

The common contains code for a static library with helper functions, used by both the runner and the PowerToys modules.