Ntoskrnl.exe

ntoskrnl.exe (short for "Windows NT operating system kernel executable"), also known as the kernel image, is an executable file that 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 the code).Russinovich, M: Systems Internals Tips and Trivia, SysInternals Information

Overview Newer x86 32-bit variants of ntoskrnl.exe heavily depend on hal.dll due to architecture-dependent code being compiled directly into it. However, AMD64 compiled variants of ntoskrnl.exe link HAL statically into the kernel but also keep a stub HAL.dll kernel module in the address space for backwards compatibility: allowing legacy kernel drivers, importing from HAL.dll, to be redirected to equivalent code in the kernel instead.

With all this, the kernel image is not a native application, therefore it is not linked against ntdll.dll. Instead, ntoskrnl.exe has its own entry point routine named KiSystemStartup (as per symbol information published by Microsoft) that calls the architecture-independent kernel initialization subroutines. The kernel is compiled using a static copy of the C Runtime, which for a normal program would noticeably increase its file 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 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.

+ Kernel image filenames32-bit Windows Filename SupportsSMP SupportsPAE 32-bit kernel ntoskrnl.exe ntkrnlmp.exe ntkrnlpa.exe ntkrpamp.exe 64-bit kernel (x64 editions) Filename SupportsSMP Supports57 bit VA SupportsAPX ntoskrnl.exe ntkrnlmp.exe ntkrla57.exe ntkrlapx.exe

The kernel's code uses prefixes to indicate their associated subsystem.

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 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 some known prefixes.

+ NT subsystem prefixes ExportPrefixInternal Prefix MeaningArbArbpPlug-and-play resource arbiter Cc Ccp File system cache Cm Cmp Configuration Manager, the kernel mode side of Windows Registry Dbg Dbg Debugging aid functions, such as a software break point Dbgk Dbgk A set of debugging functions that are being exposed to user mode through NTDLL.dll Ex Exp Windows executive, an "outer layer" of ntoskrnl.exe FsRtl FsRtlp File system runtime library Io Iop I/O managerKdKdpKernel debugging facilities, used by WinDbg Ke Ki Core kernel routines Kx Interrupt handling, semaphores, spinlocks, multithreading and context switching related functions Ks Kernel streaming Ldr Ldrp NT's PE Executables loader, NTLDR Lpc Lpcp Local Procedure Call, an internal, undocumented, interprocess or user/kernel message passing mechanism Lsa Lsap Local Security Authority Mm Mi Memory management Nls Nls Native Language Support (similar to code pages) Ob Obp Object Manager Po Pop Plug-and-play and power management Ps Psp Process and thread management (task management) Rtl Rtlp Runtime library, i.e., many utility functions that can be used by native applications, yet don't directly involve kernel support Se Sep Security Manager, access token for the Win32 API Vf Vi Driver Verifier Zw/Nt 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 (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not.

Initialization Before handing the execution to the kernel, the bootloader initializes the system to protected mode on x86 32-bit platforms and long mode with 4-level paging enabled (or 5-level paging if available) on x86 64-bit platforms (both platforms will have their CPU GDT, IDT and TSS ready).

When control is transferred to the kernel, it receives an information record, known as the Loader Parameter Block, from the bootloader. The block contains information about the hardware, the path to the Windows Registry file, kernel parameters, 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.

The entry point of ntoskrnl.exe is firstly run on the boot processor (the first processor to start on the system). The boot processor will initialize the kernel executive and create a system thread in order to launch smss.exe. After enabling interrupts, the boot processor will enter an idle loop.

Construction

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 (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 hardware, 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 (of which there are many) is in its IDT table entry 2E16 (hexadecimal; 46 in decimal), used in assembly language as INT 2EH for system calls, which are Microsoft internal usage calls, leading to kernel system calls. For newer versions, different mechanisms making use of SYSENTER instruction and in AMD64 SYSCALL instruction are used instead.

One notable feature of NT's interrupt handling 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.

Memory manager

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 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 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.

+ Virtual Address Space Layouts Arch MmHighestUserAddress MmSystemRangeStart x86 0x7fffffff 0x80000000 ARM x86-64 0x000007ff'ffffffff(until Windows 8.1 Update 2)0x00007fff'ffffffff(from Windows 8.1 Update 3) 0xffff8000'00000000 x86-64LA-57 0x00ffffff'ffffffff 0xff000000'00000000

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 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.

See also Architecture of Windows NT Windows NT Startup Process

Notes As mentioned in Windows Internals Book 7th edition, the boot-time option increaseuserva and corresponding header in executable image is required for this feature.

References

Ntoskrnl.exe

Bron en licentie