Finding Windows apps and windows from a script: alias stubs on PATH, UWP window counts, silent ms-settings URIs

Finding Windows apps and windows from a script

These observations come from one Windows 11 machine. They concern how a script decides what is installed, what is open, and how to reach it. Numbers are single measurements.

A file on PATH is not proof of a command-line program

A zero-byte file on PATH is an AppExecutionAlias stub. It is a placeholder that the shell resolves to a packaged (Store/MSIX) app, not a command-line tool. Two stubs measured on the machine look like CLIs and are not: mspaint.exe and ms-teams.exe. Both resolve through Get-Command and both run, but they open a GUI window and offer no console interface.

The PE header tells a console program from a GUI program. Read the file, find the PE header offset, and look at the Subsystem field at peOffset + 0x5C:

• 3 = Windows console subsystem, a real command-line program.
• 2 = Windows GUI subsystem, not a CLI.

A stub has no PE image of its own (zero bytes), so the length check comes first and the subsystem check applies to non-empty executables.

Name matching also produces false positives. Get-Command *Code* returned Get-AuthenticodeSignature, and a search for an office-suite name returned cloud-API cmdlets that never touch the running application. Matching on the task domain ("firewall", "printer", "service") found the relevant cmdlets; matching on the application name did not.

Get-Process undercounts windows

Get-Process | Select MainWindowHandle found 16 top-level windows on the machine. EnumWindows found 44. The difference is UWP apps: their processes report MainWindowHandle = 0 because the visible window belongs to ApplicationFrameHost, not to the app's own process. A script that looks a UWP app up by process name and finds no window will conclude, wrongly, that it is not open.

The way around it is to resolve the window through ApplicationFrameHost (match by title), or to enumerate with EnumWindows and map each handle to its owner.

Related: a minimised or suspended window can expose almost no UI Automation tree. Snipping Tool gave 1 node while minimised and 41 once restored. A To Do window gave 1 node, then 69 once it was targeted through ApplicationFrameHost and restored.

ms-settings: URIs fail silently on unknown pages

Start-Process ms-settings:<page> with a page name that does not exist does nothing and returns no error. A successful launch looks identical to a typo from the script's side. Verifying the outcome is necessary; one check used was reading the Settings window's breadcrumb element (AutomationId PermanentNavigationViewBreadcrumbBar) after the launch. On the measured machine 123 ms-* URI schemes were registered.

URI schemes launch, they do not control

ms-teams:, ms-todo: and ms-outlook: only open the application. They expose no control surface (no way to read a list, send a message, or tick an item). For these services the usable route was a cloud API (Microsoft Graph), which no local registry scan or port probe can discover. In a comparison across 19 apps, a hand-curated table of routes matched 58% and generic probing matched 11%.

Cmdlets instead of driving Settings and admin consoles

For most system areas a PowerShell cmdlet returns typed objects in milliseconds and removes the need to click anything. Measured on the same machine:

| Area | Cmdlet | Measured | |---|---|---| | Services | Get-Service | 306 services in 233 ms | | Scheduled tasks | Get-ScheduledTask | 203 tasks in 560 ms | | Devices | Get-PnpDevice | 252 devices, 20 with problems | | Firewall | Get-NetFirewallProfile | 54 ms | | Power plan | powercfg /getactivescheme | 18 ms | | Installed apps | Get-AppxPackage plus the Uninstall registry keys | 161 packages; 93 products in 52 ms | | Registry | HKCU: and HKLM: providers | 9 to 10 ms per read |

Printers (Get-Printer), disks (Get-Volume, Get-Disk) and updates (Get-HotFix) follow the same pattern. Launching an app by AUMID also works without a window search: Get-StartApps listed 180 apps with AUMIDs, started with Start-Process explorer.exe 'shell:AppsFolder\<AUMID>'.

Not verified

The PE subsystem rule was observed on two stubs and several real executables on one machine; it was not tested against every packaged-app alias type.