Skip to content
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

PerformanceCategoryCounter.GetInstanceNames() not returning correct output for some V2 performance Counters #30182

Closed
Anipik opened this issue Jul 8, 2019 · 5 comments

Comments

@Anipik
Copy link
Member

@Anipik Anipik commented Jul 8, 2019

.Net uses Registry apis to get the list of performance counters and their properties.
We generally retrieve a byte array and then we parse it to get the values of all the desired data.

The windows performance counter belongs to 2 categories i.e V1 and V2 (Generally contain performance counters added after windows vista)

.Net code works perfectly fine with the V1 counterset but is not so reliable with V2 counterset. Windows tried to make these v2 counterset work with registry apis for backwards compatibility.

One such issue is that pcc.GetInstanceNames is not returning the instance names correctly for "SMB Client Shares" Counter set. It is V2 counterset added in windows 8.1

Steps to repro

$t = New-Object System.Diagnostics.PerformanceCounterCategory -ArgumentList "SMB Client Shares"
$t.GetInstanceNames()

Actual output

*
_total

Expected output

PS C:\Users\anagniho> $t = Get-Counter -ListSet "SMB Client Shares"
PS C:\Users\anagniho> $t.PathsWithInstances
\SMB Client Shares(\scratch2\scratch)\Compressed Bytes Sent/sec
\SMB Client Shares(\scratch2\IPC$)\Compressed Bytes Sent/sec
\SMB Client Shares(\scratch2\CrashDumpsOS)\Compressed Bytes Sent/sec
\SMB Client Shares(_Total)\Compressed Bytes Sent/sec

workaround

The workaround is to use pdh library provided by the windows to read these counters, However there is no .Net wrapper for it.

How to resolve

In order to find the actual culprit i.e if the problem is in windows registry apis (added for back compat) or .NET parsing the byte array code. we will have to directly call these registry apis and verify the byte array returned.

update

You must have a network share open eg in file explorer to get a repro

cc @danmosemsft

@danmoseley
Copy link
Member

@danmoseley danmoseley commented Jul 8, 2019

Is this worth reporting to Windows, since it seems they are trying to be compatible but not doing so? If so Tarek can show how to do that.

@Anipik
Copy link
Member Author

@Anipik Anipik commented Jul 8, 2019

I talked with Doug(handles all the performance counter stuff) on the windows team. They are happy to help if there is any bug with the windows api but we first need to confirm that we are parsing it correctly and give them a repro with just the windows registry apis (Without the .Net Wrapper)

@benpye
Copy link
Contributor

@benpye benpye commented Oct 16, 2019

Did we get anywhere with this - do we know where this issue is coming from?

@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@msftgits msftgits added this to the Future milestone Feb 1, 2020
@idigdoug
Copy link

@idigdoug idigdoug commented Feb 19, 2020

This is actually a bug in the "SMB Client Shares" counterset. It doesn't handle wildcard queries correctly. The bug has already been addressed in the Windows product and a fix is expected to be available in a future version of Windows.

The .NET API uses the registry access, and the registry access uses the low-level V2 APIs to create a wildcard query, and the wildcard query is handled incorrectly, so you get incomplete results.

The PDH API uses the low-level V2 APIs to make a list of instances and then uses the low-level V2 APIs to create one non-wildcard query for each instance, and the non-wildcard queries are handled correctly, so you get complete results.

@danmoseley
Copy link
Member

@danmoseley danmoseley commented Feb 19, 2020

Great thank you @idigdoug for the confirmation. No work required on .NET then, will close.

@danmoseley danmoseley closed this Feb 19, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Dec 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants