intermediate

Kernel objects

Handles, object manager, names, and reference counting basics.

Related labs

Hands-on exercises for this area — in the browser or on a Windows machine.

View all labs

Official Microsoft docs

Closest official references related to this topic on Microsoft Learn.

Why it matters

Objects are the common language of Windows internals. Events, mutexes, processes, files, and tokens all become easier once you see the shared object model.

Mental model

The Object Manager gives Windows a standard way to name, reference, secure, and lifetime-manage kernel resources.

Windows building blocks

Names and paths you can look for in Task Manager, Explorer, or documentation.

  • FileObject directories

    \BaseNamedObjects

    Session-local named objects

Go one level deeper

Extra detail for readers who want more precision before opening a child topic.

  • Handle tables are per-process; the same kernel object can be shared by duplicating handles across processes.
  • Named objects participate in isolation boundaries (session, AppContainer, integrity).

How it works

  1. 1Kernel objects live behind handles rather than being accessed directly from user mode.
  2. 2Each process has a handle table that maps integer handles to object references.
  3. 3Reference counts and security descriptors control lifetime and access.

Key terms

Object Manager
The subsystem that standardizes kernel object naming and lifetime.
Reference count
The count of active references keeping an object alive.

Why closing a handle matters

If a process leaks handles, the kernel object may stay alive long after the app is done using it.

Common misconception

A handle is not the object itself. It is a process-specific reference to an underlying object.

You should read next

Ranked from your current topic, related links, branch depth, and any active guided path.

Related topics