runtime: System.Management.dll not working on win-arm64
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
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 27 (20 by maintainers)
Yes, the fix is part of the following package versions:
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.
@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.
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.
.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.
I also encountered this problem by using the latest
https://github.com/dotnet/runtime/blob/2327a36c5222a8e4e522ab27455bcbd8002efd06/src/libraries/System.Management/src/System/Management/ManagementScope.cs#L305
[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.
If possible, we should also re-enable tests on ARM64 while doing this. https://github.com/dotnet/runtime/blob/59f7dafe28cae36f33eecbab40635663c042e4d5/src/libraries/System.Management/tests/WmiTestHelper.cs#L14
This wasn’t possible in the past when we didn’t have an ARM64 .NETFramework. Now that we do, we should make it work 👍
We probably need to update the lookup code that finds the .NET Framework installation (kudos to @ericstj): https://github.com/dotnet/runtime/blob/2327a36c5222a8e4e522ab27455bcbd8002efd06/src/libraries/System.Management/src/System/Management/ManagementScope.cs#L292