@alastairlundy could you please run the below command in PowerShell and share if it prints the processor model?

Get-CimInstance Win32_Processor

@alastairlundy could you please run the below command in PowerShell and share if it prints the processor model?

Get-CimInstance Win32_Processor

Thanks for the quick reply.

The output from that command is:

DeviceID Name                                Caption                               MaxClockSpeed SocketDesignation Manufacturer
-------- ----                                -------                               ------------- ----------------- ------------
CPU0     12th Gen Intel(R) Core(TM) i7-1270P Intel64 Family 6 Model 154 Stepping 3 2200          U3E1              GenuineIntel

BenchmarkDotNet has two strategies for detecting the CPU model on Windows (see WindowsCpuDetector): MosCpuDetector and WmicCpuDetector. If Wmic is not installed, MosCpuDetector is the only available detector. However, it is only enabled in .NET Framework, not in .NET Core/.NET 5+. Since Get-CimInstance Win32_Processor provides the expected CPU information, we have two possible solutions:

• If ManagementObjectSearcher works on Windows with .NET 5+ (I currently do not have access to a Windows machine to verify this), we should update MosCpuDetector.IsApplicable.
• Otherwise, we should call Get-CimInstance Win32_Processor via PowerShell, similar to how we call wmic.

PRs are welcome.

• If ManagementObjectSearcher works on Windows with .NET 5+ (I currently do not have access to a Windows machine to verify this), we should update MosCpuDetector.IsApplicable.

The .NET docs website entry for it says that it requires a dependency on this Nuget package for .NET Standard 2.0 and .NET 5+.

Figuring out how to add that dependency only on required TFMs (i.e. .NET 5+ and not .NET Framework) seems like it would be quite messy unless either a .NET Framework TFM was added to BenchmarkDotNet, or, if there's no objection, adding it as a dependency for all TFMs.

Edit: Actually it looks like version 6.0 of that package is already a dependency of BenchmarkDotNet so I don't see why the MosCpuDetector class couldn't be tweaked to run it on .NET 5+. Though it also may be worth updating that dependency to a newer version since the latest stable version is 9.0.5 .

Otherwise, we should call Get-CimInstance Win32_Processor via PowerShell, similar to how we call wmic.

If I were to work on a PR for this that calls Powershell, would you guys want the code to go into MosCpuDetector or a new Detector class?

@AndreyAkinshin Do you have a preference for either solution?

Though it also may be worth updating that dependency to a newer version since the latest stable version is 9.0.5 .

That would be best if it solves the issue.

Unfortunately it looks like theSystem.Management package wrongly declares it works on .NET 5+ (See this and this) in that the code relies on a dll that isn't present if .NET Framework isn't installed on the target device.

In my fork I've enabled MosCpuDetector to run on .NET 5+ and tested it.

It works and the CPU is properly detected in BenchmarkDotNet sample benchmarks, but only because I also have .NET Framework installed. If I didn't have .NET Framework installed it would likely not work.

BenchmarkDotNet v0.15.1-develop (2025-06-04), Windows 11 (10.0.26100.4061/24H2/2024Update/HudsonValley)
12th Gen Intel Core i7-1270P 2.20GHz, 1 CPU, 16 logical and 12 physical cores
.NET SDK 9.0.300
  [Host]     : .NET 8.0.16 (8.0.1625.21506), X64 RyuJIT AVX2 [AttachedDebugger]
  DefaultJob : .NET 8.0.16 (8.0.1625.21506), X64 RyuJIT AVX2

I think MosCpuDetector should stay disabled on .NET 5+, and use a detector that works on .NET 5+ on Windows without WMIC and without .NET Framework once that is available.

I'll give the Powershell based detector a shot.

.Net Framework comes installed on Windows standard. I don't think we need to support the fringe case of Windows without Framework. Framework has no end support date.

dotnet/runtime#66386 (comment) Suggests to use WMILight instead of System.Management, which you could try.