For some reason, when I run Get-Service
in powershell, it throws an error. If I run Set-Service
first however, Get-Service
will work until I open powershell again. I can't seem to find this issue anywhere online. Has anyone experienced this and if so, is there a solution?
Error: "Program 'Get-Service' failed to run: No application is associated with the specified file for this operationAt line:1 char:1"
tl;dr
Remove file C:\Windows\System32\Get-Service
from your system - it shouldn't be there.
After that, Get-Service
will start working again.
PowerShell tries to open the perhaps accidentally created, extension-less C:\Windows\System32\Get-Service
file on your system first, if you haven't imported module Microsoft.PowerShell.Management
yet in the session.
$env:PATH
is in itself problematic - see this answer.The Microsoft.PowerShell.Management
module, which contains the Get-Service
and Set-Service
cmdlets (among other commands), is normally imported on demand the first time you try to execute one of its commands in a session.
Technically, since the module is located in a known location, it is subject to module auto-loading.
However, if the module isn't imported yet, an external program / document file of the same name located in one of the directories listed in environment variable $env:PATH
takes precedence, and it is executed / opened by default.
Since the file in your case was had no filename extension, the Windows shell did not know how to open it, resulting in the error message you saw (if you double-clicked the file in File Explorer, you'd get "How do you want to open this file?" dialog instead).
As a result, trying to execute a command named Get-Service
by itself does not trigger import of the Microsoft.PowerShell.Management
module - the external file keeps getting called.
By contrast, since the Set-Service
cmdlet is not shadowed by an external file, calling it does implicitly import the module.
Once the module has been imported, submitting command Get-Service
calls the cmdlet rather than the external file, because PowerShell's regular command precedence then kicks in, where cmdlets take precedence over external programs with the same name.
While this situational distinction makes the execution behavior hard to predict, consistently giving precedence to known cmdlets, irrespective of whether their module happens to have been imported into the current session yet or not, is not an option for performance reasons: see the discussion in since-closed GitHub issue #10853.
To unambiguously invoke a command from a given module, prefix the command name with the module name followed by \
:
That is, even without the module imported, you could have invoked the Get-Service
cmdlet as follows:
Microsoft.PowerShell.Management\Get-Service
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With