I have a client that has a few Windows Services and some EXEs that run on a computer to perform various business functions. Every once in a while, the processes fail and need to be restarted. I helped the client write a Windows Service to monitor their running processes and ensure that they are up and running and to notify them and to attempt to restart those processes. As part of this process, I had to write a class to get a list of all of the processes running on the current computer or on another computer on their network.

Read All Processes

To read all processes running on a computer, use the .NET Process class located in the System.Diagnostics namespace. The GetProcesses method returns a string array of Process objects from the current (or a remote) computer. From this Process object, you can retrieve information about the process (Figure 1) such as its unique ID, its name, whether or not it is running, and how much memory that process is consuming.

Figure 1: This WPF list box display a list of processes running on the current computer
Create a process class in order to add additional information about processes such as memory displayed in KB and MB.

You can pass a computer name to the GetProcesses method to have it attempt to read the processes running on that remote computer. You must have the appropriate network/computer permissions to read the processes on the other computer or this call will fail. Certain properties for the remote process cannot be filled in because they cannot be retrieved remotely.

The code in Listing 1 is what fills in the process information on the XAML screen shown in Figure 1. A Process array is initialized as a variable named List. Another variable, machineName, is used to hold the computer’s name that is entered into the text box on the form. A call to the GetProcesses method, with or without the computer name, returns the array of Process objects into the List variable. This string array is placed into the DataContext property of the ListView control to display all the properties from each Process object.

Create a Custom Process Class

There are a couple of things missing from the .NET Process class that you will probably want to add. First, the MachineName property is filled in with a period (.) when you are running on the current computer. You probably want this to be filled in with the current computer’s name. Another important property is whether or not this Process object was retrieved from a remote computer. A useful set of properties is the amount of memory used, expressed in both kilobytes and megabytes. All of these properties are easy to add by creating your own process class.

In order to work more effectively with a collection of processes, create a couple of new classes for your process listing service that can add additional properties and functionality. I have called mine PDSAProcess and PDSAProcessBase, but feel free to name them what you want. The PDSAProcess class inherits from the PDSAProcessBase class. The Base class implements the INotifyPropertyChanged event and adds two properties called LastMessage and LastException. These two properties can be used to keep track of the last display or error message and the last exception object when you are loading your process objects. You can look at the sample source code that comes with this article to see the implementation of the PDSAProcessBase class.

NOTE: Using INotifyPropertyChanged in XAML applications is a well-known design pattern and there are many articles on the subject, so I won’t cover it here.

Listing 2 shows the PDSAProcess class but with some of the normal property get/set methods not fully documented because they are all the same. You will see the full code for those properties that have special code in Listing 2. Notice the MachineName “property set” procedure calls the SetMachineName method. Also note the calculations for the MemoryInKb and MemoryInMb properties. The end result of creating the PDSAProcess class is shown in Figure 2. As you can see, there is better information displayed in the ListView control and the data displayed is sorted by the process name.

Figure 2: A custom process class allows you to add additional properties.

The PDSAProcess class also has many of the same properties as the .NET Process class, but the properties in this class raise the property changed event for use with XAML applications. Notice that the MachineName property shown in Figure 2 displays the current computer name rather than the period (.) that is reported by the .NET Process class. In the Set procedure of the MachineName property, a private method called SetMachineName is called to set the current computer name and to set the IsRemote property at the same time.

To load the custom process collection shown in Figure 2, click on the Load All Processes button shown on the form. The button’s Click event procedure fires and runs the code shown in the following code snippet:

private void btnLoad_Click(object sender, RoutedEventArgs e)
  if (string.IsNullOrEmpty(txtMachineName.Text))
    lstProcesses.DataContext =
    lstProcesses.DataContext =

Check the text box to see if the user entered a computer name or not. If they have entered one, pass in the computer name to a method called LoadAllProcesses. If there is no computer name in the text box, pass in an empty string to the LoadAllProcesses method. Listing 3 shows the code to load the processes from the .NET Process object into a PDSAProcess object and then into an ObservableCollection of those PDSAProcess objects.

The code in the LoadAllProcesses method is fairly straight-forward. You are primarily moving the properties from the .NET Process class into the corresponding properties in the PDSAProcess class. The PDSAProcess class takes care of filling in the real computer name, and setting whether or not the computer is remote Be careful accessing the IsResponding property on the .NET Process class because it is not available on remote Process objects. In fact, if you try to access this property, an exception is thrown. That is why you see an “if” statement surrounding the code that attempts to access the IsResponding property.

The .NET GetProcesses method does not return the processes in any sort of order. Most users like to see sorted data, so it is probably a good idea to sort your process collection by the process name. Toward the bottom of Listing 3, you can see the following code snippet:

ProcessList = new ObservableCollection<PDSAProcess>
     (ProcessList.OrderBy(p => p.ProcessName));

This line of code uses the OrderBy method of the ObservableCollection class to create a new ObservableCollection of PDSAProcess objects. You pass a lambda expression (p => p.ProcessName) that informs the OrderBy method the name of the property by which to sort the collection.

The use of lambda expressions for ordering a collection turns what would otherwise be multiple lines of code into one.

A Process Manager Class

Instead of writing the code to load a ListView or other list-type of control, you might want to move the code you just wrote in the XAML window to a method in a class. Create a “Manager” class with the appropriate method to manage the process of creating a collection of process objects.

