Windows® Internals, Sixth Edition, Part 1

To increase efficiency, the object manager doesn’t look up an object’s name each time someone uses the object. Instead, it looks up a name under only two circumstances. The first is when a process creates a named object: the object manager looks up the name to verify that it doesn’t already exist before storing the new name in the global namespace. The second is when a process opens a handle to a named object: the object manager looks up the name, finds the object, and then returns an object handle to the caller; thereafter, the caller uses the handle to refer to the object. When looking up a name, the object manager allows the caller to select either a case-sensitive or case-insensitive search, a feature that supports Subsystem for UNIX Applications and other environments that use case-sensitive file names.

Object Directories

The object directory object is the object manager’s means for supporting this hierarchical naming structure. This object is analogous to a file system directory and contains the names of other objects, possibly even other object directories. The object directory object maintains enough information to translate these object names into pointers to the objects themselves. The object manager uses the pointers to construct the object handles that it returns to user-mode callers. Both kernel-mode code (including executive components and device drivers) and user-mode code (such as subsystems) can create object directories in which to store objects. For example, the I/O manager creates an object directory named \Device, which contains the names of objects representing I/O devices.

Where the names of objects are stored depends on the object type. Table 3-17 lists the standard object directories found on all Windows systems and what types of objects have their names stored there. Of the directories listed, only \BaseNamedObjects and \Global?? are visible to standard Windows applications. (See the Session Namespace section later in this chapter for more information.)

Table 3-17. Standard Object Directories

Directory

Types of Object Names Stored

\ArcName

Symbolic links mapping ARC-style paths to NT-style paths.

\BaseNamedObjects

Global mutexes, events, semaphores, waitable timers, jobs, ALPC ports, symbolic links, and section objects.

\Callback

Callback objects.

\Device

Device objects.

\Driver

Driver objects.

\FileSystem

File-system driver objects and file-system-recognizer device objects. The Filter Manager also creates its own device objects under the Filters subkey.

\GLOBAL??

MS-DOS device names. (The \Sessions\0\DosDevices\\Global directories are symbolic links to this directory.)

\KernelObjects

Contains event objects that signal low resource conditions, memory errors, the completion of certain operating system tasks, as well as objects representing Sessions.

\KnownDlls

Section names and path for known DLLs (DLLs mapped by the system at startup time).

\KnownDlls32

On a 64-bit Windows installation, \KnownDlls contains the native 64-bit binaries, so this directory is used instead to store Wow64 32-bit versions of those DLLs.

\Nls

Section names for mapped national language support tables.

\ObjectTypes

Names of types of objects.

\PSXSS

If Subsystem for UNIX Applications is enabled (through installation of the SUA component), this contains ALPC ports used by Subsystem for UNIX Applications.

\RPC Control

ALPC ports used by remote procedure calls (RPCs), and events used by Conhost.exe as part of the console isolation mechanism.

\Security

ALPC ports and events used by names of objects specific to the security subsystem.

\Sessions

Per-session namespace directory. (See the next subsection.)

\UMDFCommunicationPorts

ALPC ports used by the User-Mode Driver Framework (UMDF).

\Windows

Windows subsystem ALPC ports, shared section, and window stations.

Because the base kernel objects such as mutexes, events, semaphores, waitable timers, and sections have their names stored in a single object directory, no two of these objects can have the same name, even if they are of a different type. This restriction emphasizes the need to choose names carefully so that they don’t collide with other names. For example, you could prefix names with a GUID and/or combine the name with the user’s security identifier (SID).