What Windows Runs: Processes & Services
What is it?
A process is a running program: when you launch an app, Windows loads its code into memory and gives it a process with its own ID (PID), its own memory, and the account it runs as. Processes are created BY other processes, so they form a tree — each process has a parent that started it. A service is a special kind of process that runs in the background without a user logged on (print spooling, updates, the event log itself), started and supervised by Windows rather than by a person double-clicking.
Why it matters
Everything a Windows machine does is a process. Being able to picture what is running, who started it, and under which account is the foundation of administration (is the right thing running?), troubleshooting (which process is stuck?) and security (is this process where it should be?). The parent-child relationship is often the single most revealing fact about a program.
Where you see it
In Task Manager and the Services console, and — the way administrators actually read them — in the process list and service list returned from the command line and PowerShell (which Unit 2 covers).
What normal looks like
Interactive apps descending from the user's shell (explorer.exe), system processes and services running as SYSTEM or dedicated service accounts, and a sensible tree — a word processor under explorer, a service under the service host, each in its expected location.
What suspicious looks like
For troubleshooting/security: a process with an unexpected parent (a browser spawning a command shell), a service running from a user folder instead of a system path, a program consuming resources with no window, or a familiar name in the wrong place. The relationship, not just the name, is the tell.
How analysts investigate
By reading a process by four facts together: its name, its PID, the account it runs as, and its parent. A program is 'normal' when all four fit its expected pattern; a mismatch on any one is the thread to pull. Services add: what account, from what path, and what starts them.
Common beginner mistakes
- Judging a process by its name alone. A trustworthy name in the wrong location, under the wrong account, or with the wrong parent is exactly how bad things hide — the context matters more than the label.
- Thinking everything running must have a visible window. Services and background processes do the majority of the work with no window at all — invisible is normal, not suspicious by itself.
Turn on an Aldar Industries workstation, WS-041, and before anyone logs in it is already busy: dozens of processes are running. Some are the operating system itself; many are services doing background work. When a.hakim logs in and opens a browser and a spreadsheet, those become processes too — each started by another process, each running as a particular account. Learning to read this is the first skill of Windows: not memorizing names, but seeing what is running, who started it, and as whom.
PROCESS TREE on WS-041 (name PID runs-as <- parent)
System / services
services.exe 664 SYSTEM
svchost.exe 1120 SYSTEM (hosts many Windows services)
Spooler - SYSTEM (print spooler service)
Interactive session (a.hakim logged on)
explorer.exe 4210 ALDAR\a.hakim (the desktop shell)
msedge.exe 5588 ALDAR\a.hakim <- explorer (user opened a browser)
excel.exe 6012 ALDAR\a.hakim <- explorer (user opened a spreadsheet)
Read each process by 4 facts: name + PID + account + parent.The key distinction is interactive program versus service. An interactive program is started by a logged-on user and usually has a window — it descends from explorer.exe, the desktop shell, and runs as that user. A service is started by Windows itself, runs in the background with no window, and often runs as a system account (SYSTEM) or a dedicated service account so it can work even when nobody is logged on. Many Windows services are hosted inside svchost.exe processes rather than each having its own executable. Both are just processes — the difference is who starts them, whether a user is present, and the account they run under.
Reading two processes with the same name
On WS-041 you see two processes both named svchost.exe. Process P1: PID 1120, runs as SYSTEM, parent services.exe, image path C:\Windows\System32\svchost.exe. Process P2: PID 7744, runs as ALDAR\a.hakim, parent msedge.exe, image path C:\Users\a.hakim\Downloads\svchost.exe. Which is normal, and why?
Read P1 by its four facts.
P1: name svchost.exe, running as SYSTEM, parent services.exe, from C:\Windows\System32. That is exactly the textbook pattern — the real svchost is a Windows service host, started by services.exe, running as SYSTEM, living in System32. All four facts agree, so P1 is normal. A beginner who only saw 'svchost.exe' could not tell it apart from P2; the context is what confirms it.
Read P2 the same way and compare.
P2: same name, but running as a normal user (a.hakim), parent msedge.exe (a browser), from C:\Users\a.hakim\Downloads. Every one of those is wrong for svchost: the real service host never runs as an ordinary user, is never a child of a browser, and never lives in a Downloads folder. The name was borrowed to look innocent; the context exposes it. This is the exact mistake the lesson warns against — trusting the label.
State the conclusion from the relationships.
Conclusion: P1 is the legitimate Windows service host; P2 is a suspicious impostor to investigate — a browser-download running under a user, masquerading as svchost. Note what decided it: not the name (identical) but the account, the parent and the path. Reading a process by all four facts is the whole skill, and it applies to administration and security alike.
Quick check
What is the relationship between processes that makes a 'process tree'?
A quick self-check — it doesn't affect your XP or progress.
Quick check
How does a service differ from an ordinary interactive program?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.