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