ntoskrnl.exe

This article is about a computer file that contains a part of Windows kernel, among other things. For the Windows NT kernel itself, see Architecture of Windows NT.

ntoskrnl.exe (Short for Windows NT operating system kernel,) also known as kernel image, provides the kernel and executive layers of the Windows NT kernel space, and is responsible for various system services such as hardware virtualization, 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.[1]

Overview

This system binary is not a native application (in that it is not linked against ntdll.dll), instead containing a standard 'start' entry point, a function that calls the architecture-independent kernel initialization function. While ntoskrnl.exe is not linked against ntdll.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 2MB in size.

Overall, there are four kernel image files. 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 processor's features.

Kernel image filenames
Filename Supports
SMP
Supports
PAE
NTOSKRNL.EXE No No
NTKRNLMP.EXE Yes No
NTKRNLPA.EXE No Yes
NTKRPAMP.EXE Yes Yes

Windows kernel coding typically uses Hungarian notation for type names, but not for variable names.

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.

NT function prefixes
Prefix Meaning
Cc File system cache[2]
Csr functions used to communicate with the Win32 subsystem process, csrss.exe (csrss stands for client/server runtime sub-system)
Dbg are 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 (p = private)
FsRtl file system runtime library[3]
Io I/O manager[4]
Ke core kernel routines[5]
Ki routines in the kernel that are not exported for call from outside the kernel (i = internal)
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 (similar to code pages).
Ob Object Manager
Pfx Pfx for prefix handling.
Po Plug-and-play and power management[6]
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
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 (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not.[7] The Zw prefix does not stand for anything.[8]

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 (SYSTEM Registry hive, nls for character encoding conversion and vga font).[9] The definition of this structure can be retrieved by using the kernel debugger or downloading it from the Microsoft symbol database.[10]

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

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 x86 architecture, interrupts are handled through the Interrupt Dispatch Table (IDT). When a device triggers an interrupt, the interrupt flag (IF) in the flags register is set and the processor's hardware looks for an interrupt handler in the table entry corresponding to the interrupt number, or IRQ. Interrupt handlers usually save the state of all or some registers before handling it and restore the registers when done.

The interrupt table contains handlers for hardware interrupts, software interrupts, and exceptions. One example of a software interrupt handler (there are many others) is in table entry 0x2e. It points to the KiSystemService.

Memory manager

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

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.

Start and end of segments by access privilege[10]
Arch MmHighestUserAddress MmSystemRangeStart
x86 0x7fffffff 0x80000000
ARM 0x7fffffff 0x80000000
x86-64 0x000007ff'ffffffff 0xffff8000'00000000

The entire physical memory (RAM) address range is broken into many small (usually 4 KB) 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 (CR3).

Registry

For more details on this topic, see 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 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 transverses that tree looking for services tagged as kernel services.

Issues

Since the release of Windows 10, there were numerous reports of memory leaks caused by the ntoskrnl.exe for users who upgraded their computers from a previous version of Windows.[12] Some suggested fixing the problem by updating incompatible or outdated drivers, scanning for malwares, and/or disabling the Windows help tip which would disable the Runtime Broker.[13]

See also

References

  1. Russinovich, M: Systems Internals Tips and Trivia, SysInternals Information
  2. Microsoft Corporation (2009). "Cache Manager Routines". Microsoft Corporation. Retrieved 2009-06-13.
  3. Microsoft Corporation (2009). "File System Runtime Library Routines". Microsoft Corporation. Retrieved 2009-06-13.
  4. Microsoft Corporation (2009). "I/O Manager Routines". Microsoft Corporation. Retrieved 2009-06-13.
  5. Microsoft Corporation (2009). "Core Kernel Library Support Routines". Microsoft Corporation. Retrieved 2009-06-13.
  6. Microsoft Corporation (2009). "Power Manager Routines". Microsoft Corporation. Retrieved 2009-06-13.
  7. The NT Insider (August 27, 2003). "Nt vs. Zw - Clearing Confusion On The Native API". OSR Online. OSR Open Systems Resources. 10 (4). Retrieved 2013-09-16.
  8. Raymond Chen (2009). "The Old New Thing : What does the "Zw" prefix mean?". Microsoft Corporation. Retrieved 2009-06-13.
  9. http://www.nirsoft.net/kernel_struct/vista/LOADER_PARAMETER_BLOCK.html
  10. 1 2 Practical Reverse Engineering Using X86, X64, Arm, Windows Kernel, and Reversing Tools. John Wiley & Sons Inc. 2014. ISBN 978-1118787311.
  11. Tanenbaum, Andrew S. (2008). Modern operating systems (3rd ed.). Upper Saddle River, N.J.: Pearson Prentice Hall. p. 829. ISBN 978-0136006633.
  12. "High Memory usage by ntoskrnl.exe System after upgrading to windows 10 home". answers.microsoft.com. Retrieved 2016-01-28.
  13. "Windows 10: How to fix system ntoskrnl.exe memory leak and high CPU usage". International Business Times UK. Retrieved 2016-01-28.

Further reading

External links

This article is issued from Wikipedia - version of the 9/18/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.