A .NET developer can use WMI to obtain information about drivers installed on the client machine, verify whether the system is licensed or not, check for hardware configuration and a lot more.
Quoting Linus Torvalds, “Talk is cheap. Show me the code”, let’s get to the basics of WMI usage. To get data through WMI, a SQL-like query is used. The specific query type is called WQL (WMI Query Language). Don’t let the name confuse you. It is still very similar to SQL.
Before diving into code, you should know that Windows comes with a tool called WMI Test Tool, which lets you test WQL queries, to check their correctness and returned results. It is a bit harder to track wrong query results in code, so this tool can save some time for the developer. To run it, just start the Run dialog (or the Command Prompt) and type wbemtest.
Once it is started, you will see a window like this:
Click on Connect and you will see a dialog like this:
It lets you connect to a namespace on your local Windows computer. You can use your credentials (although for most queries this is not a requirement) and select the impersonation and authentication levels (once again, for most queries the default settings are acceptable). Once you click connect, you will be able to execute WMI queries, as well as perform other tasks (for example, enumerate classes in a superclass to review its possibilities).
Before creating a query, you need to understand what information you want to obtain. The query is executed against a WMI class – you can read the complete list here. Let’s take the Win32_Processor class as an example here. Querying against this class will give us information about the CPU installed on a machine. If the machine runs with multiple CPUs, a query result will be returned for each one of them.
The Win32_Processor class exposes the following properties:
AddressWidth
Architecture
Availability
Caption
ConfigManagerErrorCode
ConfigManagerUserConfig
CpuStatus
CreationClassName
CurrentClockSpeed
CurrentVoltage
DataWidth
Description
DeviceID
ErrorCleared
ErrorDescription
ExtClock
Family
InstallDate
L2CacheSize
L2CacheSpeed
L3CacheSize
L3CacheSpeed
LastErrorCode
Level
LoadPercentage
Manufacturer
MaxClockSpeed
Name
NumberOfCores
NumberOfLogicalProcessors
OtherFamilyDescription
PNPDeviceID
PowerManagementCapabilities[]
PowerManagementSupported
ProcessorId
ProcessorType
Revision
Role
SocketDesignation
Status
StatusInfo
Stepping
SystemCreationClassName
SystemName
UniqueId
UpgradeMethod
Version
VoltageCaps
Most of these are have self-descriptive names, but if you are ever confused about one of them, you can always refer to the MSDN documentation for the class, that explains each one of them.
Now, let’s try to get the values of the above mentioned properties in your .NET application. In my examples I am using C#, but if you are using another .NET language, you shouldn’t have a problem adapting the code.
First, you need to add a reference to the System.Management and System. Management.Instrumentation namespaces. This is done by right-clicking on References in the Solution Explorer and selecting Add Reference. Then, you can select the above mentioned libraries from the .NET list:
It lets you connect to a namespace on your local Windows computer. You can use your credentials (although for most queries this is not a requirement) and select the impersonation and authentication levels (once again, for most queries the default settings are acceptable). Once you click connect, you will be able to execute WMI queries, as well as perform other tasks (for example, enumerate classes in a superclass to review its possibilities).
Before creating a query, you need to understand what information you want to obtain. The query is executed against a WMI class – you can read the complete list here. Let’s take the Win32_Processor class as an example here. Querying against this class will give us information about the CPU installed on a machine. If the machine runs with multiple CPUs, a query result will be returned for each one of them.
The Win32_Processor class exposes the following properties:
AddressWidth
Architecture
Availability
Caption
ConfigManagerErrorCode
ConfigManagerUserConfig
CpuStatus
CreationClassName
CurrentClockSpeed
CurrentVoltage
DataWidth
Description
DeviceID
ErrorCleared
ErrorDescription
ExtClock
Family
InstallDate
L2CacheSize
L2CacheSpeed
L3CacheSize
L3CacheSpeed
LastErrorCode
Level
LoadPercentage
Manufacturer
MaxClockSpeed
Name
NumberOfCores
NumberOfLogicalProcessors
OtherFamilyDescription
PNPDeviceID
PowerManagementCapabilities[]
PowerManagementSupported
ProcessorId
ProcessorType
Revision
Role
SocketDesignation
Status
StatusInfo
Stepping
SystemCreationClassName
SystemName
UniqueId
UpgradeMethod
Version
VoltageCaps
Most of these are have self-descriptive names, but if you are ever confused about one of them, you can always refer to the MSDN documentation for the class, that explains each one of them.
Now, let’s try to get the values of the above mentioned properties in your .NET application. In my examples I am using C#, but if you are using another .NET language, you shouldn’t have a problem adapting the code.
First, you need to add a reference to the System.Management and System. Management.Instrumentation namespaces. This is done by right-clicking on References in the Solution Explorer and selecting Add Reference. Then, you can select the above mentioned libraries from the .NET list:
Once selected, you need to reference the proper namespaces in your code:using System.Management;
Now, to the actual code. I am going to create a function that can be called from anywhere in the code to simplify this task.void GetCPUInfo()
{
ManagementObjectSearcher searcher = new ManagementObjectSearcher("SELECT * FROM Win32_Processor");
foreach (ManagementObject obj in searcher.Get())
{
if (!(obj == null))
Debug.Print(obj.Properties["CpuStatus"].Value.ToString());
}
}
The ManagementObjectSearcher is the key element here – it gets the returned properties based on the query. The parameter I am passing to it when instantiating is the actual query. As you see, it is very similar to SQL. My current query will retrieve all properties available in Win32_Processor. I iterate through them (note that each result is a ManagementObject – the property holder, in this case will be a separate instance for each CPU that is found) and print in the Output window the value of the CpuStatus property:
The 1 here is exactly what is returned. It is a good practice to consult the documentation before reading specific properties, to understand the possible returned values. 1 for CpuStatus means that the CPU is installed and is active.
Important note: Some of the readers might be curious, why there is a null value verification. Some of the classes require user authentication to get the correct data and some properties are simply not available, being the cause of multiple exceptions, depending on the authentication methods and property types. Therefore, to avoid exceptions, this code security measure is used here.
If only one property is needed to be retrieved, then the query can be organized like this:SELECT CpuStatus FROM Win32_Processor
The important thing to remember here is that when you only retrieve one property, the rest of them are unavailable for that specific query result. Therefore, trying to get their value will cause an exception.
Courtesy: Original source is from Denzel D at - https://dzone.com/articles/how-use-wmi-net-application
Now, to the actual code. I am going to create a function that can be called from anywhere in the code to simplify this task.void GetCPUInfo()
{
ManagementObjectSearcher searcher = new ManagementObjectSearcher("SELECT * FROM Win32_Processor");
foreach (ManagementObject obj in searcher.Get())
{
if (!(obj == null))
Debug.Print(obj.Properties["CpuStatus"].Value.ToString());
}
}
The ManagementObjectSearcher is the key element here – it gets the returned properties based on the query. The parameter I am passing to it when instantiating is the actual query. As you see, it is very similar to SQL. My current query will retrieve all properties available in Win32_Processor. I iterate through them (note that each result is a ManagementObject – the property holder, in this case will be a separate instance for each CPU that is found) and print in the Output window the value of the CpuStatus property:
The 1 here is exactly what is returned. It is a good practice to consult the documentation before reading specific properties, to understand the possible returned values. 1 for CpuStatus means that the CPU is installed and is active.
Important note: Some of the readers might be curious, why there is a null value verification. Some of the classes require user authentication to get the correct data and some properties are simply not available, being the cause of multiple exceptions, depending on the authentication methods and property types. Therefore, to avoid exceptions, this code security measure is used here.
If only one property is needed to be retrieved, then the query can be organized like this:SELECT CpuStatus FROM Win32_Processor
The important thing to remember here is that when you only retrieve one property, the rest of them are unavailable for that specific query result. Therefore, trying to get their value will cause an exception.
Courtesy: Original source is from Denzel D at - https://dzone.com/articles/how-use-wmi-net-application
