Object Manager (Windows)

Last updated
Object Manager in Windows, categorized hierarchically using namespaces Object Manager (Windows) screenshot.png
Object Manager in Windows, categorized hierarchically using namespaces

Object Manager (internally called Ob) is a subsystem implemented as part of the Windows Executive which manages Windows resources. Resources, which are surfaced as logical objects, each reside in a namespace for categorization. Resources can be physical devices, files or folders on volumes, Registry entries or even running processes. All objects representing resources have an Object Type property and other metadata about the resource. Object Manager is a shared resource, and all subsystems that deal with the resources have to pass through the Object Manager.

Contents

Architecture

The Object Manager in the architecture of Windows NT Windows 2000 architecture.svg
The Object Manager in the architecture of Windows NT

Object Manager is the centralized resource broker in the Windows NT line of operating systems, which keeps track of the resources allocated to processes. It is resource-agnostic and can manage any type of resource, including device and file handles. All resources are represented as objects, each belonging to a logical namespace for categorization and having a type that represents the type of the resource, which exposes the capabilities and functionalities via properties. An object is kept available until all processes are done with it; Object Manager maintains the record of which objects are currently in use via reference counting, as well as the ownership information. Any system call that changes the state of resource allocation to processes goes via the Object Manager.

Objects can either be Kernel objects or Executive objects. Kernel objects represent primitive resources such as physical devices, or services such as synchronization, which are required to implement any other type of OS service. Kernel objects are not exposed to user mode code, but are restricted to kernel code. Applications and services running outside the kernel use Executive objects, which are exposed by the Windows Executive, along with its components such as the memory manager, scheduler and I/O subsystem. Executive objects encapsulate one or more kernel objects and expose not only the kernel and kernel-mediated resources, but also an expanded set of services that the kernel does.[ clarification needed ] Applications themselves can wrap one or more Executive objects and surface objects[ definition needed ] that offer certain services. Executive objects are also used by the environment subsystems (such as the Win32 subsystem, the OS/2 subsystem, the POSIX subsystem, etc.) to implement the functionality of the respective environments.

