Section 5: Process IDs and Handles

The Big Picture: Name Tags and Coat-Check Tickets

A busy PC has hundreds of processes. Windows needs two things to keep them straight:

1. A name tag for every process: the PID. Anyone can read it.
2. A coat-check ticket for every object a process has opened: the handle. Only the owner can use it.

 PID    = "Process number 4812"        (one number, same for everybody)
 HANDLE = "Ticket 0x1A4 in MY pocket"  (a ticket that only works for me)

5.1 PID (Process ID)

What it is: The PID (Process ID) is a whole number that Windows gives each process when it is created. It identifies the process while it exists.

Facts:

Where to see them:

• Task Manager: Details tab shows the PID column by default.
• Command Prompt: tasklist lists each image name and PID.
• PowerShell: Get-Process shows the Id column.

Get-Process notepad | Select-Object Name, Id
tasklist /FI "IMAGENAME eq notepad.exe"

Do not trust a PID forever. Because numbers are reused, a program that remembers "process 4812" and tries to act on it much later might hit a different program. That is why Windows keeps a PID reserved while anyone still has a handle to the old process (Section 3.5), and why tools that must be careful use handles, not bare PIDs.

You use a PID in commands such as taskkill /PID 4812 or Stop-Process -Id 4812. Under the hood, a program calls OpenProcess with the PID and asks for access rights; Windows checks the rights and, if allowed, returns a handle.

5.2 Handles (Not the Same as Memory Addresses)

What it is: A handle is a small number that a process uses to refer to something the kernel owns: a file, a thread, another process, a registry key, an event, a window, and more. These things are called kernel objects.

Why not give the program the object's real memory address? Because:

• The object lives in kernel memory, which programs must never touch directly.
• If the program had a raw address it could damage the object or find other people's data.
• Windows can move or check the object safely if it only deals in tickets.

Every handle comes with access rights chosen when it was created: "read only", "read and write", "may terminate the process", and so on. The kernel checks them on each use.

Handles you create stay open until you close them (CloseHandle). A program that opens things and never closes them has a handle leak: the count in Task Manager grows. Windows closes them all when the process exits (Section 3.4).

5.3 Handle Table (Per-Process)

What it is: The kernel keeps, for each process, a handle table: a list that turns each handle number into a pointer to the real kernel object. It is stored in the process's kernel record (the EPROCESS from Section 1.1).

 PROCESS A's handle table                 KERNEL OBJECTS
 +--------+------------------------+      +-----------------------+
 | 0x04   | -> File: report.docx   |  --> | File: report.docx     |
 | 0x08   | -> Event "DataReady"   |  --> | Event "DataReady"     |
 +--------+------------------------+      +-----------------------+
                                                    ^
 PROCESS B's handle table                           | same object,
 +--------+------------------------+                | different ticket
 | 0x04   | -> File: photo.png     |                |
 | 0x10   | -> Event "DataReady"   |  --------------+
 +--------+------------------------+

Notice:

1. Handle 0x04 means different things in A and B (a different file in each). Each process has its own table.
2. Two processes can hold handles to the same object (here the event). That is how sharing works safely: both tickets lead to one object.
3. Kernel objects have a reference count: the object is only freed after the last handle to it is closed.

Seeing it: Task Manager's Details tab has a Handles column (right-click header, Select columns). Get-Process shows Handles too. A normal program might have a few hundred; a busy one such as a browser can have thousands. A count that only climbs over hours may mean a handle leak. Sysinternals Process Explorer (free from Microsoft, optional) can list the handle names themselves.

Windows has a very high limit on handles per process (in the millions), but a leak is still a bug that wastes kernel memory.

5.4 Handle Inheritance

What it is: When a parent starts a child (Section 2), the parent can choose to pass some of its handles to the child. This is called handle inheritance.

Two steps are needed, and both must say yes:

1. The handle must be created inheritable (marked "may be inherited").
2. The parent must call CreateProcess with the inherit handles option turned on.

 PARENT                          CHILD (after CreateProcess)
 handle 0x20 (inheritable) ----> handle 0x20  (same number, same object)
 handle 0x24 (not inheritable)   (child gets nothing for this one)

The child gets the same handle number pointing to the same object. A very common use is redirected output: a parent opens a pipe or file, passes it to the child as its "standard output", and reads everything the child prints (this is exactly how dir > list.txt works in Command Prompt).

Safety notes:

• Pass only what the child needs. Leaking an inheritable handle to a child can give it access to something sensitive.
• If a parent keeps a file handle inheritable, every child may keep that file open, which can cause "file in use" problems.
• Not-inheritable handles can also be duplicated deliberately into another process with a function called DuplicateHandle, which needs both processes' permission.

Summary