FFoundationalGeneral
Processes and threads are the basic units of execution on every Windows machine. This lesson explains what they are, how the parent-child relationships between them work, and why this mental model underpins almost everything you will later say about detection, persistence, and attack analysis.
Almost every meaningful event on a Windows machine is a process doing something. When a defender investigates an alert, an attacker establishes persistence, or an analyst reconstructs what happened during an incident, they are reasoning about processes and the relationships between them. If you cannot describe a process clearly, you cannot explain most of what happens on Windows.
This is foundational vocabulary. Concepts you will meet later, process injection, parent-process spoofing, living-off-the-land binaries, suspicious process trees, all assume you already know what a process and a thread are, and how one process comes to start another. Getting this right early makes every downstream explanation sharper and more credible.
A process is what a program becomes once Windows loads it into memory and gives it the resources to run: its own address space, open handles, and security context. A thread is a single stream of execution working inside that process. Put plainly, the program is the instructions sitting on disk, the process is the live environment those instructions get loaded into, and the thread is the activity actually carrying them out. One process can run many threads at the same time, all sharing that process's memory and security context.
The second half of the idea is lineage. When one process starts another, the starter is the parent and the new process is the child. This relationship is what lets you read a system as a tree rather than a flat list. A web browser launching a calculator is unremarkable; a document viewer launching a command shell is the kind of parent-child pairing that makes an analyst stop and look closer.
A clean way to carry this into an interview is to picture a kitchen. The program is a recipe written on a card; the process is the kitchen set up and stocked to actually cook it; and each thread is a cook working in that kitchen. The recipe does nothing on its own; it only comes alive once a kitchen is built around it. Several cooks can then work side by side, sharing the same counters and ingredients, the way many threads run inside one process and share its memory. The process is where the work happens; the thread is the work happening.
For lineage, think of a family tree. If one process opens another, it becomes the parent of that child, and the two stay related only while both are alive; kill the parent and the relationship simply ends. Windows tags every process with a Process Identifier, a PID, the way each person in a building gets a badge number, so you can point to exactly one process when you need to inspect or stop it. There is also a deeper floor to the building you rarely visit directly: kernel mode, where trusted operating-system code talks to the hardware. Almost everything you will analyze lives upstairs in user mode.
Common misunderstandings
On a live Windows machine, hundreds of processes run at once, and most of them are ordinary system housekeeping. Defenders learn the normal shape of the process tree so anomalies jump out: a known system process running from the wrong folder, an office application spawning a scripting engine, or a child process whose parent makes no sense. The everyday tools for this are simple, tasklist lists running processes with their PIDs, and taskkill ends one by PID or by name, and the same information appears in Task Manager and Sysinternals' Process Explorer.
C:\>tasklist
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
System 4 Services 0 136 K
smss.exe 428 Services 0 1,200 K
csrss.exe 628 Services 0 5,576 K
winlogon.exe 888 Console 1 12,120 K
lsass.exe 968 Services 0 22,064 KWhen you explain a finding to a client, this vocabulary is what makes the story land. Saying "the malware ran" is vague; saying "a malicious document spawned a child PowerShell process, which then launched a network connection" gives a stakeholder a concrete, defensible picture. The clarity of your explanation depends on the clarity of your process model.
Interview answer
On Windows, a process is what a program turns into once it's loaded into memory and given resources to run (it owns the memory and the security context), and a thread is a single line of execution working inside that process. One process can run many threads at once, and they all share the process's resources. Each process gets a numeric Process Identifier, or PID, so the system can reference and manage it.
The part that matters most for security work is lineage. When one process starts another, the first is the parent and the second is the child. That relationship lets you read a machine as a process tree instead of a flat list, which is how defenders spot anomalies, like an office document spawning a command shell. Almost everything I'd later analyze, from process injection to suspicious child processes, builds directly on this model.