One of the most useful troubleshooting skills one can get is understanding what processes are and how they function. It’s not that you need to know exactly how applications use processes, but rather what their general meaning is and how they interact with the system. Let’s go over the basics: an application consists of one or more processes to function, a process has many characteristics such as a virtual address space, executable code, process identifier, etc.

Let’s use Microsoft Outlook as an example. The application name is Microsoft Outlook, the process for that application is Outlook.exe. When you start the application the process is the one that interacts with the system, the process alone does not do all the work as it relies on threads to complete the various functions. As you can imagine an application such as Microsoft Outlook has many multiple functions, you may be typing an email, the system may be updating the inbox in the background, the calendar is keeping track of appointments, etc., all that happening at the same time. Threads execute any part of the process code.

Application ——> Process ———> Threads

In the example below you see the processes running, notice that there’s a process called OUTLOOK.EXE, that process in turn is being executed by many threads.

Below is a snapshot of the threads running OUTLOOK.EXE process, as you can see each thread has a unique identifier (TID) and individually request the CPU’s attention to carry out its function within its memory space.

Knowing how to trace back an application to its process and vice versa is a tremendous help when working on a compromised system. A high level of security may require baselining all processes so, in the event of a security breach, you can compare your running processes with the baseline.