Ntoskrnl.exe
In computing ntoskrnl.exe, also known as kernel image, provides the kernel and executive layers of the Microsoft Windows NT kernel space, and is responsible for various system services such as hardware abstraction, process and memory management, thus making it a fundamental part of the system. It contains the cache manager, the executive, the kernel, the security reference monitor, the memory manager, and the scheduler.
Overview
This system binary is not a native application, instead containing a standard 'start' entry point in its-own, a function that calls the architecture-independent kernel initialization function. While ntoskrnl.exe is not linked againstntdll.dll, it is linked against bootvid.dll, hal.dll and kdcom.dll. Because it requires a static copy of C Runtime objects it depends on, the executable is usually about 2 MB in size.Overall, there are four kernel image files for each revision of Windows, and two kernel image files for each Windows system. Multiprocessor or uniprocessor files are selected at install time, and PAE or non-PAE files are selected by boot.ini or BCD option, according to the.
| Filename | Supports SMP | Supports PAE |
ntoskrnl.exe | ||
ntkrnlmp.exe | ||
ntkrnlpa.exe | ||
ntkrpamp.exe |
Routines in ntoskrnl use prefixes on their names to indicate in which component of ntoskrnl they are defined. The following table lists some of them.
| Prefix | Meaning |
| Cc | File system cache |
| Cm | Configuration Manager, the kernel mode side of Windows Registry |
| Csr | functions used to communicate with the Win32 subsystem process, csrss.exe |
| Dbg | debugging aid functions, such as a software break point |
| Ex | Windows executive, an "outer layer" of Ntoskrnl.exe |
| Exp | Windows executive private: Routines within the executive layer that are not exported for call outside of the executive |
| FsRtl | file system runtime library |
| Io | I/O manager |
| Ke | core kernel routines |
| Ki | routines in the kernel that are not exported for call from outside the kernel |
| Ks | kernel streaming |
| Ldr | loader functions for PE file handling |
| Lpc | Local Procedure Call, an internal, undocumented, interprocess or user/kernel message passing mechanism |
| Lsa | Local Security Authority |
| Mi | memory management routines not exported for call outside the memory manager |
| Mm | memory management |
| Nls | Nls for Native Language Support. |
| Ob | Object Manager |
| Pfx | Pfx for prefix handling. |
| Po | Plug-and-play and power management |
| Ps | Process and thread management |
| Rtl | Run-Time Library. This includes many utility functions that can be used by native applications, yet don't directly involve kernel support |
| Rtlp | Run-Time Library internal routines that are not exported form the kernel. |
| Se | security |
| Vf | Driver verifier |
| Vi | Driver verifier routines not exported for call outside the driver verifier |
| Zw | Nt or Zw are system calls declared in ntdll.dll and ntoskrnl.exe. When called from ntdll.dll in user mode, these groups are almost exactly the same; they trap into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT. When calling the functions directly in ntoskrnl.exe, the Zw variants ensure kernel mode, whereas the Nt variants do not. |
Initialization
When the kernel receives control, it gets a pointer to a structure as parameter. This structure is passed by the bootloader and contains information about the hardware, the path to the registry file, kernel parameters containing boot preferences or options that change the behavior of the kernel, path of the files loaded by the bootloader. 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 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.
Interrupt handling
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 the Interrupt Dispatch Table. When a device triggers an interrupt and the interrupt flag 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 the kernel, one example of such a software interrupt handler is in its IDT table entry 2E16, used in assembly language as
INT 2EH for system calls. In the real implementation the entry points to an internal subroutine named 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 is that interrupts are usually conditionally masked based on their priority, 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.
Memory manager
Microsoft Windows divides virtual address space into two regions. The lower part, starting at zero, is instantiated separately for each process and 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 the file system cache.
| Arch | MmHighestUserAddress | MmSystemRangeStart |
| x86 | 0x7fffffff | 0x80000000 |
| ARM | 0x7fffffff | 0x80000000 |
| x86-64 | 0x000007ff'ffffffff | 0xffff8000'00000000 |
The entire physical memory address range is broken into many small blocks. A few of 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.
Registry
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 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.
Drivers
The list of drivers to be loaded from the disk are retrieved from theServices 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.