The Windows Object Manager Namespace: Handles, Named Objects, and Object Directories
A practical map of Windows kernel objects, per-process handles, the Object Manager namespace, symbolic links, sessions, access checks, and inspection tools.
Windows represents processes, threads, events, mutexes, sections, devices, tokens, registry keys, and many other kernel resources as executive objects. A process normally refers to an object through a handle in its private handle table. Some object types can also have names in a kernel-managed hierarchical namespace. Paths such as C:\ are user-facing translations layered over this model, not the namespace’s root.
An object, a name, and a handle are different things
An object has a type, state, security descriptor, and reference counts defined by the executive subsystem. A name, when supported, lets code locate an existing object through an Object Manager directory. A handle is a process-relative table entry that records granted access and attributes. The numeric value 0x100 in two processes does not imply the same object.
When a process opens a named object, the Object Manager parses the path, finds the object, evaluates security through the relevant checks, and creates a handle with the granted rights. Later operations use the handle rather than repeating name lookup. Closing removes that handle reference; the object remains while other handles or kernel references exist, and permanent objects follow additional lifetime rules.
Duplicating a handle into another process can grant no more access than the source and requested rules permit. Passing a handle is an authority transfer. Applications should request the narrowest rights and mark handles non-inheritable unless a child explicitly needs them.
Object directories organize kernel-visible names
The root \ contains directories such as \Device, \Driver, \KnownDlls, \BaseNamedObjects, and symbolic-link structures whose exact contents vary by Windows version and boot. The Win32 path C: commonly resolves through a DOS-device symbolic link to a volume device. QueryDosDevice exposes supported mappings without programs hard-coding kernel paths.
User sessions complicate named synchronization objects. Win32 prefixes such as Local\ and Global\ select session-scoped or global namespaces for file mappings, events, mutexes, and related objects. A service and an interactive app can therefore create the same suffix yet refer to different objects. Global creation may require privilege or an appropriate security descriptor depending on type and operation.
Names are not authentication. If a lower-privileged process can create a predictable named event or section first, a privileged process that opens it without verifying security can be confused. Use explicit security descriptors, restrictive namespaces/private namespaces where appropriate, unguessable per-instance data only as defense in depth, and validate the creator/contents through a real trust protocol.
Win32, NT, and file namespaces overlap selectively
Win32 APIs translate familiar names into NT object paths before system calls. The \\?\ prefix changes Win32 path parsing and length behavior for file APIs; it does not give arbitrary access to every Object Manager type. \\.\DeviceName is commonly used to open a device exposed through a DOS-device link.
File-system directories live inside volumes managed by file-system drivers, whereas Object Manager directories contain kernel object names. Seeing \Device\HarddiskVolume... in a tool does not mean every NTFS folder is an Object Manager directory.
Inspect without mutating
Microsoft Sysinternals WinObj displays the namespace and object metadata. Process Explorer/Handle can show process handles. Run with only the privilege needed, collect screenshots or exports before changes, and never delete/close another process’s handles as a routine repair; forced closure can corrupt state or crash the owner.
For code, rely on documented Win32/WDK APIs. Native Nt* information calls and namespace layouts can be version-sensitive. The useful mental model remains stable: names resolve objects, handles carry granted authority within a process, and reference/security rules govern lifetime and access.
Related:
- ALPC on Windows: The Message Transport Behind Local System Services
- How to Centralize Windows Events with Windows Event Forwarding
Sources: