Forem: nicoriff

Writing a simple process monitor with WMI and C#

nicoriff — Sat, 02 Jan 2021 19:15:06 +0000

In this article we are going to see how we can create a Windows process monitor using WMI. For this purpose we are going to use ORMi library.

Tradionally, working with WMI to create a tool for this purpose would require that you know WQL and that you have knowledge of how WMI itself works. Using ORMi you can abstract from those requirements and you will find out that this task is extremely easy to accomplish.

First things first. Let's create a Worker Service project:

Second, we have to install ORMi library:

    Install-Package ORMi

The next thing we are going to do is create a model which we can use to create a WMI Watcher and that can match the WMI process creation instance.

    [WMIClass("Win32_ProcessStartTrace")]
    public class Process
    {
        public string ProcessName { get; set; }
        public int ProcessID { get; set; }
    }

Note that we created a model that will match the WMI output for a process creation. For that matter we set the WMIClass attribute on the class declaration. We could also do the same on properties.

Then, we are going to register IWMIWatcher so it can be injected via dependency injection where we need it:

    .ConfigureServices((hostContext, services) =>
    {
        services.AddHostedService<Worker>();
        services.AddSingleton<IWMIWatcher>(new WMIWatcher("root\\CimV2", typeof(Process)));
    });

Now we are going to create the business logic. We are going to do all that in the Worker class. For more complex applications you would use a specific service.

    public class Worker : BackgroundService
    {
        private readonly IWMIWatcher _watcher;

        public Worker(IWMIWatcher watcher)
        {
            _watcher = watcher;
        }

        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            _watcher.WMIEventArrived += _watcher_WMIEventArrived;
        }

        private void _watcher_WMIEventArrived(object sender, WMIEventArgs e)
        {
            Process process = (Process)e.Object;

            Console.WriteLine("New Process: {0} (Pid: {1})", process.ProcessName, process.ProcessID.ToString());
        }
    }

And that's it!. You will probably need administrator privileges when running the application or debbuging in VS so that the Watcher can do it's job.

Conclusion

The best of using ORMi is to use attributes on classes and property names to make ORMi do all the hard work for you. You see that we haven't wrote any line of WQL code on this example. Nevertheless if you want to write your own queries you also can do it. In fact you can also avoid creating a model and you will receive a dynamic object. It's all up to you.

I hope this article is useful!. If any doubts, fell free to contact me!

Worker Service with .NET Core and ORMi

nicoriff — Mon, 18 Nov 2019 22:38:03 +0000

In this article, we are going to write a Worker Service app using ORMi to access WMI and get some information about the system and take some decisions based on results.

Worker Service is a kind of project that started to be available from .NET Core 2.1 but it got boosted in latest .NET Core 3.0 release and now you got the template project just as a separate project and not as an ASP.NET one.
Worker Services are applications that can be run as console apps, or can be hosted as Windows Services or Linux Daemons. That is just great. I´m personally using Worker Services in all my server side and service projects and I can say that it works like a charm so I do not write .NET Framework Windows Services kind of apps any more.

For making this app, you will need Visual Studio 2019 and .NET Core 3.0 installed. Let´s create the project:

For making Worker Services run as a Windows Service you will need some minor tweaks:

You got to install the Microsoft.Extensions.Hosting.WindowsServices library from NuGet:
```
Install-Package Microsoft.Extensions.Hosting.WindowsServices
```

Add the the following line to the CreateHostBuilder method:

.UseWindowsService()

That will tell Windows we want to host this applicacion as a Windows Service. The method should be something like this:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .UseWindowsService()
        .ConfigureServices((hostContext, services) =>
        {
            services.AddHostedService<Worker>();
        });

Now, let´s install ORMi library via NuGet:

    Install-Package ORMi

ORMi is a library I wrote to make WMI work much more easier. It is extremely easy to get WMI information by just declaring your domain model clases and optionally adding some attributes if you want to enhance the experience.

In this article, we are going to make an app to monitor the CPU usage and make some decisions based on the processes that are running on the computer. First, we´ll add a Models folder and put all classes on it. Let´s create the model classes:

    [WMIClass("Win32_PerfRawData_PerfProc_Process")]
    public class Process
    {
        public string Name { get; set; }

        [WMIProperty("IdProcess")]
        public int Pid { get; set; }

        public long PercentProcessorTime { get; set; }

        public long TimeStamp_Sys100NS { get; set; }

        [WMIIgnore]
        public double CpuUsagePercent { get; set; }
    }

Note that we are going to use Win32_PerfRawData_PerfProc_Process to get the CPU usage percent and not Win32_Process class. Then we are going to need to add some logic to finally get the % CPU usage.
There are also some things to note on this class. Some properties got the WMIProperty and some not. This is because we can add the attibute to explicitely tell ORMi which will be the name of that property that has to be mapped on the WMI Class. If there is no attribute set, the ORMi will use the property name. The second thing to note is the WMIIgnore attribute. That attribute is set when we don´t want to map that property to any WMI class property. In this case, CpuUsagePercent will be set later.

Now we are going to create the WMI service class. As all new projects in .NET Core, Worker Service are built so you can easily inject dependencies using Dependency Injection.
Let´s create the interface for the WMI service:

    public interface IWMIService
    {
        Task<List<Processor>> GetAllProcessors();
        Task<List<Process>> GetProcesses();
    }

