You type a winget command in Command Prompt or PowerShell and Windows says the term is not recognized, or the command closes without displaying anything. WinGet, the Windows package manager, is not a separate program: it ships with the App Installer component, delivered through the Microsoft Store. The fault almost always comes from that component, its execution alias or the PATH.
Problem
- winget is not recognized in Command Prompt or in PowerShell.
- The command works for one Windows account but not for another.
- winget exits without any message.
- Message "Program 'winget.exe' failed to run: The file cannot be accessed by the system".
Typical messages (in English in the Microsoft documentation; the wording on a non-English Windows may differ):
'winget' is not recognized as an internal or external command,
operable program or batch file.
winget : The term 'winget' is not recognized as the name of a cmdlet, function, script file, or operable program.
Observe before acting
| What you see | Most likely cause | Step |
|---|---|---|
| New PC or freshly created account | WinGet not yet registered for this account | Step 1 |
| Command unknown everywhere, App Installer missing or old | Component missing or too old | Step 2 |
| The full path works, but not the word winget alone | Alias disabled or PATH modified | Step 3 |
| winget exits without a message | Old version using a retired CDN | Step 4 |
| "cannot be accessed by the system" error or visibly damaged package | Corrupted package registration | Step 5 |
Supported systems: WinGet is supported on Windows 10 version 1809 (build 17763) and later, Windows 11 and Windows Server 2025. It is not available in Windows Sandbox, nor in a session running as SYSTEM.
Step 1: register WinGet for your account
When to use it: on a new PC, right after installing Windows or at a new account's first sign-in. Microsoft states that WinGet is only available after the first sign-in: the Microsoft Store registers it asynchronously.
Suggested solution
Wait a few minutes after the first sign-in, then reopen the terminal. If the command is still unknown, force the registration in a normal PowerShell window (no administrator rights needed):
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
Close and reopen PowerShell, then test:
winget --version
Expected result: a version number is displayed.
Rollback: none, the command only registers an already present package for your account.
Step 2: install or update App Installer
When to use it: the command is still unknown after step 1, or the component is missing (reduced Windows edition, Microsoft Store removed, corporate image).
Suggested solution
- Check the installed version in PowerShell:
Get-AppxPackage microsoft.desktopappinstaller
- If nothing is displayed or the Version line is old (the official repository says a version above 1.11.11451 is required), install or update App Installer from its Microsoft Store page, or via the official link aka.ms/getwinget.
- Reopen the terminal and run winget --version again.
Expected result: the command responds after the update.
Rollback: not needed, this is a Windows component maintained by Microsoft.
If the Microsoft Store itself does not open, fix that first: Microsoft Store not opening or downloads stuck (French guide).
Step 3: check the execution alias and the PATH
When to use it: the component is installed (step 2) but the word winget alone is not found.
Suggested solution
- Test the alias's full path in PowerShell:
& "$env:LOCALAPPDATA\Microsoft\WindowsApps\winget" --version
- If this works, the problem lies in how Windows finds the command:
- open the Start menu, search for Manage app execution aliases and check that the winget.exe alias (App Installer) is On;
- check that your account's PATH still contains %LOCALAPPDATA%\Microsoft\WindowsApps (Start, search for Edit environment variables for your account, then the Path variable). This entry is present by default; a program or a manual edit may have removed it.
- If the entry is missing, add it with the New button, confirm, then open a new terminal.
Expected result: winget --version responds in a new window.
Rollback: the alias can be turned off again in the same place; an entry added to the PATH is removed from the same window.
Step 4: winget exits without any message
When to use it: the command is recognized but produces no output.
Suggested solution
The official WinGet repository explains that versions older than 1.6.3482 use a retired CDN. Update App Installer (step 2), then refresh the sources:
winget source update
Expected result: winget search displays results again.
Rollback: none.
Step 5: repair the component
When to use it: after steps 1 to 4, or if the "Program 'winget.exe' failed to run" error appears. Both methods below come from the Microsoft documentation and the official repository; start with the first one.
Suggested solution
Method A, reset the package (Windows 11) in PowerShell:
Get-AppxPackage Microsoft.DesktopAppInstaller | Reset-AppxPackage
Method B, official repair tool in PowerShell opened as administrator:
Install-PackageProvider -Name NuGet -Force | Out-Null
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
Repair-WinGetPackageManager -Force -Latest
If PowerShell refuses to run the module because of the execution policy, see "Running scripts is disabled on this system" in PowerShell instead of blindly turning off a protection.
Expected result: winget --version responds after closing and reopening the terminal.
Rollback: the reset returns the component to its original state; software already installed with WinGet is not uninstalled.
Special cases
| Situation | Explanation |
|---|---|
| Works for one account, not another | The component is registered per user: repeat step 1 in the affected session. |
| Script launched by a scheduled task as SYSTEM | The WinGet command-line client is not supported in that context. |
| Windows Sandbox | WinGet and the Microsoft Store are not included. |
| Corporate PC | A policy may block the Store or WinGet: contact your IT department. |
Final check
- ☐ winget --version displays a version number.
- ☐ winget search returns results.
- ☐ The command works in a new window, in both Command Prompt and PowerShell.
For deeper diagnosis, winget --info shows, among other things, the log location (by default %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir).
Sources
- Microsoft Learn: Use WinGet to install and manage applications
- Microsoft Learn: Troubleshoot WinGet
- Official WinGet repository (common issues): microsoft/winget-cli on GitHub
- Microsoft Store: App Installer
Still having the problem?
Reply to this topic with your Windows version (Windows key + R, winver), the exact message you get, the output of Get-AppxPackage microsoft.desktopappinstaller (the Version line only) and whether the PC is managed by a company or school. Remove your user name from paths before copying them.