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.
Select any process in the tree to reveal its full forensic profile and baseline.
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.
winload.efi, and the kernel (ntoskrnl.exe) — right up to the moment it hands control to smss.exe, the first process below.
Every core Windows process, with the shape it should have on a healthy machine. Read the columns like this. PID is the process identifier Windows assigns at creation; only the few listed as fixed are ever the same number twice. Parent is the process that created it — the single most useful column here, because a correct name under the wrong parent is the classic masquerade. Account is the security context it runs as. Prio is its base scheduling priority, which matters because a system process running at a user priority, or the reverse, is out of place. Session separates services from interactive logons: session 0 is the isolated service session, session 1 and above are logged-on users, so a user-facing process in session 0 deserves a second look. Instances is how many copies should be running at once, and Timing is when in the boot sequence it normally appears — a process that starts far later than it should did not start the way it usually does.
| Process | PID | Parent | Account | Prio | Session | Instances | Timing |
|---|
| Indicator | Why It Matters |
|---|---|
| Wrong path | Core 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 name | scvhost.exe, csrsss.exe, lsas.exe — typosquatting the trusted name. |
| Wrong parent | e.g. svchost.exe not under services.exe, or lsass.exe not under wininit.exe. |
| Wrong / missing args | Every svchost.exe has a -k group; every legit dllhost.exe has a /Processid:{GUID}. Missing = suspect. |
| Wrong account | explorer.exe running as SYSTEM, or a SYSTEM process running as a user, breaks the model. |
| Too many instances | There is exactly one lsass.exe, services.exe, wininit.exe. A second copy is a strong alert. |
| Suspect children | lsass/spoolsv/wmiprvse spawning cmd/powershell = injection, PrintNightmare, or WMI lateral movement. |
| Process | Evolution |
|---|---|
| taskhost | taskhost.exe (Win7) → taskhostex.exe (Win8) → taskhostw.exe (Win10+). |
| taskeng | Win7/2008R2 scheduled-task engine → replaced by taskhostw.exe + Schedule svchost (Win8+). |
| lsm | lsm.exe (Win7) → merged into lsm.dll hosted by svchost.exe (Win8+). Seeing the EXE on a modern build is anomalous. |
| lsaiso | Only present when Credential Guard is enabled; isolates LSA secrets via virtualization-based security. |
| Registry / Secure System | Minimal processes added in Win10 (1803) for hive storage and VBS/VTL1 isolation respectively. |
| conhost | Introduced in Win7 to host console windows; child of the console-owning app, tied to csrss.exe. |
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.
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-EyeKnowing normal is what makes an anomaly visible, and it is also what makes the anomaly easy to over-read. Three claims a process tree does not carry:
A Word document spawning cmd.exe is worth investigating; it is not proof of
compromise. Legitimate software does strange-looking things — installers re-parent
their children, management agents launch shells, and a crashed parent leaves its child
orphaned under whatever adopts it. The tree tells you where to look. What actually ran, and
with what command line, is the evidence.
Task Manager and its equivalents show what is running now. An intrusion's most important processes ran and exited before anyone looked, leaving no row at all. The tree is a baseline for recognising what is wrong in the present, not a record of the past — that comes from process-creation events, Prefetch and the registry's execution keys.
Instance counts, session numbers and even parentage move between Windows versions, between a workstation and a domain controller, and with whatever endpoint agent is deployed. The reference here is a starting point, not a fingerprint. The baseline that matters is the one taken from healthy machines in the same estate.
What it is genuinely good for: making masquerading visible at a glance. A process named correctly but running from the wrong path, under the wrong account, in the wrong session or under the wrong parent is the single most reliable cheap signal on a live host — and none of the four requires a tool, a signature or an alert to notice.
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.
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.
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.
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.