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

[release/5.0] Fix reading performance counters on Windows ARM64 #46590

Merged
merged 4 commits into from
Jan 14, 2021

Conversation

ericstj
Copy link
Member

@ericstj ericstj commented Jan 5, 2021

Backport of #45142 to release/5.0

Fixes: #41144

Customer Impact

System performance counters cannot be read on Windows ARM64. Any access results Win32Exception due to failure to load perfcounter.dll module. Customers are blocked from using System.Diagnostics.PerformanceCounter on Windows ARM64.

Regression?

No, new platform

Testing

Reenabled all failing unit tests, and better conditioned the tests to improve coverage. Outer-loop testing.

Risk

Low. The only risk here is that this may not be enough for some consumers of Performance Counters #46589. However the current fix should unblock most consumers.

* Remove dependency on PerfCounter.dll

This dependency was unnecessary and only for calling through to pdh.dll.

PerfCounter.dll is still needed for the consumption side of performance
counters, but removing from the dependency from the .NET can help enable
some scenarios like reading non-.NET counters.

* Update conditions on performance counter tests.

* Condition more perf counter tests
Update assembly version of PerformanceCounter package and build it in
servicing.

Also update the package baseline to ensure that Windows.Compatibility
package gets the new version.
@ghost
Copy link

ghost commented Jan 5, 2021

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

Issue Details

Backport of #45142 to release/5.0

Fixes: #41144

Customer Impact

System performance counters cannot be read on Windows ARM64. Any access results Win32Exception due to failure to load perfcounter.dll module. Customers are blocked from using System.Diagnostics.PerformanceCounter on Windows ARM64.

Regression?

No, new platform

Testing

Reenabled all failing unit tests, and better conditioned the tests to improve coverage. Outer-loop testing.

Risk

Low. The only risk here is that this may not be enough for some consumers of Performance Counters #46589. However the current fix should unblock most consumers.

Author: ericstj
Assignees: ericstj
Labels:

area-System.Diagnostics.Tracing

Milestone: -

@@ -19,7 +19,7 @@ internal static partial class Libraries
internal const string Odbc32 = "odbc32.dll";
internal const string Ole32 = "ole32.dll";
internal const string OleAut32 = "oleaut32.dll";
internal const string PerfCounter = "perfcounter.dll";
internal const string Pdh = "pdh.dll";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pdh [](start = 37, length = 3)

just wondering, does pdh.dll exist on all Windows skus we support? I guess so but wanted to ensure we looked at that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. It was already being used by perfcounter.dll so it will exist everywhere this worked before. It's been present in Windows since XP/2k3. It's also part of nano and server core.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfcounter.dll (which it was using before) imports PdhFormatFromRaw value, which MSDN says back to Windows XP, eg
https://docs.microsoft.com/en-us/windows/win32/api/pdh/nf-pdh-pdhformatfromrawvalue

As for SKU's, the tests exclude only Nano server so it apparently is available on Server Core.

Copy link
Member

@danmoseley danmoseley Jan 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having said that, the old code presumably failed on Nano with Win32Exception here

and the new code presumably fails with EntrypointNotFoundException() ? Not sure that is important but just pointing it out.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, our comments crossed. Why do the tests exclude nano?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess Nano not carrying the full framework which means the PerfCounter.dll is absent there. but maybe after this change we can try to enable the test there and look if it will succeed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah - of course. Well, that would be a happy result if it worked.

Copy link
Member Author

@ericstj ericstj Jan 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My change did enable many test cases which read perf counters on nano. See many of the test cases which removed conditions completely. These tests are running and passing on nano.

I still conditioned a few tests which failed to write to perfcounters. I can't recall if I tried removing the write condition for nano or not. I can try this in master and see if we can enable more tests. It's somewhat irrelevant since folks won't be able to read the counters there due to lack of perfcounter.dll, but no harm in getting that coverage.

@ericstj
Copy link
Member Author

ericstj commented Jan 5, 2021

Package testing currently failing to restore Microsoft.NETCore.Platforms:

C:\h\w\AE0F09A1\w\A0A9091A\u\netcoreapp3.0\project.csproj : error NU1102: Unable to find package Microsoft.NETCore.Platforms with version (>= 5.0.2)

It looks like we tie platforms package version to product version:

<PlatformPackageVersion>$(ProductVersion)</PlatformPackageVersion>

We haven't made any changes to this package since GA:
https://github.com/dotnet/runtime/commits/release/5.0/src/libraries/pkg/Microsoft.NETCore.Platforms

In 3.1 we maintained this independently:
https://github.com/dotnet/corefx/blob/aae1eab04d154a198c0e254ca003277f5079e484/eng/Packaging.props#L30

So I'm thinking we just dial back this property to 5.0.0. Thoughts @Anipik?

@danmoseley danmoseley added the Servicing-consider Issue for next servicing release review label Jan 5, 2021
@ericstj
Copy link
Member Author

ericstj commented Jan 7, 2021

I will cherry-pick ac5e2e3 to unblock CI on this.

@ericstj
Copy link
Member Author

ericstj commented Jan 7, 2021

Mono test failure is #43981

@leecow leecow added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jan 12, 2021
@leecow leecow added this to the 5.0.3 milestone Jan 12, 2021
@Anipik
Copy link
Contributor

Anipik commented Jan 14, 2021

networking failure #45204

@Anipik Anipik merged commit c9e1648 into dotnet:release/5.0 Jan 14, 2021
@ericstj ericstj deleted the rel-5.0-PerfCounter-arm64 branch January 14, 2021 05:49
@ghost ghost locked as resolved and limited conversation to collaborators Feb 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants