Section 2: Process Creation

The Big Picture: Opening a New Restaurant

When you double-click an icon, a process is born in a fraction of a second. Behind the scenes it is like opening a new restaurant: find the building plans, rent the land, set up the kitchen, hire the first cook, and finally open the doors. Windows does each of these steps in order.

 You double-click
        |
        v
 [ Find the .exe ] -> [ Make process record ] -> [ Map the file into memory ]
        |
        v
 [ Set up environment ] -> [ Create first thread ] -> [ Code starts running ]

2.1 Application Execution

What it is: Execution means "running". Something must ask Windows to start a program. That something is another process. It is never "magic".

Common ways a program is started:

So every process (except the very first few that Windows creates while booting) has a creator: a parent process (Section 10). Starting a program is always: one process asks the OS to make another.

2.2 CreateProcess API

What it is: An API (Application Programming Interface) is a menu of functions that Windows offers to programs. The main function for starting a process is CreateProcess. (It comes in a few flavours: CreateProcessW, CreateProcessAsUser, and so on.)

What the caller gives it:

What it gives back: a handle to the new process and a handle to its first thread, plus the new PID (Section 5). If it fails (file not found, no permission), it returns an error code.

Windows has no fork. Some other systems (Linux, macOS) make a new process by copying the current one (fork). Windows does not do that. Windows builds a brand-new, empty process and loads the program into it. Because of that, starting a process on Windows is a little heavier than on Linux, which is one reason programs on Windows prefer threads for small jobs.

You can start processes yourself from PowerShell:

Start-Process notepad          # asks Windows to create a Notepad process
Start-Process cmd -ArgumentList "/c echo hi"

2.3 Executable Loading (PE Format)

What it is: Windows .exe files use the PE (Portable Executable) format. It is a file with a known layout, so Windows knows where everything is.

A simplified PE file:

+---------------------------+
| Headers                   |  <- "I am a PE file, I want to start at X,
|                           |      I need these DLLs, I use these sections"
+---------------------------+
| .text    (machine code)   |  <- the instructions
+---------------------------+
| .rdata   (read-only data) |  <- constants, import list
+---------------------------+
| .data    (changing data)  |  <- global variables
+---------------------------+
| .rsrc    (resources)      |  <- icons, menus, version info
+---------------------------+

The headers also hold the entry point (where to start running) and the import table, the list of DLL functions the program needs (Section 8).

The file is not simply copied into RAM. Windows uses memory mapping: it links parts of the file into the process's address space (an image section), and the real data is loaded from disk only when needed (this is paging, Chapter 3). This is why a big program can start quickly.

Windows checks the file first: Is it really a PE? Is it 32-bit or 64-bit? Does it match this PC's CPU type? If not, you get the message "This app can't run on your PC".

2.4 Address Space Allocation

What it is: Windows creates the process's virtual address space (the private bubble from Section 1.4) and sets up its tables. At this point the process has almost nothing in it. Windows then fills in the key parts:

1. The kernel's EPROCESS record and the page tables (the translation maps from Chapter 3).
2. The program image (the .exe), mapped into the space.
3. ntdll.dll, the lowest-level user-mode DLL. Every Windows process gets this one first.
4. Space for the PEB (Process Environment Block), a small data block inside the process that holds the command line, environment pointer, loaded-module list and more. (The kernel's EPROCESS lives in the kernel; the PEB lives in the process's own memory so the process can read it quickly.)

Details of the layout are in Section 4.

2.5 Process Environment Setup

What it is: The new process needs its "surroundings": variables, a starting folder, a command line and an identity. Windows sets these up (Section 6 explains each):

Then the Windows subsystem and the loader do last-minute work in user mode: the loader (inside ntdll) reads the import table, loads each required DLL, and fixes the addresses (Section 8). Windows 10 and 11 also use the first moments for security checks such as ASLR (placing things at random addresses so attackers cannot guess them).

2.6 Initial Thread Creation

What it is: A process cannot run by itself, so Windows creates its first thread (the primary thread), giving it:

• Its own stack (a small notebook for the thread's temporary data, covered in Section 4.3)
• A starting point: not your program's main directly, but a Windows start-up routine that first finishes the setup (loading DLLs, running DLL start-up code) and then calls your program's entry point.
• A starting priority (how urgent it is, Chapter 10).

By default the thread starts running as soon as the process is ready. A parent can ask for it to start suspended (frozen), set things up, and then release it. Debuggers use this trick to catch a program from its very first instruction.

2.7 Execution Starts

What it is: Everything is ready. The scheduler (the part of Windows that hands out CPU time) now sees a new thread that is ready to run and gives it a turn on a CPU core. Your program's own code begins.

The full story, in order:

 1. Parent calls CreateProcess
 2. Windows opens the .exe and checks it is a valid PE
 3. Kernel makes the process record (EPROCESS) and address space
 4. The .exe and ntdll.dll are mapped in
 5. Windows makes the first thread
 6. The new process's loader loads DLLs
 7. DLL start-up code runs
 8. Your program's own entry point runs   <-- "main"
 9. CreateProcess has already returned to the parent
    (the parent is NOT stuck waiting, unless it chooses to)

You can watch a newly created process appear: run Start-Process notepad, then Get-Process notepad. It will show an Id (the PID), the memory used and the number of handles.

Not every program starts quickly. The slow part is usually step 6 and 7 (loading DLLs and reading from disk), not the process record itself.

Summary