And now we create the service where we are implementing IWMIService:

    public class WMIService : IWMIService
    {
        private WMIHelper _helper = new WMIHelper("root/CimV2");

        public async Task<List<Processor>> GetAllProcessors()
        {
            List<Processor> res = (await _helper.QueryAsync<Processor>()).ToList();

            return res;
        }

        public async Task<List<Process>> GetProcesses()
        {
            List<Process> res = (await _helper.QueryAsync<Process>()).ToList();

            return res;
        }
    }

Now, to make the dependency injection work we have to register the service and then receive it on the constructor of the Worker class.

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .UseWindowsService()
            .ConfigureServices((hostContext, services) =>
            {
                services.AddSingleton<IWMIService, WMIService>();
                services.AddHostedService<Worker>();
            });

And then on the constructor:

    public Worker(ILogger<Worker> logger, IWMIService wmiService)
    {
        _logger = logger;
        _wmiService = wmiService;
    }

Now, let´s add the logic!. Worker Service got a Worker with an ExecuteAsync method that is looped and executed while the application is alive. That is where we are going to put all the logic.

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                List<Process> processes1 = (await _wmiService.GetProcesses()).Where(p => p.Pid != 0).ToList();
                await Task.Delay(2000);
                List<Process> processes2 = (await _wmiService.GetProcesses()).Where(p => p.Pid != 0).ToList();


                List<Process> highCPUConsumingProccesses = new List<Process>();

                foreach (Process p1 in processes1)
                {
                    Process p2 = processes2.Where(pr => pr.Pid == p1.Pid).SingleOrDefault();

                    int procDiff = (int)(p2.PercentProcessorTime - p1.PercentProcessorTime);
                    int timeDiff = (int)(p2.TimeStamp_Sys100NS - p1.TimeStamp_Sys100NS);

                    double percentUsage = Math.Round(((double)procDiff / (double)timeDiff) * 100, 2);

                    Console.WriteLine($"{p1.Name}: {percentUsage}%");

                    if (percentUsage > 80)
                    {
                        p1.CpuUsagePercent = percentUsage;
                        highCPUConsumingProccesses.Add(p1);
                    }
                }

                if (highCPUConsumingProccesses.Any())
                {
                    SendMail(System.Environment.GetEnvironmentVariable("COMPUTERNAME"), highCPUConsumingProccesses);
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.ToString());
            }

            await Task.Delay(5000, stoppingToken);
        }
    }

As you see, the code is easy to read and all the WMI work is abstracted and solved pretty easy.
There are a few things to note:

The process are filtered with .Where(p => p.Pid != 0) because there were some system projects that had PID 0. No need to have those.
We have to create two lists of Processes so the CPU time can be calculated.
The logic implemented will send an email to the network administrator every minute if there are high CPU consuming procceses. (I´m not sure that´s such a good idea :D). This is just a conceptual example.

Here is a link to the repo.

I hope this article is useful to know a little bit more about both Worker Service and ORMi library.

New .NET library for those who work with WMI. Simpler than ever.

nicoriff — Wed, 02 Jan 2019 15:34:05 +0000

ORMi is a new .NET library I wrote to communicate to WMI (Windows Management Instrumentation). I´ve made several dozens of WMI compatible apps over these years and I always came to the conclusion that the .NET standard libraries are very poor and makes developer write too much code to get simple values. That´s where ORMi stands. To make every WMI work much more easy and to make developers write more readable, easy to understand and mantainable code.
I´ve added several improvements since the first versions of ORMi such as async methods, WMI watcher and WMI method support.

Anyone that has worked with WMI and .NET can tell you that WMI work can be a headache. WMI class names are not the simpler ones and definitvely not the more intuituve. The have tricky and non conventional names. I bet you would never want give that name to a class on your project. That´s one thing that ORMi makes simpler and more intuitive.

Let me show you how it works:

To get the full experience with ORMi it is important to have our model defined and mapped to a WMI Class. Let's suppose that we want to get a list of devices connected to the PC. That is quite simple:

[WMIClass("Win32_PnPEntity")]  
public class Device  
{  
    public string Name { get; set; }  

    public string Description { get; set; }  

    [WMIProperty("Status")]  
    public string StatusName { get; set; }  
}

The above class is enhanced with the use of some attributes. WMIClass tells ORMi what is the name of the WMIClass that Device represents. WMIProperty attribute tells which is the WMI property that will be mapped to that property. ORMi works like this: If there is no attribute, then the member name is used to do the mapping. If an attribute has been set, then the attribute name is used.

Then, with our model properly set we can query WMI to get the instances we want:

static void Main(string[] args)  
{  
    WMIHelper helper = new WMIHelper("root\\CimV2");
    List<Device> devices = helper.Query<Device>().ToList();  
}

This way for example if you only want to search for a mouse device, you can query this way:

List<Device> devices = helper.Query<Device>().Where(p => p.Description.Contains("Mouse")).ToList();

ORMi also supports all of CRUD operations. You can add, modify or delete instances in a quite simple way.

 Person person = new Person
     {
         FirstName = "John",
         Lastname = "Doe",
         DocumentNumber = "9995",
     };
 helper.AddInstance(person);

The class defined in this example is defined this way:

[WMIClass("Lnl_CardHolder")]
public class Person
{
    public string Lastname { get; set; }
    public string FirstName { get; set; }

    [WMIProperty( Name = "SSNO", SearchKey = true)]
    public string DocumentNumber { get; set; }

    [WMIIgnore]
    public int Age { get; set; }
}

All these operations are also supported in async fashion.

You are invited to suggest improvements, fixes and contribute to the project!.

Project Repository and docs: https://github.com/nicoriff/ORMi

You can download via NuGet: https://www.nuget.org/packages/ORMi/