New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some drivers throw an exception when fetched with Get-Service, but still return the object anyway #10371
Comments
What is MsQuic? How could we install it? Maybe you know another repo scenario? |
MsQuic is a driver. The way that I obtained it is by first getting a list of drivers, then iterating through their names with $drivers = Get-CimInstance win32_SystemDriver
foreach ($driver in $drivers)
{
$svcObj = Get-Service -Name $driver.Name
} When I do this, then I get a few drivers on my computer that return the same error (MsQuic is just the first one for me). If I say $svcObj = Get-Service -Name $driver.Name -ErrorAction -SilentlyContinue we can bypass that problem and access the driver objects that throw exceptions, because the correct object is still returned, but in that case it just seems like the exception is wrong. |
I can repo with Get-Service -Name WinQuic
Get-Service : Service 'WinQuic (WinQuic)' cannot be queried due to the following error:
At line:1 char:1
+ Get-Service -Name WinQuic
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (System.ServiceProcess.ServiceController:ServiceController) [Get-Service], ServiceCommandException
+ FullyQualifiedErrorId : CouldNotGetServiceInfo,Microsoft.PowerShell.Commands.GetServiceCommand
Status Name DisplayName
------ ---- -----------
Running WinQuic WinQuic
PS > $error[0] | fl * -Force
PSMessageDetails :
Exception : Microsoft.PowerShell.Commands.ServiceCommandException: Service 'WinQuic (WinQuic)' cannot be qu
eried due to the following error:
TargetObject : WinQuic
CategoryInfo : PermissionDenied: (System.ServiceProcess.ServiceController:ServiceController) [Get-Service], Se
rviceCommandException
FullyQualifiedErrorId : CouldNotGetServiceInfo,Microsoft.PowerShell.Commands.GetServiceCommand
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1} |
/cc @daxian-dbw @bergmeister @SteveL-MSFT |
In PowerShell Core 6.2.0, I get two errors, whether elevated or not:
The first error above is reported by Microsoft.PowerShell.Commands.GetServiceCommand.AddProperties after its QueryServiceConfig2 call returns false and sets Win32 error 15100 "The resource loader failed to find MUI file". This error has ErrorCategory.PermissionDenied even though permission was not denied.
The second error above comes from a Win32Exception thrown by System.ServiceProcess.ServiceController.get_StartType after its QueryServiceConfig call returns false and sets Win32 error 15100 "The resource loader failed to find MUI file". Process Monitor shows that [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WinQuic] "DisplayName" is "@%SystemRoot%\system32\drivers\winquic.sys,-1" and "Description" is "@%SystemRoot%\system32\drivers\winquic.sys,-2". services.exe tries to access "C:\Windows\System32\drivers\winquic.sys" (success, but apparently lacks the resources), "C:\WINDOWS\system32\SystemResources\winquic.sys.mun" (directory does not exist), "C:\Windows\System32\drivers\en-US\winquic.sys.mui" (file does not exist), and "C:\WINDOWS\system32\drivers\en\winquic.sys.mui" (directory does not exist).
Even if CoreFX fixes ServiceController… although I am not sure how it can be fixed, since QueryServiceConfig is failing… it seems the ErrorCategory.PermissionDenied should still be corrected at the PowerShell side. |
The problem is actually here: https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Management/commands/management/Service.cs#L677 The cmdlet fails at querying some information and writes a non-terminating error. This doesn't happen in Windows PowerShell because these are actually additional note properties being added. Seems like the right thing to do is just to not emit the non-terminating error at all and doc that some of these properties will be
|
How does an user know that a property cannot be read? I believe the non-terminating error is right thing in the case. |
I get this issue with ssd-broker service from Open-ssh .
So it appears to be more than drivers. (It also may be an easier one to test with). |
Not sure which OpenSSH you're talking about, using the built-in one in Windows 10 I only have As others have said, my take is that if we fail to retrieve a property, it's perfectly fine to emit a non-terminating error as long as we still emit what we were able to retrieve. Is it also possibly the case that we're trying to retrieve more properties than Windows PowerShell did, and that's why we're hitting this now? |
@iSazonov there are other cases where failure to retrieve specific information simply has that property be $null without emitting any error |
At least the error message needs to be updated. |
I'm not sure how I've configured mine differently, but I don't think it was delivered in Windows (the EXE files are not signed, and have no copyright notice. But when I look in the Services GUI I get this in the description box. 15100 is The resource loader failed to find MUI file, so it looks like it should be loading a language specific description and can't find it. (en-GB instead of en-US ? who knows).
My first reaction was NO! But having seen that services has ERROR in the the description, I've changed to "yeah, OK, that's what happens elsewhere". The other information IS returned, so that's OK. I was anti-producing an error because it caused a pester test I had to fail (get-service was get-anyRandomData) and including -errorAction fixes that.
Yep. Windows PowerShell does not get the description. So no error. A quick reg hack will probably fix the description. |
@jhoneill We had the discussion last week in the @PowerShell/powershell-committee and we agree that there is differing behavior between cmdlets in throwing non-terminating errors vs. just blanking the information that can't be retrieved. For instance, there's a (maybe bug, maybe by-design) behavior in However, we may not need to make a broad call on that, as I believe @JamesWTruher is investigating whether there's just a bug here we can fix. |
@joeyaiello Yes, that makes sense. |
@PowerShell/powershell-committee reviewed this, we agree that if a property value cannot be retrieved, then suppressing the error will be a better user experience. If an entire object cannot be retrieved, then a non-terminating error is appropriate (with a good error message). |
FYI, I see this happening now with |
I got the same problem, so it is still not fixed. Here an actualized description: Step to reproduce (no difference if elevated or not): Actual behaviour: Reason:
contains probably a reference to a string in a dll which not exists. Expected behaviour: |
If somebody could create a simple repro on C# one could open issue in .Net Runtime. |
Any plans to fix this? Came here after googling for a solution of:
|
Also related to: |
Still a problem as of 7.4.1 on |
Steps to reproduce
Run in elevated PowerShell prompt:
If not run in an elevated prompt, no object is returned in PS6/7, and only the exception is shown. In PS5, the object is returned and there is no exception.
Expected behavior
From PowerShell 5:
Actual behavior
From PowerShell 6.2 and 7:
Environment data
PowerShell 6.2:
PowerShell 7:
The text was updated successfully, but these errors were encountered: