There are many tables permanently updated by the system, which we can search. The complete list is published on MSDN, and you can find this information in the Computer System Hardware Classes section, available at https://msdn.microsoft.com/en-us/library/aa389273(v=vs.85).aspx.

I'll resume some of the most useful terms to search for programmers here:

Each one contains a set of distinct classes, holding a variety of information about the hardware and the software.

For this brief review, we're just going to use the classical WMI and look at the type of data that can be revealed to us in a demo and how to query for it.

Although there are several ways to access this information for the .NET programmer, .NET provides part of the WMI functionality through the System.Management namespace, which is filled with classes to search for system-related information, such as ManagementObjectSearcher, SelectQuery, ManagementObject, and so on.

For a simple query about the system information, we first create a ManagementObjectSearcher object that defines the focus of our search (an information provider). This object should receive a SQL string, indicating the table we want to search for.

So, in our demo, we're going to start by creating a Windows Forms app, including a few buttons and a couple of Listbox controls to present the results.

We'll start by coding a general query to obtain the list of tables available. The code for the button in charge of that is as follows:

ManagementObjectSearchermos = newManagementObjectSearcher
("SELECT * FROM meta_class WHERE __CLASS LIKE 'Win32_%'");
foreach (ManagementObject obj in mos.Get())
listBox1.Items.Add(obj["__CLASS"]);

As you can see, meta_class is a CIM object containing the complete list of classes available for searching. Note that the query might take a while since ManagementObjectSearcher has to go through all the information available in the system and registered in the CIM tables.

You should see output similar to the what is shown in the next screenshot:

Later on, we can query these tables to retrieve the required data. In this demo, we'll use several tables—Win32_OperatingSystem, Win32_processor, Win32_bios, Win32_Environment, and Win32_Share—to find some information about the running machine and related characteristics.

The way it works is always the same: you create ManagementObjectSearcher and iterate over it, invoking the Get()method on every instance of the collection returned by the searcher. So, we have the following code:

private void btnQueryOS_Click(object sender, EventArgs e)
{
    listBox1.Items.Clear();
    listBox2.Items.Clear();

    // First, we get some information about the Operating System:
    // Name, Version, Manufacturer, Computer Name, and Windows Directory
    // We call Get() to retrieve the collection of objects and loop through it
    var osSearch = new ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem");
    listBox1.Items.Add("Operating System Info");
    listBox1.Items.Add("-----------------------------");
    foreach (ManagementObject osInfo in osSearch.Get())
    {
        listBox1.Items.Add("Name: " + osInfo["name"].ToString());
        listBox1.Items.Add("Version: " + osInfo["version"].ToString());
        listBox1.Items.Add("Manufacturer: " + osInfo["manufacturer"].ToString());
        listBox1.Items.Add("Computer name: " + osInfo["csname"].ToString());
        listBox1.Items.Add("Windows Directory: " + osInfo["windowsdirectory"].ToString());
    }

    // Now, some data about the processor and BIOS
    listBox2.Items.Add("Processor Info");
    listBox2.Items.Add("------------------");
    var ProcQuery = new SelectQuery("Win32_processor");
    ManagementObjectSearcher ProcSearch = new ManagementObjectSearcher(ProcQuery);
    foreach (ManagementObject ProcInfo in ProcSearch.Get())
    {
        listBox2.Items.Add("Processor: " + ProcInfo["caption"].ToString());
    }

    listBox2.Items.Add("BIOS Info");
    listBox2.Items.Add("-------------");
    var BiosQuery = new SelectQuery("Win32_bios");
    ManagementObjectSearcher BiosSearch = new ManagementObjectSearcher(BiosQuery);
    foreach (ManagementObject BiosInfo in BiosSearch.Get())
    {
        listBox2.Items.Add("Bios: " + BiosInfo["version"].ToString());
    }

    // An enumeration of Win32_Environment instances
    listBox2.Items.Add("Environment Instances");
    listBox2.Items.Add("-----------------------------");
    var envQuery = new SelectQuery("Win32_Environment");
    ManagementObjectSearcher envInstances = new ManagementObjectSearcher(envQuery);
    foreach (ManagementBaseObject envVar in envInstances.Get())
        listBox2.Items.Add(envVar["Name"] + " -- " + envVar["VariableValue"]);

    // Finally, a list of shared units
    listBox2.Items.Add("Shared Units");
    listBox2.Items.Add("------------------");
    var sharedQuery = new ManagementObjectSearcher("select * from win32_share");
    foreach (ManagementObject share in sharedQuery.Get())
    {
        listBox2.Items.Add("Share = " + share["Name"]);
    }
}

