Section 10: Parent-Child Processes

The Big Picture: A Family Tree, With a Twist

Every process (after the first few at boot) was started by another process. That makes a family tree: the starter is the parent, the new process is the child. But the Windows family is unusual. The link between parent and child is only a note on a card, not a leash. A child can outlive its parent, and the card can end up pointing to a stranger.

 explorer.exe  (you double-click)
   |
   +-- chrome.exe
   |     +-- chrome.exe  (helper)
   |     +-- chrome.exe  (helper)
   +-- cmd.exe
         +-- ping.exe

10.1 Process Hierarchy

What it is: The hierarchy is the tree formed by "who started whom". Windows stores, in each process's record, the PID of its creator (the parent process ID, PPID, Section 6.5).

A typical tree on a Windows PC:

 System Idle Process (0)   <- placeholder, not a real program
 System (4)                <- the kernel's own threads
   smss.exe                <- first user-mode process (Session Manager)
 wininit.exe               <- starts the core services (parent has exited)
   services.exe            <- the Service Control Manager
     svchost.exe (many)    <- hosts for Windows services
   lsass.exe               <- security and logins
 winlogon.exe              <- the sign-in screen
 explorer.exe              <- your desktop (started during sign-in)
   your apps...

The names of the boot processes (smss.exe, wininit.exe, services.exe) are real, and some boot-time parents (such as smss.exe's helpers) exit early, which leaves orphans, a normal thing on Windows. You do not need to memorize them now. What matters is the idea: everything after boot traces back to something earlier, and your programs mostly descend from explorer.exe (the Windows desktop and File Explorer).

Seeing the tree.

• Task Manager (Processes tab groups related processes under one app entry, which is a rough view of the tree.
• PowerShell: Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name gives the cards. You can follow the numbers to build the tree.
• Sysinternals Process Explorer (free from Microsoft, optional) draws the full indented tree.

An important Windows detail: the link is only a record.

So in Windows, a tree drawn from PPIDs may show a "broken" branch: a child whose parent number matches no running process. That is normal.

10.2 Child Process Creation

What it is: A process creates a child by calling CreateProcess (Section 2.2). There is no fork: Windows never duplicates the parent. The child is built fresh from a program file.

What the parent can decide at creation time:

After CreateProcess returns, the parent may:

1. Wait for the child to finish (a wait function on the process handle, and then read its exit code, Section 3.1). A command prompt does this when you run a program.
2. Carry on without waiting. This is how Explorer launches your app: the app runs on its own.
3. Communicate with it using IPC (Section 9).

In PowerShell: Start-Process notepad returns at once. Start-Process notepad -Wait waits until you close Notepad.

Many modern programs create lots of child processes on purpose: browsers use one process per site or tab-group, so that a crash or a security problem in one page does not affect the others. That is isolation (Section 1.4) used as a design tool.

10.3 Inheritance

What it is: A child starts with some things copied from its parent. Inheritance is why a process you start from a Command Prompt feels like it "belongs" to that prompt.

What is not inherited:

• Memory. The child has a fresh address space. It never sees the parent's variables or heap. (This is the big difference from Linux fork, which copies memory.)
• Threads. The child starts with one new thread.
• Non-inheritable handles, locks and open windows.

 PARENT                               CHILD
 environment copy   ------------->    its own environment copy
 working folder     ------------->    same folder at start
 token (you)        ------------->    same token
 handle 0x20 (inh.) ------------->    handle 0x20
 memory             --- NOT copied    fresh private memory

10.4 Process Groups

What it is: Sometimes you need to treat several related processes as one unit: stop them all together, limit them together, or know when they are all finished. Windows has several ways, which are easy to confuse. The most important for modern Windows is the job object.

Job objects. A job is a kernel object (reached by a handle) that holds a set of processes. Once a process is in a job, any children it starts normally join the same job. The job can enforce rules on the whole group:

          JOB OBJECT "Build task"
 +-------------------------------------+
 |  build.exe                          |
 |    +- compiler.exe                  |
 |    +- linker.exe                    |
 |  Limits: 2 GB memory, kill-on-close |
 +-------------------------------------+
   Close the job -> all three are ended.

Job objects solve a real problem: because Windows does not re-parent or auto-kill children, killing a parent leaves its children running. With a job, you can stop the whole family. Windows itself and tools such as web browsers and build systems use jobs to keep helpers under control.

Console process groups. For console (text window) programs there is a separate meaning of "group": a set of console processes that all receive the same Ctrl+C or Ctrl+Break signal. When you press Ctrl+C in Command Prompt, the signal goes to the group, not just one process. This is a small, older feature that is separate from jobs.

Process trees with taskkill. The command taskkill /PID 1234 /T kills the process and its children ("tree kill"). It finds children through the recorded parent IDs, so it can miss grandchildren whose parent already died, or hit the wrong ones if a PID was reused. A job object is more reliable.

Summary