Eye Describe Anatomy

Windows Process Genealogy

The master forensic reference for the Windows process tree — the legitimate boot-time parent/child hierarchy plus the most-investigated service and COM hosts. Every node carries its expected path, parent, account, session, command line, code-signer, MITRE ATT&CK abuse, corroborating artifacts, and the “Know Normal, Find Evil” baseline. Click any node to dissect it.

Kernel / System
Session Manager
Session 0 — Services & Security
Session 1 — Interactive User
Special / Hosted
Process Dissection

Select any process in the tree to reveal its full forensic profile and baseline.

From PID 4 to the Desktop

Windows builds itself in a strict, repeatable order. The kernel starts as System (PID 4), which launches the Session Manager smss.exe. smss.exe bootstraps two worlds: Session 0 (the non-interactive OS services) via wininit.exe, and Session 1 (the interactive user) via winlogon.exe. A separate csrss.exe is spun up for each session.

Because smss.exe copies itself into each new session and that copy then exits, the processes it creates — csrss.exe, wininit.exe, winlogon.exe — normally appear with no living parent. The same is true of explorer.exe, whose parent userinit.exe exits as soon as the shell is up. These "orphans" are normal; knowing this is the whole point of the baseline.

This is the foundation of "Know Normal, Find Evil." Every node below carries its expected path, account, parent, command line, code-signer, instance count, and the anomalies that betray a malicious imposter — a wrong path, a misspelled name, a missing -k switch, the wrong parent, or one-too-many copies.

Where does PID 4 come from? This tree begins where the boot relay ends. The Windows Booting Masterclass walks the full path — power-on, POST, UEFI, the boot manager, winload.efi, and the kernel (ntoskrnl.exe) — right up to the moment it hands control to smss.exe, the first process below.
Read: The Booting Process

Full Process Reference

Process PID Parent Account Prio Session Instances Timing

Masquerading Red Flags

IndicatorWhy It Matters
Wrong pathCore processes run from C:\Windows\System32 (explorer.exe from C:\Windows, WmiPrvSE.exe from System32\wbem). A copy in a user/temp folder is malware.
Misspelled namescvhost.exe, csrsss.exe, lsas.exe — typosquatting the trusted name.
Wrong parente.g. svchost.exe not under services.exe, or lsass.exe not under wininit.exe.
Wrong / missing argsEvery svchost.exe has a -k group; every legit dllhost.exe has a /Processid:{GUID}. Missing = suspect.
Wrong accountexplorer.exe running as SYSTEM, or a SYSTEM process running as a user, breaks the model.
Too many instancesThere is exactly one lsass.exe, services.exe, wininit.exe. A second copy is a strong alert.
Suspect childrenlsass/spoolsv/wmiprvse spawning cmd/powershell = injection, PrintNightmare, or WMI lateral movement.

Naming Across Versions

ProcessEvolution
taskhosttaskhost.exe (Win7) → taskhostex.exe (Win8) → taskhostw.exe (Win10+).
taskengWin7/2008R2 scheduled-task engine → replaced by taskhostw.exe + Schedule svchost (Win8+).
lsmlsm.exe (Win7) → merged into lsm.dll hosted by svchost.exe (Win8+). Seeing the EXE on a modern build is anomalous.
lsaisoOnly present when Credential Guard is enabled; isolates LSA secrets via virtualization-based security.
Registry / Secure SystemMinimal processes added in Win10 (1803) for hive storage and VBS/VTL1 isolation respectively.
conhostIntroduced in Win7 to host console windows; child of the console-owning app, tied to csrss.exe.

Sources & Methodology

PIDs, command lines, and exact behaviour vary by Windows build, edition, and configuration. Only System Idle Process (PID 0) and System (PID 4) have fixed PIDs; all others are shown as Dynamic. Command lines are representative of a default install. Always validate against the host under investigation.

From reading to doing

Trace process activity with Crow-Eye

Crow-Eye treats each process as an identity and pulls its traces together across your evidence — SRUM resource usage, event logs, the registry, services and scheduled tasks — correlating a binary's path, the user it ran as, its network and resource usage, and execution times onto one timeline, so you can apply this baseline yourself instead of pivoting between artifacts by hand.

Download Crow-Eye

Frequently Asked Questions

What should a normal Windows process tree look like?

Core processes have expected parents, paths, accounts and instance counts - for example a single lsass.exe launched from System32 under SYSTEM. Knowing the normal shape is what makes an anomaly visible; there is nothing suspicious about a process until you know what it should have looked like.

Why is process parentage a useful signal?

Because malware frequently gets it wrong. A system binary running from the wrong directory, under the wrong account, or spawned by a parent that should never launch it, stands out against the baseline even when the binary name looks entirely legitimate.

How many instances of svchost.exe are normal?

Many, and that is expected - svchost hosts grouped services. What matters is not the count but the parent, the path and the service group each instance is hosting, since a lone svchost with the wrong parent is a very different thing from the usual set.

Can I check the process tree after the fact?

Not directly, but the artifacts left behind carry much of it. Process creation events, Prefetch and the Registry's execution keys let you reconstruct what ran and, in many cases, what launched it, long after the machine was powered down.