I did not like having to add in the 1 second stall to all of the PerformanceCounter solutions. Instead I chose to use a WMI solution. The reason the 1 second wait/stall exists is to allow the reading to be accurate when using a PerformanceCounter. However if you calling this method often and refreshing this information, I'd advise not to constantly have to incur that delay... even if thinking of doing an async process to get it.
I started with the snippet from here Returning CPU usage in WMI using C# and got here:
//Get CPU usage values using a WMI query
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_PerfFormattedData_PerfOS_Processor");
var cpuTimes = searcher.Get()
.Cast<managementobject>()
.Select(mo => new {
Name = mo["Name"],
Usage = mo["PercentProcessorTime"]
}).ToList();
//The '_Total' value represents the average usage across all cores,
//and is the best representation of overall CPU usage
var query = cpuTimes.Where(x => x.Name.ToString() == "_Total").Select(x => x.Usage);
var cpuUsage = query.SingleOrDefault();
If you want to verify the cpuUsage, add up each core's value in the cpuTimes List and then divide by the total number of cores to get the "_Total" value.
I have added a full explanation of the solution on my blog post below:
