Misplaced Pages

#845154

34-698: Most of the Native API calls are implemented in ntoskrnl.exe and are exposed to user mode by ntdll.dll . The entry point of ntdll.dll is LdrInitializeThunk . Native API calls are handled by the kernel via the System Service Descriptor Table (SSDT). The Native API comprises many functions. They include C runtime functions that are needed for a very basic C runtime execution, such as strlen(), sprintf(), memcpy() and floor(). Other common procedures like malloc(), printf(), scanf() are missing (the first because it does not specify

68-487: 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: The Attributes member can be zero, or a combination of the following flags: Object Manager paths are available to many Windows API file functions, although Win32 names like \\?\ and \\.\ for

102-533: A heap to allocate memory from and the second and third because they use the console, accessed only via KERNEL32.DLL). The vast majority of other Native API routines, by convention, have a 2 or 3 letter prefix, which is: user32.dll and gdi32.dll include several other calls that execute an interrupt into kernel mode. These were not part of the original Windows NT design, as can be seen in Windows NT 3.5 . However, due to performance issues of hardware of that age, it

136-446: 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

170-400: 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

204-527: A static copy of the C Runtime objects, the executable is usually about 10 MB in size. In Windows XP and earlier, the Windows installation source ships four kernel image files to support uniprocessor systems , symmetric multiprocessor (SMP) systems, CPUs with PAE , and CPUs without PAE. Windows setup decides whether the system is uniprocessor or multiprocessor, then, installs both the PAE and non-PAE variants of

238-419: Is accessible from both user and kernel mode. Application programs run in processes and supply code that runs in user mode. The upper part is accessible only from kernel mode, and with some exceptions, is instantiated just once, system-wide. Ntoskrnl.exe is mapped into this region, as are several other kernel mode components. This region also contains data used by kernel mode code, such as the kernel mode heaps and

272-529: Is easy to understand. Functions and global variables use the, so called Pascal Case formatting with special (additional) prefixes in their names to differentiate parts of the kernel. An example is IoCreateDevice and ObReferenceObjectByHandle . Both functions have different prefix names to differentiate critical managers within the kernel code: Io being used for I/O Manager functions and Ob for Object Manager functions. Variations of these prefixes exist for internal functions that are not being exported by

306-761: 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

340-474: Is stored on disk as several different files called "hives." One, the System hive, is loaded early in the boot sequence and provides configuration information required at that time. Additional registry hives, providing software-specific and user-specific data, are loaded during later phases of system initialization and during user login, respectively. The list of drivers to be loaded from the disk are retrieved from

374-451: Is that interrupts are usually conditionally masked based on their priority (called "IRQL"), instead of disabling all IRQs via the interrupt flag. This permits various kernel components to carry on critical operations without necessarily blocking services of peripherals and other devices. The entire physical memory (RAM) address range is broken into many small blocks also called pages, 4KB in size each, and mapped to virtual addresses. A few of

SECTION 10

#1732797603846

408-611: The Services key of the current control set's key in the SYSTEM registry hive. That key stores device drivers, kernel processes and user processes. They are all collectively called "services" and are all stored mixed on the same place. During initialization or upon driver load request, the kernel traverses that tree looking for services tagged as kernel services. As mentioned in Windows Internals Book 7th edition ,

442-471: 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 layers, it contains the cache manager, security reference monitor, memory manager, scheduler (Dispatcher), and blue screen of death (the prose and portions of

476-400: 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

510-757: The Interrupt Dispatch Table (IDT). When a device triggers an interrupt and the interrupt flag (IF) in the FLAGS register is set, the processor's hardware looks for an interrupt handler in the table entry corresponding to the interrupt number to which in turn has been translated from IRQ by PIC chips, or in more modern hardwares, APIC . Interrupt handlers usually save some subset of the state of registers before handling it and restore them back to their original values when done. The interrupt table contains handlers for hardware interrupts, software interrupts, and exceptions. For some IA-32 versions of

544-460: The address of each one, it has to load them one by one to fill the PCR structure. The main entry point of ntoskrnl.exe performs some system dependent initialization then calls a system independent initialization then enters an idle loop. Modern operating systems use interrupts instead of I/O port polling to wait for information from devices. In the x86 architecture , interrupts are handled through

578-556: The behavior of the kernel, path of the files loaded by the bootloader ( SYSTEM Registry hive , nls for character encoding conversion, and vga font). The definition of this structure can be retrieved by using the kernel debugger or downloading it from the Microsoft symbol database. In the x86 architecture , the kernel receives the system already in protected mode, with the GDT , IDT and TSS ready. But since it does not know

612-659: The boot-time option increaseuserva and corresponding header in executable image is required for this feature. Object Manager (Windows) 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

646-446: The code). x86 versions of ntoskrnl.exe depend on bootvid.dll , hal.dll and kdcom.dll (x64 variants of ntoskrnl.exe have these dlls embedded in the kernel to improve performance). However, it is not a native application thus it is not linked against ntdll.dll . Instead, ntoskrnl.exe has its own entry point " KiSystemStartup " that calls the architecture -independent kernel initialization function. Because it requires

