System.Management.dll not working on win-arm64

[SteveL-MSFT]

Description

This dll works on x64, but fails to load the required native dll on win-arm64. This is impacting the Get-HotFix cmdlet in PowerShell 7.

Reproduction Steps

var scope = new System.Management.ManagementScope(@"root\cimv2");
scope.Connect();

Expected behavior

No error (nothing will happen with this snippet)

Actual behavior

It appears to be trying to load the native library from Framework64 when it should be loading it from FrameworkArm64:

Unhandled exception. System.TypeInitializationException: The type initializer for 'System.Management.WmiNetUtilsHelper' threw an exception.
 ---> System.ComponentModel.Win32Exception (193): Failed to load required native library 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll'.
   at System.Management.WmiNetUtilsHelper..cctor()
   --- End of inner exception stack trace ---
   at System.Management.MTAHelper.IsNoContextMTA()
   at System.Management.MTAHelper.CreateInMTA(Type type)
   at System.Management.ManagementPath.CreateWbemPath(String path)
   at System.Management.ManagementPath..ctor(String path)
   at System.Management.ManagementScope..ctor(String path)
   at Program.<Main>$(String[] args) in C:\Users\slee\test\wmi\Program.cs:line 1

Regression?

Don't know

Known Workarounds

No response

Configuration

.NET 7
Windows 11
arm64

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-management
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This dll works on x64, but fails to load the required native dll on win-arm64. This is impacting the Get-HotFix cmdlet in PowerShell 7.

Reproduction Steps

var scope = new System.Management.ManagementScope(@"root\cimv2");
scope.Connect();

Expected behavior

No error (nothing will happen with this snippet)

Actual behavior

Unhandled exception. System.TypeInitializationException: The type initializer for 'System.Management.WmiNetUtilsHelper' threw an exception.
---> System.ComponentModel.Win32Exception (193): Failed to load required native library 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll'.
at System.Management.WmiNetUtilsHelper..cctor()
--- End of inner exception stack trace ---
at System.Management.MTAHelper.IsNoContextMTA()
at System.Management.MTAHelper.CreateInMTA(Type type)
at System.Management.ManagementPath.CreateWbemPath(String path)
at System.Management.ManagementPath..ctor(String path)
at System.Management.ManagementScope..ctor(String path)
at Program.

$(String[] args) in C:\Users\slee\test\wmi\Program.cs:line 1

Regression?

Don't know

Known Workarounds

No response

Configuration

.NET 7
Windows 11
arm64

Other information

No response

Author:	SteveL-MSFT
Assignees:	-
Labels:	area-System.Management
Milestone:	-

[smasher164]

Could be related: #59844

/cc @ericstj @danmoseley

[ViktorHofer]

We probably need to update the lookup code that finds the .NET Framework installation (kudos to @ericstj):

runtime/src/libraries/System.Management/src/System/Management/ManagementScope.cs

Line 292 in 2327a36

RegistryKey netFrameworkSubKey = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\.NETFramework\");

[ericstj]

If possible, we should also re-enable tests on ARM64 while doing this.

runtime/src/libraries/System.Management/tests/WmiTestHelper.cs

Line 14 in 59f7daf

PlatformDetection.IsNotArmNorArm64Process &&

This wasn't possible in the past when we didn't have an ARM64 .NETFramework. Now that we do, we should make it work 👍

[ericstj]

This is likely not a regression, but rather something that never worked but can now that we have an Arm64 .NET Framework. @SteveL-MSFT how urgent is a fix here?

[SteveL-MSFT]

@ericstj I don't think it's super urgent, but the original issue was reported by a customer. If it can be addressed within the next couple of months, I think that would be fine.

[SimonCropp]

isnt this a duplicate of #59844?

just a head up that this also breaks

• https://github.com/VerifyTests/Verify
• https://github.com/shouldly/shouldly
• https://github.com/approvals/ApprovalTests.Net

since they will all be hit by VerifyTests/DiffEngine#315

[Nuklon]

Can't we ship that DLL with .NET Core instead? It would be much better than relying on .NET Framework being installed.

[SimonCropp]

@SteveL-MSFT

I don't think it's super urgent, but the original issue was reported by a customer. If it can be addressed within the next couple of months, I think that would be fine.

Note this was actually reported in Oct 2021 in 59844. so a "couple of months" has definitely passed

[JamesWCCheng]

I also encountered this problem by using the latest

runtime/src/libraries/System.Management/src/System/Management/ManagementScope.cs

Line 305 in 2327a36

