ntoskrnl.exe

Source: Wikipedia, the free encyclopedia.
This article is about a computer file that contains a part of the Windows NT kernel. For the Windows NT kernel itself, see Architecture of Windows NT.

ntoskrnl.exe (short for

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).[1]

Overview

x86 versions of ntoskrnl.exe depend on bootvid.dll,

architecture
-independent kernel initialization function. Because it requires 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 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 filenames
32-bit Windows
Filename Supports
SMP 		Supports
PAE
32-bit kernel
ntoskrnl.exe No No
ntkrnlmp.exe Yes No
ntkrnlpa.exe No Yes
ntkrpamp.exe Yes Yes
64-bit kernel (x64 editions)
Filename Supports
SMP 		Supports
57 bit VA
ntkrnlmp.exe Yes No
ntkrla57.exe Yes Yes

Routines in ntoskrnl use prefixes on their names to indicate in which component of ntoskrnl they are defined.

Since not all functions are being exported by the kernel, function prefixes ending in i or p (such as Mi, Obp, Iop) are internal and not supposed to be accessed by the user. These functions contain the core code and implements important checks, such as for vulnerabilities, missing arguments and exception handling.

The following table lists some of them.

NT function prefixes
Prefix Meaning
Cc File system cache[2]
Cm Configuration Manager, the kernel mode side of Windows Registry
Csr Functions used to communicate with the Win32 subsystem process, csrss.exe (csrss stands for client/server runtime sub-system)
Dbg Debugging aid functions, such as a software break point
Ex Windows executive, an "outer layer" of Ntoskrnl.exe
Exp Windows executive private (routines intended for the internal use of Windows Executive)
FsRtl File system runtime library[3]
Io I/O manager[4]
Iop Internal and base code for the I/O Manager
Ke Core kernel routines[5]
Ki Internal core routines
Kx
Interrupt handling, semaphores, spinlocks, multithreading and context switching
functions
Ky Internal and stub functions that generate a trap frame and call Kx-prefixed functions
Ks Kernel streaming
Kx Internal functions for acquiring spinlock and semaphore implementations
Ldr NT's PE Executables loader
Ldrp Internal base code for the PE Loader, usually just PE relocate implementation.
Lpc Local Procedure Call, an internal, undocumented, interprocess or user/kernel message passing mechanism
Lsa Local Security Authority
Mm Memory management
Mi Memory management routines not exported for call outside the memory manager (i = internal)
Nls Nls for Native Language Support (similar to code pages).
Ob
Object Manager
Obp Internal base code for the Object Manager
Pfx Prefix handling
Po Plug-and-play and power management[6]
Ps Process and thread management (task management)
Psp Internal base code for the Task manager
Rtl Runtime library, i.e., many utility functions that can be used by native applications, yet don't directly involve kernel support
Rtlp Runtime library private (for internal use only)
Se Security Manager, access token for the Win32 API
Sep Internal base code for the Security Manager
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 (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not.[7]

Initialization

When the kernel receives control, it gets a struct-type pointer from

Registry hive, nls for character encoding conversion, and vga font).[8] The definition of this structure can be retrieved by using the kernel debugger or downloading it from the Microsoft symbol database.[9][page needed
]

In the

TSS ready.[further explanation needed] But since it does not know the address of each one, it has to load them one by one to fill the PCR structure.[jargon
]

The main entry point of ntoskrnl.exe performs some system dependent initialization then calls a system independent initialization then enters an idle loop.[contradictory]

Interrupt handling

This article is about NT implementation of interrupt handlers. For other uses, see
Interrupt handling
.

Modern operating systems use interrupts instead of I/O port polling to wait for information from devices.

In the

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

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 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.[10]

Memory manager

This article is about NT implementation of a memory manager. For other uses, see memory management.

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[9]
Arch MmHighestUserAddress MmSystemRangeStart
x86[a] 0x7fffffff 0x80000000
ARM
x86-64 0x000007ff'ffffffff 0xffff8000'00000000

Registry

Further information: Windows 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.[11] 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

Further information: Device driver

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

Notes

  1. ^ Tunable via /userva or /3gb switch.

References

  1. ^ Russinovich, M: Systems Internals Tips and Trivia, SysInternals Information
  2. Microsoft Corporation
    . Retrieved 2009-06-13.
  3. Microsoft Corporation
    . Retrieved 2009-06-13.
  4. Microsoft Corporation
    . Retrieved 2009-06-13.
  5. Microsoft Corporation
    . Retrieved 2009-06-13.
  6. Microsoft Corporation
    . Retrieved 2009-06-13.
  7. ^ The NT Insider (August 27, 2003). "Nt vs. Zw - Clearing Confusion On The Native API". OSR Online. 10 (4). OSR Open Systems Resources. Retrieved 2013-09-16.
  8. ^ "struct LOADER_PARAMETER_BLOCK". www.nirsoft.net.
  9. ^
    ISBN 978-1118787311
    .
  10. Microsoft Corporation
    . Retrieved 2018-11-11.
  11. ISBN 978-0136006633
    .

Further reading

External links
Retrieved from "https://en.wikipedia.org/w/index.php?title=Ntoskrnl.exe&oldid=1217383799"