Whenever an object is created or opened, a reference to the instance, called a handle, is created. Object Manager indexes the objects both by their names as well as the handles. But, referencing the objects by the handles is faster because the name translation can be skipped. Handles are associated with processes (by making an entry into the process' Handle table that lists the handles it owns) and can be transferred between processes as well. A process must own a handle to an object before using it. A process can own a maximum of 16,000,000 handles at one time. During creation, a process gains handles to a default set of objects. While there exists different types of handles - file handles, event handles and process handles - they only help in identifying the type of the target objects; not in distinguishing the operations that can be performed through them, thus providing consistency to how various object types are handled programmatically. Handle creation and resolution of objects from handles are solely mediated by Object Manager, so no resource usage goes unnoticed by it.

The types of Executive objects exposed by Windows NT are:

TypeDescription System call to get handle
DirectoryA container holds other kernel objects. Multiple levels of nested directories organize all kernel objects into a single tree.NtCreateDirectoryObject
NtOpenDirectoryObject
Process A collection of executable threads along with virtual addressing and control information.NtCreateProcess
NtOpenProcess
Thread An entity containing code in execution, inside a process.NtCreateThread
NtOpenThread
JobA collection of processes.NtCreateJobObject
NtOpenJobObject
FileAn open file or an I/O device.NtCreateFile
NtOpenFile
SectionA region of memory optionally backed by a file or the page file.NtCreateSection
NtOpenSection
Access tokenThe access rights for an object.NtCreateToken
NtDuplicateToken
NtOpenProcessToken
NtOpenThreadToken
EventAn object which encapsulates some information, to be used for notifying processes of something.NtCreateEvent
NtOpenEvent
Semaphore/Mutex Objects which serialize access to other resources.NtCreateSemaphore
NtOpenSemaphore
TimerAn objects which notifies processes at fixed intervals.NtCreateTimer
NtOpenTimer
KeyA registry key.NtCreateKey
NtOpenKey
DesktopA logical display surface to contain GUI elements.None
Clipboard A temporary repository for other objects.None
WindowStationAn object containing a group of Desktop objects, one Clipboard and other user objects.None
Symbolic linkA reference to another object, via which the referred object can be used.NtCreateSymbolicLinkObject
NtOpenSymbolicLinkObject

Object structure

Each object managed by the Object Manager has a header and a body; the header contains state information used by Object Manager, whereas the body contains the object-specific data and the services it exposes. An object header contains certain data, exposed as Properties, such as Object Name (which identifies the object), Object Directory (the category the object belongs to), Security Descriptors (the access rights for an object), Quota Charges (the resource usage information for the object), Open handle count (the number of times a handle, an identifier to the object, has been opened), Open handle list (the list of processes which has a live reference to the object), its Reference count (the number of live references to the object), and the Type (an object that identifies the structure of the object body) of the object.

A Type object contains properties unique to the type of the object as well as static methods that implement the services offered by the object. Objects managed by Object Manager must at least provide a predefined set of services: Close (which closes a handle to an object), Duplicate (create another handle to the object with which another process can gain shared access to the object), Query object (gather information about its attributes and properties), Query security (get the security descriptor of the object), Set security (change the security access), and Wait (to synchronize with one or more objects via certain events). Type objects also have some common attributes, including the type name, whether they are to be allocated in non-paged memory, access rights, and synchronization information. All instances of the same type share the same type object, and the type object is instantiated only once. A new object type can be created by endowing an object with Properties to expose its state and methods to expose the services it offers.

Object name is used to give a descriptive identity to an object, to aid in object lookup. Object Manager maintains the list of names already assigned to objects being managed, and maps the names to the instances. Since most object accesses occur via handles, it is not always necessary to look up the name to resolve into the object reference. Lookup is only performed when an object is created (to make sure the new object has a unique name), or a process accesses an object by its name explicitly. Object directories are used to categorize them according to the types. Predefined directories include \?? (device names), \BaseNamedObjects (Mutexes, events, semaphores, waitable timers, and section objects), \Callback (callback functions), \Device, \Driver, \FileSystem, \KnownDlls, \Nls (language tables), \ObjectTypes (type objects), \RPC Control (RPC ports), \Security (security subsystem objects), and \Windows (windowing subsystem objects). Objects also belong to a Namespace. Each user session is assigned a different namespace. Objects shared between all sessions are in the GLOBAL namespace, and session-specific objects are in the specific session namespaces

OBJECT_ATTRIBUTES structure:

typedefstruct_OBJECT_ATTRIBUTES{ULONGLength;HANDLERootDirectory;PUNICODE_STRINGObjectName;ULONGAttributes;PSECURITY_DESCRIPTORSecurityDescriptor;PSECURITY_QUALITY_OF_SERVICESecurityQualityOfService;}OBJECT_ATTRIBUTES*POBJECT_ATTRIBUTES;

The Attributes member can be zero, or a combination of the following flags:

OBJ_INHERIT OBJ_PERMANENT OBJ_EXCLUSIVE OBJ_CASE_INSENSITIVE OBJ_OPENIF OBJ_OPENLINK OBJ_KERNEL_HANDLE

Usage

Object Manager paths are available to many Windows API file functions, although Win32 names like \\?\ and \\.\ for the local namespaces suffice for most uses. [1] Using the former in Win32 user-mode functions translates directly to \??, but using \?? is still different as this NT form does not turn off pathname expansion. [2]

Tools that serve as explorers in the Object Manager namespaces are available. These include the 32-bit WinObj from Sysinternals [3] and the 64-bit WinObjEx64. [4]

See also

Related Research Articles

<span class="mw-page-title-main">Graphics Device Interface</span> Microsoft Windows API

The Graphics Device Interface (GDI) is a legacy component of Microsoft Windows responsible for representing graphical objects and transmitting them to output devices such as monitors and printers. It was superseded by Direct2D API. Windows apps use Windows API to interact with GDI, for such tasks as drawing lines and curves, rendering fonts, and handling palettes. The Windows USER subsystem uses GDI to render such UI elements as window frames and menus. Other systems have components that are similar to GDI; for example: macOS has Quartz, and Linux and Unix have X Window System and Wayland.

An object-oriented operating system is an operating system that is designed, structured, and operated using object-oriented programming principles.

NTLDR is the boot loader for all releases of Windows NT operating system from 1993 with the release of Windows NT 3.1 up until Windows XP and Windows Server 2003. From Windows Vista onwards it was replaced by the BOOTMGR bootloader. NTLDR is typically run from the primary storage device, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file.

In computing, a directory service or name service maps the names of network resources to their respective network addresses. It is a shared information infrastructure for locating, managing, administering and organizing everyday items and network resources, which can include volumes, folders, files, printers, users, groups, devices, telephone numbers and other objects. A directory service is a critical component of a network operating system. A directory server or name server is a server which provides such a service. Each resource on the network is considered an object by the directory server. Information about a particular resource is stored as a collection of attributes associated with that resource or object.

<span class="mw-page-title-main">Windows NT 3.1</span> First major release of Windows NT, released in 1993

Windows NT 3.1 is the first major release of the Windows NT operating system developed by Microsoft, released on July 27, 1993.

<span class="mw-page-title-main">Windows Registry</span> Database for Microsoft Windows

The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interfaces can all use the registry. The registry also allows access to counters for profiling system performance.

The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards. DRM exposes an API that user-space programs can use to send commands and data to the GPU and perform operations such as configuring the mode setting of the display. DRM was first developed as the kernel-space component of the X Server Direct Rendering Infrastructure, but since then it has been used by other graphic stack alternatives such as Wayland and standalone applications and libraries such as SDL2 and Kodi.

<span class="mw-page-title-main">Architecture of Windows NT</span> Overview of the architecture of the Microsoft Windows NT line of operating systems

The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant multitasking operating system, which has been designed to work with uniprocessor and symmetrical multiprocessor (SMP)-based computers. To process input/output (I/O) requests, they use packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows XP, Microsoft began making 64-bit versions of Windows available; before this, there were only 32-bit versions of these operating systems.

The Local Inter-Process Communication is an internal, undocumented inter-process communication facility provided by the Microsoft Windows NT kernel for lightweight IPC between processes on the same computer. As of Windows Vista, LPC has been rewritten as Asynchronous Local Inter-Process Communication in order to provide a high-speed scalable communication mechanism required to efficiently implement User-Mode Driver Framework (UMDF), whose user-mode parts require an efficient communication channel with UMDF's components in the executive.

A Unix architecture is a computer operating system system architecture that embodies the Unix philosophy. It may adhere to standards such as the Single UNIX Specification (SUS) or similar POSIX IEEE standard. No single published standard describes all Unix architecture computer operating systems — this is in part a legacy of the Unix wars.

Extended file attributes are file system features that enable users to associate computer files with metadata not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem. Unlike forks, which can usually be as large as the maximum file size, extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses include storing the author of a document, the character encoding of a plain-text document, or a checksum, cryptographic hash or digital certificate, and discretionary access control information.

The booting process of Windows NT is the process run to start Windows NT. The process has been changed between releases, with the biggest changes being made with Windows Vista. In versions before Vista, the booting process begins when the BIOS loads the Windows NT bootloader, NTLDR. Starting with Vista, the booting process begins with either the BIOS or UEFI load the Windows Boot Manager, which replaces NTLDR as the bootloader. Next, the bootloader starts the kernel, which starts the session manager, which begins the login process. Once the user is logged in, File Explorer, the graphical user interface used by Windows NT, is started.

The Native API is a lightweight application programming interface (API) used by Windows NT and user mode applications. This API is used in the early stages of Windows NT startup process, when other components and APIs are still unavailable. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API. The Native API is also used by subroutines such as those in kernel32.dll that implement the Windows API, the API based on which most of the Windows components are created.

ntoskrnl.exe, also known as the kernel image, contains the kernel and executive layers of the Microsoft Windows NT kernel, and is responsible for hardware abstraction, process handling, and memory management. In addition to the kernel and executive mentioned earlier, it contains the cache manager, security reference monitor, memory manager, scheduler (Dispatcher), and blue screen of death.

The Session Manager Subsystem, or smss.exe, is a component of the Microsoft Windows NT family of operating systems, starting in Windows NT 3.1. It is executed during the startup process of those operating systems.

The Microsoft Windows operating system supports a form of shared libraries known as "dynamic-link libraries", which are code libraries that can be used by multiple processes while only one copy is loaded into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.

Client Server Runtime Subsystem, or csrss.exe, is a component of the Windows NT family of operating systems that provides the user mode side of the Win32 subsystem and is included in Windows NT 3.1 and later. Because most of the Win32 subsystem operations have been moved to kernel mode drivers in Windows NT 4 and later, CSRSS is mainly responsible for Win32 console handling and GUI shutdown. It is critical to system operation; therefore, terminating this process will result in system failure. Under normal circumstances, CSRSS cannot be terminated with the taskkill command or with Windows Task Manager, although it is possible in Windows Vista if the Task Manager is run in Administrator mode. On Windows 7 and later, Task Manager will inform the user that terminating the process may result in system failure, and prompt if they want to continue. In Windows NT 4.0 however, terminating CSRSS without the Session Manager Subsystem (SMSS) watching will not crash the system. However, in Windows XP, terminating CSRSS without SMSS watching will crash the system due to the critical bit being set in RAM for csrss.exe.

In Unix-like operating systems, a device file or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

cgroups is a Linux kernel feature that limits, accounts for, and isolates the resource usage of a collection of processes.

<span class="mw-page-title-main">Standard Libraries (CLI)</span> Standard libraries of C#, the .NET Framework and Core, and related projects

The Standard Libraries is a set of libraries included in the Common Language Infrastructure (CLI) in order to encapsulate many common functions, such as file reading and writing, XML document manipulation, exception handling, application globalization, network communication, threading, and reflection, which makes the programmer's job easier. It is much larger in scope than standard libraries for most other languages, including C++, and is comparable in scope and coverage to the standard libraries of Java.

References

  1. "Naming Files, Paths, and Namespaces - Win32 apps". docs.microsoft.com.
  2. "winapi - Is there a difference between \??\ and \\?\ paths?". Stack Overflow.
  3. "WinObj - Windows Sysinternals". docs.microsoft.com.
  4. "hfiref0x/WinObjEx64: Windows Object Explorer 64-bit". GitHub. 20 February 2020.