string wminet_utilsPath = Path.Combine(

[Experimental change]
If I set registry InstallRoot from C:\Windows\Microsoft.NET\Framework64\ to C:\Windows\Microsoft.NET\FrameworkArm64\

ARM64 process with WMI works fine.

I think it's a simple change, I'm looking forward to seeing it gets fixed soon.

[JamesWCCheng]

I also encountered this problem by using the latest

runtime/src/libraries/System.Management/src/System/Management/ManagementScope.cs

Line 305 in 2327a36

string wminet_utilsPath = Path.Combine(

[Experimental change] If I set registry InstallRoot from C:\Windows\Microsoft.NET\Framework64\ to C:\Windows\Microsoft.NET\FrameworkArm64\

ARM64 process with WMI works fine.

I think it's a simple change, I'm looking forward to seeing it gets fixed soon.

.netframework has no such issue since it wrote
System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory() + "\wminet_utils.dll";
https://referencesource.microsoft.com/#System.Management/managementscope.cs,304
to compose the path. But this API didn't fit .net core.

Can Microsoft fix it as soon as possible? It's a critical issue I think, it makes this package malfunction.

[ViktorHofer]

We understand the importance here which is why I'll be working on a fix for this next week. After the fix is merged into main, we plan to backport it into .NET 6 and .NET 7.

[SimonCropp]

@ViktorHofer can it be backported to the v6 System.Management nuget? i still support netcore 3.1 since it only went "End of support" 4 month ago

Please

[ViktorHofer]

Yes, the plan is to backport the fix into both the 6.0 and 7.0 nuget package but a) we don't yet have a fix ready and b) our shiproom needs to first approve the backports.

Note that while .NET 6 package provide a netcoreapp3.1 assembly, that runtime is already out-of-support and we strongly discourage staying on it or offering assets for it because of the lack of security fixes.

[SimonCropp]

@ViktorHofer

the plan is to backport the fix into both the 6.0 and 7.0 nuget package

thanks. thats great to hear

that runtime is already out-of-support and we strongly discourage staying on it or offering assets for it because of the lack of security fixes

i hear you. but i still have a non-trivial number of people using my libs that are still on unsupported frameworks VerifyTests/Verify#784

[Nuklon]

Can't we ship that DLL with .NET Core instead? It would be much better than relying on .NET Framework being installed.

Thanks, but what about shipping the necessary DLL with Runtime? That'd be better as it would avoid the need to have .NET Framework installed.

[ViktorHofer]

Thanks, but what about shipping the necessary DLL with Runtime? That'd be better as it would avoid the need to have .NET Framework installed.

From my discussion with @ericstj, there was a very strong reason to not bundle that assembly into the package but I don't remember. @ericstj would you mind sharing some context here?

[ericstj]

WMINet_utils is a native binary and I believe requires machine-wide registration/installation to work correctly. It also has never been open sourced, so it would need to go through that process. On top of that the component isn't owned by .NET so it would require some help/permission from the owning team to see that happen assuming such a port was even possible. That's all out of the scope of this issue and tracked by #66386.

[Dharmateja-Challa-Dell]

I have done few changes as per previous comments, enabled unit test for ARM64, added one test case for this particular issue. Not sure if this solution is correct or not, hence wanted to check, attaching my changes and unit test case and its results in both ARM64 and X64
.NetCore81400.zip

[ViktorHofer]

@Dharmateja-Challa-Dell I won't open you attachment. Can you please let me know what your comment refers to?

[danmoseley]

@Dharmateja-Challa-Dell if you want to share a proposed change please do it by pushing a branch to your fork and sending a link to that.

[Silve2611]

This is also a critical error for us. When can we expect for that it will be resolved? Do you have a timeframe?

[Dharmateja-Challa-Dell]

@Dharmateja-Challa-Dell if you want to share a proposed change please do it by pushing a branch to your fork and sending a link to that.
Took a fork and added changes to branch
https://github.com/Dharmateja-Challa-Dell/runtime/branches/

[ViktorHofer]

Do you have a timeframe?

As shared above, I'll be working on a fix this week and we will then bring it to our shiproom for backport approval. I can't share when this would then be available but likely not before May.

EDIT: We got this into the April servicing release so updated packages with the change will be available mid April.

[SimonCropp]

was this included in v6.0.1? https://www.nuget.org/packages/System.Management/6.0.1

[ViktorHofer]

Yes, the fix is part of the following package versions:

• https://www.nuget.org/packages/System.Management/6.0.1
• https://www.nuget.org/packages/System.Management/7.0.1
• https://www.nuget.org/packages/System.Management/8.0.0-preview.3.23174.8

[SimonCropp]

@ViktorHofer thanks