680-629: 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, known as a handle, is created. The Object Manager indexes objects by both their names and handles. Referencing objects by handles is faster since it bypasses name translation. Handles are associated with processes by making an entry in

714-414: The file system cache. Windows Registry is a repository for configuration and settings information for the operating system and for other software, such as applications. It can be thought of as a filesystem optimized for small files. However, it is not accessed through file system-like semantics, but rather through a specialized set of APIs, implemented in kernel mode and exposed to user mode. The registry

SECTION 20

#1732797603846

748-399: The kernel image for the decided kind. On a multiprocessor system, Setup installs ntkrnlmp.exe and ntkrpamp.exe but renames them to ntoskrnl.exe and ntkrnlpa.exe respectively. Starting with Windows Vista, Microsoft began unifying the kernel images as multi-core CPUs took to the market and PAE became mandatory. Windows kernel's architecture is structured so that everything

782-491: 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. Applications themselves can wrap one or more Executive objects and surface objects that offer certain services. Executive objects are also used by

816-559: The kernel, one example of such a software interrupt handler (of which there are many) is in its IDT table entry 2E 16 ( hexadecimal ; 46 in decimal ), used in assembly language as INT 2EH for system calls . In the real implementation the entry points to an internal subroutine named (as per symbol information published by Microsoft) KiSystemService . For newer versions, different mechanisms making use of SYSENTER instruction and in x86-64 SYSCALL instruction are used instead. One notable feature of NT's interrupt handling

850-558: The kernel, such as adding an i after the first letter (e.g., Ki for “Kernel Internal”) or appending p to the full prefix (e.g., Psp for “Process Support Internal”). The following table lists all prefixes. Prefix When the kernel receives control, it gets a struct-type pointer from bootloader . The pointer's destination contains information about the hardware, the path to the Windows Registry file, kernel parameters containing boot preferences or options that change

884-461: 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

918-469: The operations that can be performed through them. This consistency ensures uniform handling of various object types programmatically. Handle creation and resolution of objects from handles are exclusively managed by the Object Manager, ensuring that no resource usage goes unnoticed. The types of Executive objects exposed by Windows NT are: Each object managed by the Object Manager has a header and

952-435: The process's Handle table, which lists the handles it owns, and can be transferred between processes. A process must own a handle to an object to use it, and can own up to 16,000,000 handles at one time. During creation, a process gains handles to a default set of objects. There are different types of handles, such as file handles, event handles, and process handles, which identify the type of target objects but do not distinguish

986-492: The properties of each block are stored in structures called page table entries, which are managed by the OS and accessed by the processor's hardware. Page tables are organized into a tree structure, and the physical page number of the top-level table is stored in control register 3 (CR3). Microsoft Windows divides virtual address space into two regions. The lower part, starting at zero, is instantiated separately for each process and

1020-453: The resource. Object Manager is a shared resource, and all subsystems that deal with the resources have to pass through the Object Manager. 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

1054-438: 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

Windows Native API - Misplaced Pages Continue

1088-447: 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

1122-449: 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

1156-575: Was decided to move the graphics subsystem into kernel mode. As such, system call in the range of 0x1000-0x1FFF are satisfied by win32k.sys (instead of ntoskrnl.exe as done for 0-0x0FFF), and are declared in user32.dll and gdi32.dll. These functions have the NtUser and NtGdi prefix (e.g. NtUserLockWorkStation and NtGdiEnableEudc ). Uses of Native API functions includes but not limited to: Ntoskrnl.exe ntoskrnl.exe (short for Windows NT operating system kernel executable ), also known as

#845154