Start-Process cmdlet and the specific shell: URI protocol. Standard executable paths do not work for these modern applications because they are packaged differently than traditional Win32 programs. This guide explains how to identify the correct package name and execute the launch command efficiently.
Understanding UWP Application Structure
Universal Windows Platform apps, formerly known as Metro or Modern apps, are installed in protected system directories rather thanC:\Program Files. They rely on manifest files and package families that define their capabilities and dependencies. Because of this sandboxed architecture, double-clicking an icon triggers the Windows Shell to resolve the association, but a direct call to the binary often fails or throws access denied errors. Therefore, leveraging the shell's ability to handle URIs is the most reliable method for automation via scripts or batch files.
The primary challenge users face is identifying the unique identifier for each app. Unlike standard programs where you might know the path to chrome.exe or notepad.exe, UWP apps have complex names like Microsoft.WindowsCalculator_8wekyb3d8bbwe!App. Without knowing this exact string, attempts to launch the application will fail. The following steps detail how to retrieve this information and construct the proper command.
Listing Installed UWP Applications
Before launching any application, you need to discover its full package name. PowerShell provides built-in cmdlets specifically designed to query the AppX deployment system. Open PowerShell as an administrator to ensure you have permission to read all user and system packages. Run the following command to list all installed UWP apps along with their family names and display names:Get-AppxPackage | Select Name, PackageFamilyName, InstallLocationWhere-Object or use Select-String to filter by name. For example, to find the Calculator app specifically, you would use:
Get-AppxPackage *calculator* | Select Name, PackageFamilyNamePackageFamilyName column. This value is crucial for the next step. It typically follows the format Vendor.AppName_Key. You will also see a Name column which contains the App User Model ID (AUMI). The AUMI usually ends with an exclamation mark followed by the entry point identifier, often App. Both pieces of information are useful, but the AUMI is generally required for the shell URI method.
If you are managing multiple users or looking for apps installed per-user rather than per-machine, you may need to adjust your scope. The command above lists packages for the current user context. If you need to see all packages across all users, add the -AllUsers flag to Get-AppxPackage. This is particularly helpful when troubleshooting why a script works for one user but not another.
Launching Apps Using Shell URIs
Once you have identified the AUMI, you can launch the application using theshell: protocol handler. This method mimics what happens when you click a tile in the Start Menu. The syntax requires the start-process cmdlet in PowerShell.
Use the following structure to open the app:
Start-Process "shell:appsFolder\YourPackageFamilyName!App" -WindowStyle HiddenYourPackageFamilyName!App with the actual value found in your previous step. For instance, to open the Calculator, the command would look like this:
Start-Process "shell:appsFolder\Microsoft.WindowsCalculator_8wekyb3d8bbwe!App"-WindowStyle Hidden parameter is optional but recommended if you are running this from a background script or batch file. It prevents a PowerShell window from flashing on the screen during execution. If you want the app to appear normally, you can omit this flag or use -WindowStyle Normal.
This approach is robust because it respects the default launch settings of the application. It ensures that any associated handlers or deep links are processed correctly by the operating system. It also avoids issues related to missing environment variables or working directory contexts that often plague direct executable calls.
Integrating with Batch Files
Many users prefer using batch files (.cmd or .bat) for simple automation tasks. Since batch files do not natively support PowerShell cmdlets, you must invoke PowerShell from within the batch script. This creates a seamless workflow for legacy systems or users who are more comfortable with command-line interfaces. Create a new text file and save it with a.bat extension. Inside, add the following line to call PowerShell and execute your launch command:
powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "Start-Process 'shell:appsFolder\Microsoft.WindowsCalculator_8wekyb3d8bbwe!App'"-NoProfile switch speeds up execution by skipping the loading of user profile scripts. The -ExecutionPolicy Bypass flag ensures that the inline command runs without being blocked by security policies, which is common in restricted environments. Quotes around the PowerShell command are essential if the command contains spaces or special characters.
This technique allows you to combine UWP app launching with other traditional command-line tools. You can chain commands, check exit codes, or log timestamps alongside the launch action. For more complex scenarios involving arguments passed to the app, you may need to explore the Args property of the process, though this is less commonly supported for all UWP applications compared to standard executables.
Troubleshooting Common Issues
Sometimes the command returns an error or the app does not open. The most frequent cause is an incorrect AUMI string. Double-check the spelling and ensure the exclamation mark is present. Another issue arises if the app is corrupted or unregistered. In such cases, reinstalling the app via the Microsoft Store or usingRepair-AppxPackage can restore functionality.
Additionally, some enterprise environments restrict the use of shell protocols or PowerShell execution. If you encounter access denied errors, verify your group policy settings and user permissions. Ensure that the account running the script has the right to launch application shortcuts.
For developers creating custom UWP apps, ensuring the Package.appxmanifest correctly defines the entry point is vital. If the manifest is misconfigured, even the correct shell URI will fail to launch the app. Always test the URI in the Run dialog (Win + R) before embedding it in scripts to validate correctness.
Frequently Asked Questions
Can I pass arguments to a UWP app using this method?
No, the shell:appsFolder protocol does not support passing command-line arguments directly. UWP apps handle input differently than Win32 apps, often relying on activation events rather than raw command-line parameters.
Why does Start-Process fail with 'Access Denied'?
This error usually occurs if you are not running PowerShell with administrative privileges or if the target user profile is locked. Ensure you are executing the command under an account that has permission to interact with the graphical subsystem.
How do I find the AUMI for a third-party UWP app?
Use Get-AppxPackage with a wildcard search matching the app's vendor or name. Look for the Name column in the output, which contains the full AUMI ending in !App.
Is there a way to close a UWP app via command line?
You can try using Stop-Process with the process name, but this is unreliable as UWP processes may have dynamic names. A more robust method involves sending a close message via WMI or using taskkill if the main process is identifiable.
Does this method work for Windows 10 and Windows 11?
Yes, the shell:appsFolder protocol is consistent across Windows 10 and Windows 11. The underlying AppX infrastructure remains the same, making these commands compatible with both operating systems.