In preparation for creating a Manager class, move the IsRemote and MachineName properties from the PDSAProcess class into the PDSAProcessBase class. Move the SetMachineName method into the PDSAProcessBase class as well, because the set property of the MachineName property relies on this method. The Manager class you are going to write needs these two properties IsRemote and MachineName, so you might as well take advantage of inheritance by placing them into the Base class. The following code snippet shows the declaration for your new process manager class.

public class PDSAProcessManager : PDSAProcessBase

In this new process Manager class, you are going to add a method to retrieve memory instead of merely accessing the WorkingSet64 property of the .NET Process class. The WorkingSet64 property does not report the same amount of memory as the Task Manager utility and it can sometimes be confusing if you are looking at Task Manager, and then at your program, and you see different memory values. The method you are going to write will use a PerformanceCounter object in .NET to get the same value reported by Task Manager. The basics of how to retrieve memory using a performance counter is coded like this:

PerformanceCounter pc = null;
long ret = -1;
pc = new PerformanceCounter("Process",
            "Working Set - Private", prc.ProcessName);
if(pc != null)
  ret = pc.RawValue;

Although the above code works, you may also need to pass in a computer name to the constructor of the PerformanceCounter if you are accessing a remote computer. Be aware that in order to access a performance counter on another computer, you need to either be a member of the Performance Monitor Users group or have administrative privileges on that computer.

Within the new PDSAProcessManager class, add a constant called PERF_COUNTER_MEMORY that holds the name of the performance counter you use. Add an ObservableCollection of PDSAProcess classes to hold the list of PDSAProcess objects as well. These two items are shown in the following code snippet:

private const string PERF_COUNTER_MEMORY =
  "Working Set - Private";
private ObservableCollection<PDSAProcess> _ProcessList
 = new ObservableCollection<PDSAProcess>();
public ObservableCollection<PDSAProcess> ProcessList
  get { return _ProcessList; }
    _ProcessList = value;

You are now ready to write the LoadAllProcesses method in your process Manager class. Listing 4 shows the complete LoadAllProcesses method. As you will notice when you read the code, there are a few differences from the method you wrote earlier in this article.

The first difference is that you are using LINQ to create a collection of PDSAProcess objects. LINQ simplifies the process of creating a collection and is more concise than looping through the string array of .NET Process objects. However, if you like using a loop, you can modify this code to use the loop like you did in Listing 3. The second difference is the call to set the Memory property on the PDSAProcess object by calling a method named GetMemory.

Use LINQ to iterate to build your collection of process objects makes your code more readable and succinct.

The GetMemory method is where you attempt to get the PerformanceCounter object from either the local or the remote computer. You need to wrap up the creation of the PerformanceCounter object into a try…catch block in case you can’t access the performance counter for one of the reasons stated above. Also notice that you need a finally block when accessing a performance counter, in order to close and dispose of the performance counter object properly. You can wrap this call into a using block if you prefer. If, for some reason, you can’t access the performance counter to get the memory and you still want to have a valid memory value, and if the memory value is not set, get the WorkingSet64 property on the .NET Process object to set the return value from this method.

Now that you have this process Manager class written, you can use it as a view model on your WPF Window. (Some of the XAML has been removed in the code snippet below because it was not important to show it.) You create an XML namespace to reference the .NET namespace that the PDSAProcessManager is contained within. In the Window.Resources section of the XAML, create an instance of the PDSAProcessManager class and assign it a key of “viewModel”. Bind the ItemsSource property of the ListView to the ProcessList property in the PDSAProcessManager class. This is the collection of process objects retrieved when you call the LoadAllProcesses method. Finally, you bind each of the GridViewColumn objects in the ListView to each property of the PDSAProcess class that you wish to display.

<Window x:Class="ProcessSample.MainWindow"
    <vm:PDSAProcessManager x:Key="viewModel" />
  <ListView ItemsSource="{Binding Path=ProcessList}">
        DisplayMemberBinding="{Binding Path=Id}" />
        DisplayMemberBinding="{Binding Path=ProcessName}" />

To load the process collection into the ProcessList property, call the LoadAllProcesses method when the user clicks on the Load All Processes button shown in Figure 2. The MachineName property of the PDSAProcessManager class is bound to the TextBox shown on Figure 2. In the constructor of this main window, you bind the instance of the view model class created in the XAML to a variable called _ViewModel. Call the LoadAllProcesses method, as shown in the following code snippet:

public partial class MainWindow : Window {
  PDSAProcessManager _ViewModel = null;
  public MainWindow() {
    _ViewModel =
  private void btnLoad_Click(object sender, RoutedEventArgs e)

The LoadAllProcesses method retrieves all the processes on the specified computer, builds the collection class, sorts the collection class, and sets the ProcessList property. As the ProcessList property is an ObservableCollection, any bindings to it are automatically updated when the collection changes. Thus, the ListView control is refreshed once it is set in the LoadAllProcesses method.


In this article, you learned how to read the list of processes running on the current computer or a remote computer using the .NET Process class. Create your own process class so that you can add additional properties and functionality that is not available with the .NET Process class. One feature you might want to add includes returning the amount of memory in both kilobytes and megabytes. Also, whether or not the process was read from a remote computer is very useful. Setting the computer name is more readable than displaying a period (.) as the .NET Process class does. Sorting the data using an ObservableCollection makes the display of the data easier for the user. Finally, wrapping the loading of process classes into a Manager class makes creating a list of processes quick and easy.