PowerShell "Is Not Recognized as the Name of a Cmdlet": What It Really Means
"The term is not recognized as the name of a cmdlet, function, script file, or operable program" means PowerShell searched every place it knows to look — your typed aliases, your loaded functions, your installed cmdlets, then your PATH folders — and found nothing with that exact name. Here's the part almost nobody tells you: this error has nothing to do with permissions or execution policy, and if it's happening to plain built-in commands like cmd, PowerShell usually isn't the thing that's broken.
Jake called on a Tuesday morning sounding more rattled than usual. A customer had brought in a laptop and asked him to "just run the script the manufacturer sent" to reset a forgotten BIOS password tool. Jake opened PowerShell, typed the command from the PDF, and got a wall of red text ending in "is not recognized as the name of a cmdlet, function, script file, or operable program." He tried it three more times, convinced he'd fat-fingered it. Same result. The customer waited. Jake charged him for a diagnostic and sent him home without an answer — a $45 job that turned into an apology.
He didn't find out until later that his typing had been right the whole time. The tutorial PDF had quietly swapped a plain hyphen for a longer dash somewhere during export, and the two characters look identical on screen but mean nothing alike to PowerShell's parser.
What this error actually means, in plain English
Every time you type a word at the start of a line in PowerShell, it isn't just looking things up in one big dictionary. It's working through an ordered list, and it stops at the first match it finds. That order is: aliases first, then functions currently loaded in your session, then cmdlets, and finally native programs — the actual .exe files on your computer, but only if the folder that contains them is listed in your PATH. If none of those four categories contain a match, you get this exact error.
That ordered list matters because it explains something confusing: two people can type the identical command, on the same version of Windows, and one gets an answer while the other gets "not recognized" — because one of them has a module loaded (which adds entries to the "cmdlet" bucket) and the other doesn't. Nothing about their PowerShell installation is different. Their session's contents are different.
A quick vocabulary check, because the error message uses four words on purpose and each one is a different failure:
- Cmdlet — a command built into PowerShell or added by a module, always in the
Verb-Nounshape (Get-Process,Install-Module). - Function — code someone wrote (often in a script or profile) and loaded into the current session.
- Script file — a saved
.ps1file, which behaves like a program but needs different handling to launch. - Operable program — a real, standalone .exe (or .bat, .cmd) on disk, like
make.exe,cmd.exe, or your own compiled tool.
The four versions of this error, and how to tell them apart
🙋♂️ Jake's Reality Check
"It's the exact same red error message every time. Why do you keep asking me what kind of command it was?"
Because PowerShell recycles one sentence for four completely different problems. The wording never changes; the fix always depends on which of the four you're actually hitting, and the only way to tell is by looking at what you typed, not the error itself.
Look at the command you typed, not the error text, and match it against this table:
| What you typed looked like | Category | Go to |
|---|---|---|
Get-ADUser, Install-Module, Connect-PnPOnline — a Verb-Noun word |
Cmdlet | Fix 1 or Fix 2 |
myscript.ps1 or a filename typed on its own |
Script file | Fix 3 |
make, run, a custom tool name, or an installed program's name |
Native program | Fix 4 |
cmd, notepad, or another command that ships with Windows itself |
Broken system PATH | The section below |
Fix 1: The module exists on your PC but isn't loaded (Windows 11)
PowerShell doesn't load every cmdlet that exists on your machine into every session automatically. Some modules load on demand, the first time you use one of their commands, through a feature called module auto-loading. If auto-loading fails — often because the module's own files were only partially installed, or because a previous session imported an old version that's now shadowing the real one — the cmdlet looks completely absent.
- Open PowerShell and run
Get-Command -Name "Verb-Noun*"using the start of the cmdlet's name. If nothing comes back, the module truly isn't present on this machine yet — skip to Fix 2. - If something does come back, check which module it lives in:
Get-Command YourCmdletName | Format-List Name, Module. - Force-load that module explicitly:
Import-Module ModuleName -Force. Run the original command again. - If it still fails, list every loaded module with
Get-Moduleand check for a same-named module already loaded from a different, older location — that's a command-precedence conflict, and unloading it withRemove-Module OldNamebefore re-importing usually clears it.
A word about spelling, capitalization, and hyphens
PowerShell cmdlet names are not case-sensitive, so capitalization alone never causes this error. What does cause it: a missing hyphen (GetADUser instead of Get-ADUser), an extra space inside the name, or — very commonly with commands copied from a PDF, a Word document, or a formatted web page — the hyphen character itself has been silently swapped for a longer dash that looks identical on screen but isn't the same character to the parser. If a command you copied fails and the exact same characters typed by hand work fine, that's almost always what happened. Retype the hyphens by hand rather than trusting a paste.
Fix 2: The cmdlet isn't installed on this PC at all
Cmdlets from Microsoft's own product teams — Azure, Microsoft Graph, SharePoint (PnP), Exchange Online — don't ship inside Windows. They come from separate modules you install from the PowerShell Gallery, and until you do, the cmdlet name means nothing to your session, no matter how correctly you spell it.
Open PowerShell as Administrator and run:
Install-Module -Name ModuleName -Scope CurrentUser
Two prompts commonly appear here, and both are safe to accept in a normal home or small-business setup:
- "NuGet provider is required to continue" — the first time any machine installs a module from the Gallery, it needs a small provider component to talk to it. Answer Yes.
- "Untrusted repository" — the PowerShell Gallery isn't marked as trusted out of the box, so you get a confirmation prompt the first time. Answer Yes, or run
Set-PSRepository -Name PSGallery -InstallationPolicy Trustedonce to stop being asked.
✅ Why this is the one to check first
If the NuGet or trust prompts hang, or the install itself fails with a different error, update the installer tooling before anything else: Install-Module PowerShellGet -Force -AllowClobber, then close and reopen PowerShell. An outdated PowerShellGet is the most common reason module installs silently fail on older Windows 10 machines that haven't been patched in a while.
Once Install-Module finishes without red text, close and reopen PowerShell before trying the original cmdlet again — a module you just installed doesn't automatically appear in a session that was already open when you installed it.
Fix 3: It's your own script file, not a cmdlet
If you're trying to run a .ps1 file you saved yourself, typing just its name will always fail, even sitting in the same folder. As a security measure, PowerShell refuses to run any executable — including your own scripts — unless it's in a folder listed in your PATH, or you tell it exactly where to look. Your current folder is deliberately not searched by default.
Type a dot and a backslash before the filename to mean "right here":
.\myscript.ps1
🕐 What changed between versions
- Before: older Windows PowerShell guidance is written against the Restricted execution policy, which is still the out-of-the-box default for Windows PowerShell 5.1 (the version built into Windows) and blocks every script from running at all.
- Now: PowerShell 7 — the separate, newer version you install yourself — ships with RemoteSigned as its default, which allows scripts you write locally to run and only blocks unsigned scripts downloaded from the internet.
- What that means for you: if a script fails with a permissions or "cannot be loaded" message rather than "not recognized," that's a different, execution-policy problem, not the one this article is about — and which PowerShell you're running changes what you'll see by default.
That last point is worth repeating because it trips up a lot of people searching for this exact error: "not recognized" and "running scripts is disabled on this system" are two unrelated errors. Only the second one is about execution policy. If you're seeing "not recognized," changing your execution policy will not fix it — you're missing the .\, or the file genuinely isn't where you think it is.
Fix 4: It's a real program, and it isn't on your PATH
This is the version that catches developers off guard, and it's the one behind "make is not a recognized command" and "run is not recognized as a cmdlet." Windows does not include make out of the box — it's a build tool that arrives with things like MinGW, MSYS2, or Visual Studio's build tools, and if you haven't installed one of those, "not recognized" is the correct, honest answer: the program genuinely does not exist on this PC yet. Installing it is the fix, not troubleshooting PowerShell.
run is a different flavor of the same trap: it isn't a real standalone command in PowerShell, Command Prompt, or Windows itself. If a tutorial told you to type a bare run, it almost certainly meant a prefixed command from another tool — npm run, dotnet run, docker run, or a Python script's own run command — and the prefix got lost somewhere between the tutorial and your terminal.
If the program is genuinely installed but Windows still can't find it by name, its folder is missing from PATH:
- Find the program's install folder (check its shortcut's "Open file location," or the installer's log) and confirm the .exe actually sits inside it.
- Press Win + I to open Settings, go to System > About > Advanced system settings, then click Environment Variables.
- Under "System variables" (or "User variables" if you only need it for your own account), select Path and click Edit.
- Click New and paste in the exact folder path that contains the .exe — not the .exe filename itself, just the folder — then click OK on every window to save.
- Close every open PowerShell or Command Prompt window and open a fresh one; PATH changes only apply to windows opened after the change.
⚠️ What this actually breaks
Before you touch the Path field, copy its entire current contents somewhere safe first. If you accidentally delete or overwrite the existing entries instead of adding to them, you can lose access to cmd, notepad, and every other built-in Windows command in that session — which is exactly the failure covered next.
When it isn't PowerShell's fault at all
Here's the sharpest fact in this whole article: if cmd, notepad, or another command that ships with Windows itself gets flagged as "not recognized," the problem is not PowerShell. Those commands live in C:\Windows\System32, and that folder is supposed to always be in your system PATH, before you ever open a terminal. If it's missing, something — usually a heavy-handed installer that overwrote the Path variable instead of adding to it — wiped out the built-in entries. That breaks Command Prompt exactly the same way it breaks PowerShell, because both tools rely on the same system-wide PATH.
To check: open Settings > System > About > Advanced system settings > Environment Variables, select the System Path variable, click Edit, and look for an entry that reads exactly C:\Windows\System32 (usually alongside C:\Windows and C:\Windows\System32\Wbem). If it's gone, add it back using the same steps as Fix 4 above, then restart your PC — this particular repair needs a full restart, not just a new terminal window, because so many background Windows services also depend on that PATH entry.
The copy-paste problem nobody warns you about
A surprising share of "I typed it exactly right" cases are true — the person typed it right the first time, then pasted a version that wasn't identical. Formatted text sources (a PDF, a Word document, a styled web page) routinely swap a plain hyphen-minus for a longer dash character during export, and the two look pixel-for-pixel the same in most fonts. PowerShell reads them as completely different characters. The same thing happens with non-breaking spaces sneaking in from a web page — visually a normal space, structurally not one.
If a pasted command fails and you're certain the spelling is right, select the whole line, delete it, and retype it by hand rather than pasting again. If it works once retyped, you've confirmed a hidden-character issue and can stop looking for anything more complicated.
Windows 10: the same fixes, one honest caveat
Every fix above works identically on Windows 10 — the command precedence rules, module loading, and the PATH environment variable all behave the same way. The Environment Variables path is reached slightly differently (right-click Start > System > Advanced system settings, rather than Settings > System > About), but the dialog itself is the same window.
Windows 10 reached the end of free security updates on October 14, 2025. It still runs PowerShell exactly as before, and none of that changes how this error works — but if you're troubleshooting an unsupported Windows 10 machine anyway, it's worth knowing you can still enroll it in Consumer Extended Security Updates through Settings > Windows Update, at no cost if you sync settings with a Microsoft account, for 1,000 Microsoft Rewards points, or for a one-time roughly $30 fee, with coverage currently running through October 2027.
Decision table: match your exact error to the fix
| Symptom | Likely cause | Fastest fix |
|---|---|---|
| A Microsoft cmdlet you've used before suddenly fails | Module not loaded this session | Import-Module -Force |
| A cmdlet you've never installed before | Module never installed | Install-Module |
| Your own .ps1 file, typed by filename | Missing .\ prefix | Type .\name.ps1 |
make, a build tool, a custom .exe | Not installed, or not in PATH | Install it, then add its folder to PATH |
cmd, notepad, other built-ins | System PATH lost System32 | Re-add C:\Windows\System32, restart |
| Works typed, fails pasted | Hidden character from source | Retype by hand |
Edge cases: remote sessions, 32-bit vs. 64-bit, and PowerShell 7
A cmdlet installed for "Windows PowerShell" (the version built into Windows, version 5.1) will not automatically appear in "PowerShell 7" (the newer, separately installed version), and vice versa — they're two different programs with two different module folders, even though both are launched from a very similar-looking blue or black window. If you installed a module in one and are testing in the other, that alone explains "not recognized." Check which one you're in with $PSVersionTable.PSVersion; a major version of 5 means Windows PowerShell, 7 means PowerShell 7.
Inside a remote session (Enter-PSSession, or a script run against another machine), the modules and PATH that apply are the remote computer's, not yours. A cmdlet that works perfectly on your own PC can be "not recognized" the moment you're remoted into a machine that never had that module installed. And inside a 32-bit PowerShell window on a 64-bit Windows install, some System32 tools are silently redirected to a different folder behind the scenes — if you've built a custom tool and placed it only in the 64-bit System32 folder, a 32-bit session won't see it there.
When none of this fixes it
If you've confirmed the module is installed, imported, and visible with Get-Command, but the exact command still fails only in one specific window or one specific script, the remaining usual suspects are a Group Policy restriction locking down which modules can load on a work or school-managed PC, or antivirus/endpoint-protection software quarantining the module's files without telling you — check your antivirus's quarantine log by name before assuming Windows itself is at fault. On a managed device, this genuinely isn't something you can fix yourself; it needs an administrator to adjust policy on their end, and no PATH edit or reinstall on your side will get around that.
🙋♂️ Jake's Reality Check
"So if I'd just checked whether cmd worked at all before spending twenty minutes reinstalling PowerShell, I'd have saved that customer's Tuesday?"
Pretty much, yes. That one thirty-second test — try a completely unrelated built-in command first — tells you in seconds whether you're chasing a PowerShell problem or a whole-system PATH problem, and it's the single most time-saving step in this entire article.
Ethan's take, when Jake asked whether he should just reinstall PowerShell every time this happens:
"Reinstalling fixes it by accident about as often as it fixes it on purpose. You're not repairing anything — you're resetting a default PATH that happened to include the folder you needed, and undoing every module you'd already installed along with it. Check the four categories first. It takes less time than the reinstall, and you actually learn which one broke."
- WMIC not recognized as an internal or external command: the fix
Same "not recognized" error, but for the older WMIC tool Microsoft has been removing from Windows entirely.
Frequently asked questions
Why does PowerShell say "not recognized" but Command Prompt runs the same command fine?
They aren't the same environment. Command Prompt and PowerShell each maintain their own aliases, and a cmdlet only exists inside PowerShell — Command Prompt has no concept of cmdlets at all, so a command that's actually a native .exe on your PATH will run in both, but a true PowerShell cmdlet only ever works in PowerShell.
I typed the command exactly as the tutorial showed. Why is it still not recognized?
"Exactly as shown" usually means the visible characters matched, not that a required module was installed first. Tutorials frequently assume a module is already present and skip the install step. Check Get-Command for the cmdlet before assuming your typing is at fault.
Does this mean my computer is broken?
No. In the large majority of cases it means one specific module isn't installed or loaded, which is completely normal and expected on a fresh Windows install — Windows deliberately doesn't ship every possible PowerShell module by default.
Why does "cmd" itself get flagged as not recognized in PowerShell?
Because cmd.exe lives in C:\Windows\System32, and if that folder has been removed from your system PATH — usually by an installer that overwrote the variable instead of adding to it — every native Windows command breaks at once, not just cmd. Check and restore the PATH entry as described above.
Is this the same as the "running scripts is disabled on this system" error?
No, and it's worth separating them clearly. "Not recognized" means PowerShell couldn't find the command at all. "Running scripts is disabled" means it found your script but your execution policy is blocking it from running. Changing your execution policy will never fix a "not recognized" error.
Why does "make" say it's not a recognized command?
make is a build tool that doesn't ship with Windows. If you haven't installed something that provides it — MinGW, MSYS2, or Visual Studio's build tools, for example — "not recognized" is Windows correctly reporting that the program doesn't exist on this PC yet.
Why does "run" say it's not recognized as a cmdlet?
There is no standalone run command in PowerShell or Windows. If you were told to type run on its own, the instructions likely meant a prefixed version from another tool, such as npm run, dotnet run, or docker run, and the prefix was left out somewhere along the way.
Why does typing "windows" as a command say it's not a valid command?
"Windows" is not a command in any Windows shell. This almost always happens when a longer command containing spaces gets split apart — for example, an unquoted file path with a space in it — and the shell tries to run only the first word as the command, leaving the rest, including a stray word like "windows," as leftover text it can't interpret either.
I ran Install-Module and it worked, but the cmdlet still isn't found in a new window. Why?
Check that you installed for the right scope and the right PowerShell version. -Scope CurrentUser installs only for your account; if you're testing in an elevated ("Run as Administrator") window under a different profile context, or in PowerShell 7 after installing under Windows PowerShell 5.1, the module genuinely isn't there for that session.
Do I need to be an administrator to fix this?
Installing a module with -Scope CurrentUser does not require administrator rights. Editing the system-wide PATH variable, or installing most standalone programs, does. If a fix's step involves Environment Variables' "System variables" section, expect an administrator prompt.
Does reinstalling PowerShell fix it?
Sometimes, by coincidence, because a fresh install resets PATH to its defaults and can clear a conflict. But it also removes every module you'd previously installed, so it should be a last resort, not a first step — work through the four categories above first.
Why does the error mention "operable program" if I just typed a cmdlet name?
PowerShell uses one shared error message for all four categories it searches — aliases, functions, cmdlets, and native programs — rather than a different sentence for each. The wording doesn't change based on what you were trying to run; only the underlying cause does.
I copied the command from a website and it still fails, but retyping it works. Why?
Text copied from formatted sources like PDFs or styled web pages can silently substitute a hyphen or space character for a similar-looking one that PowerShell's parser reads differently. Retyping by hand replaces those characters with the plain versions and resolves it.
Is PowerShell 7 different from "Windows PowerShell" for this error?
Yes — they're two separate programs with separate installed-module folders and separate default execution policies. A module installed in one won't appear in the other. Check which you're running with $PSVersionTable.PSVersion.
Can antivirus or Group Policy cause this error?
Yes. Endpoint protection software can quarantine a module's files without any visible warning, and Group Policy on a managed work or school device can restrict which modules are allowed to load. On a managed PC, this needs an administrator to resolve, not a PATH or install fix on your end.
Will this be different on Windows 10 versus Windows 11?
No — the underlying command-search behavior, module system, and PATH variable work identically on both. The only difference is where the Environment Variables dialog is reached from in Settings, and that Windows 10 itself is past its free-support date, which is worth knowing but doesn't change any of the fixes here.
Revision note. Written September 2026, covering Windows 11 and Windows 10, Windows PowerShell 5.1, and PowerShell 7. This will need a revisit if a future Windows release changes how module auto-loading or PATH handling works. If you're staring at a wall of red text right now, take a breath — this error looks alarming, but it's almost always a small, fixable mismatch, not something you broke.If you found it was not working, please let me know through contact us page or comments. I will update the post accordingly! thanks!