If you run the demo, depending on your machine, you'll get some distinct values, but the structure of the information should be similar to what is shown in the next screenshot:

To summarize, WMI offers a simple, managed way to access practically any relevant data related to the hardware and software on our machine and also in the network to which we are connected (as far as the query has the required permissions).

As for the security concerns, Microsoft has published an exhaustive article on the subject on MSDN: Maintaining WMI Security (https://msdn.microsoft.com/en-us/library/aa392291(v=vs.85).aspx), with all the critical information and guidelines about maintaining security while allowing access to these resources.

There is much more functionality related to the ManagementObject class. For instance, you can get information related to processes or services by creating a new instance of the desired element and use the methods the object inherits.

For example, if you want to know which services are dependent on other services programmatically, you can use the GetRelated method of the object's instance. Let's imagine we want to know which services are related to the LSM (Local Session Manager) service. We could code the following:

var mo = newManagementObject(@"Win32_service='LSM'");
foreach (var o in mo.GetRelated("Win32_Service", "Win32_DependentService",
null,null,"Antecedent","Dependent", false, null))
{
  listBox1.Items.Add(o["__PATH"]);
}

In this way, we can get this (hard-to-find) information in a totally programmatic manner. This will help us configure some scenarios in which one of our application's procedures require the active presence of a certain service (remember that we can launch a service from code as well).

Besides this, other actions are available, such as stopping, pausing, or resuming a given service. In the case of the LSM service, we should see information similar to what is shown in this screenshot:

And there is much more information that you will discover going through the class hierarchy related to System.Management. Practically every byte of system-related data that we should otherwise read via Registry or Windows APIs is available here in a totally programmatic fashion with no need for complex approaches.

The only caveat is that the documentation is very long. Consequently, Microsoft created a tool called WMI Code Creator, which analyzes the information available and generates code for all possible scenarios (often, this code is expressed in Windows Scripting Host), but a big part is perfectly translatable to C#.

Besides, we have the advantage of a tool that joins much of the functionality available in a single user interface.

You can download it from https://www.microsoft.com/en-gb/download/details.aspx%3Fid%3D8572, getting a ZIP file that contains the executable and the source code, which is a valuable tip for coding in WMI.

The tool includes several options:

As you can see in the next screenshot, this tool is quite complete in possibilities and in the information it provides:

Another typical usage of WMI is to check the state of a piece of hardware before performing an action that could provoke a system's failure, such as testing a hard drive before copying big chunks of data that could exceed the disk quota.

The code, in this case, is simple, and it gives us an idea about how to code other system-related queries. All we need is something like this:

ManagementObject disk = new
ManagementObject("win32_logicaldisk.deviceid='c:'");
disk.Get();
var totalMb = long.Parse(disk["Size"].ToString()) / (1024 * 1024);
var freeMb = long.Parse(disk["FreeSpace"].ToString()) / (1024 * 1024);
listBox1.Items.Add("Logical Disk Size = " + totalMb + " Mb.");
listBox1.Items.Add("Logical Disk FreeSpace = " + freeMb + " Mb.");

Thus, after adding a new button and including the previous code to check the state of the C: drive, we should see output similar to this:

To summarize, we've seen several ways of interacting with the operating system. We can analyze which messages are linked to a certain functionality and capture the related events to either change, cancel, or modify the default behaviors. In this case, the communication is in both directions.

This also happens (bi-directional communications) when we use the system APIs to call functionalities through Platform/Invoke, which offers unlimited possibilities.

Finally, Windows Management Instrumentation and its variant MI provide access to otherwise difficult-to-reach information, allowing our applications to configure and behave more suitably depending on the operating system's state.