| |
|
|
|
| |
|
| Warm Boot |
|
Rebooting a system by means of a software command rather than turning the power off and back on.
When the computer is powered on the System BIOS begins its complex and convoluted POST sequence of duties when the CPU is reset, i.e., powered on, cold or warm boot. To ascertain a warm boot or a cold boot the ROM BIOS starts up routines to check the value of two bytes located at memory location 0000:0472. Any value other than 1234h or 0x1234 (indicating a warm boot) indicates that it is a cold boot.
See: Basic Input/Output system (BIOS), Cold Boot, and Rebooting. POST (Power-On-Self-Test) |
|
| |
|
| Windows File Protection (WFP) |
|
In addition to its important role as the interactive logon interface and Session Manager, Winlogon also implements through three possible registry key settings for System File Checker (SFC) scan (SFCscan) at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Windows File Protection (WFP). WFP, which is implemented in the two DLLs in the System32 folder, sfc.dll and sfc_os.dll, monitors in the background several directories for changes to key drivers, executables, and DLLs, including most subdirectories under \Windows.
When WFP detects a change of a critical Windows system file listed in \System32\Sfcfiles.dll by a program, it receives a directory change notification from a file in the protected directory. Once WFP determines a file has been changed it checks to see whether the file is digitally signed by Microsoft looking in the catalogue. If the file is digitally signed, WFP allows the change and copies the file to the default WFP backup directory or (cache folder, Dllcache) by default at %systemroot%\system32\DllCache if present. WFP stores verified file versions in the Dllcache folder on the volume. If the default size of 400MB (SFCQuote value 0xFFFFFFFF; this can be increased or decreased), is set, approximately 2,7000 files are stored in the Dllcache folder. Service packs (using Update.exe), hotfixes (using Update.exe), operating system upgrades using Winnt32 always install Microsoft signed system files.
For file modifications that do not result in a file that is Microsoft-signed, WFP replaces the modification in the following order:
- With the backup version of the file from the %systemroot%\system32\DllCache and the file silently replaced. If the WFP cannot automatically locate the file it will present a message, if the Administrator is logged on or after an Administrator logs on; recording an event in the system event log noting the file replacement attempt, that it will be replace by method 2 and 3.
- If Winlogon cannot find a backup version in %systemroot%\system32\DllCache, it checks in the network install path if the system was installed using a network install.
- The Windows CD-ROM setup media (for the original file(s)), if installed from CD-ROM.
SFC (the second protection mechanism, (Sfc.exe)) can be used to search all protected files, to ensure that they have not been modified by unattended program installation, and replace system files with a valid version using the catalogue that is used to track correct file versions. If any file is damaged or missing, WFP renames the affected catalogue file and retrieves a version from %systemroot%\system32\DllCache. Method 2 and 3 are carried out if this is not possible. Moreover, SFC can scan all protected files to verify their version, checks and repopulates %systemroot%\system32\DllCache as it does. If the cache folder is damaged in any way, using sfc / scanonce (registry key values is 0x1, if run) or sfc / scanboot (registry key value 0x2), is run) at the command prompt, SFC will repair the contents of the folder. The default, (registry value is 0x0), prohibiting a scan of protected file after a restart.
In addition, all drivers in the Driver.cab file are protected; however they are not populated in the Dllcache folder. WFP can restore these files from the Driver.cab file directly without prompting the user for the source media. However, running the sfc /scannow command does populate the files from the Driver.cab file into the Dllcache folder. If WFP detects a file change and the affected file is not in the cache folder, WFP examines the version of the changed file that the operating system is currently using. If the file that is currently in use is the correct version, WFP copies that version of the file to the cache folder. If the file that is currently in use is not the correct version, or if the file is not cached in the cache folder, WFP tries to locate the installation source. If WFP cannot find the installation source, WFP prompts an administrator to insert the appropriate media to replace the file or the cached file version.
When Windows starts, WFP synchronises (copies) the WFP settings from the following registry key:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File Protection
In turn to the registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Therefore, if the SfcScan, SFCQuota, or SFCDllCacheDir values are present in the registry subkey:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File Protection
Then these values take precedence over the same values in the registry subkey:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
See: Windows NT-Based Startup Phases. |
|
| |
|
| Windows Kernel (Lower Windows Executive) |
|
Simply put, the kernel, or hybrid kernel, (the lowest layer in Ntoskrnl.exe and a component of the executive situated between the Hardware Abstract Layer (HAL) and the Executive) is the operating system’s core component consisting of a set of functions in Ntoskrnl.exe that provides the fundamental (basic level) mechanisms (operations), such as, thread (blocks of executing code), scheduling (pre-emption) and multi-processor synchronisation (to optimise performance), used by the executive components, as well as allowing low-level hardware architecture-dependent support, such as, interrupt and exception scheduling and dispatching, trap handling and exception dispatching that are different on each processor architecture, to keep it as busy as possible.
As mentioned, the kernel provides a low-level base of well-defined, predictable operating system primitives and mechanisms that allow higher-level components of the executive to do what they need to do. The kernel separates itself from the rest of the executive by implementing operating system mechanisms so avoiding policy making. It leaves almost all policy making decisions to the executive, with the exception of thread scheduling and dispatching.
Another important role of the kernel is to abstract or isolate the executive and device drivers from variations between the hardware architecture by Windows. This job involves handling variations in functions such as interrupt handling, exception dispatching, and multi-processor synchronisation.
The kernel also synchronises activities among executive-level sub-components, such as the I/O Manager and Process Manager, and handles hardware exceptions and other hardware-dependent functions. The kernel works closely with the hardware abstract layer (HAL), drivers and Executive, which all exist in kernel mode.
To protect user applications from accessing and/or modifying critical operating system system data the architecture of the Windows NT highly modular operating system family uses two processor access modes (or layers): kernel and user mode (also referred to as Kernel Land and User Land, respectively). User application code runs in user mode (non-privileged processor mode or slave mode), comprising of two subsystems; the Environment (Win32: Win64; 32-bit: 64-bit) running applications; Integral: consisting of a security subsystem (dealing with security tokens, grants or denies access to user accounts based on resource permission, handles logon requests and initiates logon authentication; besides overseeing the Active Directory), a workstation service (an API (Application Programming Interfaces)) to the network redirector, providing access to the network and a server service (an API that allows the computer to provide network services)) operating specific functions on behalf of the Environment ((Win32 or Win64) subsystem) capable of passing I/O requests to the appropriate kernel mode software drivers by using the I/O Manager (existing in kernel mode), so that errant applications cannot disrupt the stability of a system as a whole as it does not have direct access to the code and data of the privileged part of the operating system. Operating system code on the other hand, such as system services and kernel mode device drivers (existing in three levels: highest, intermediate and low) run in the unrestricted environment of kernel mode (other designations being master mode, supervisor mode, and privileged mode etc) and only then when absolutely necessary. Kernel mode (privileged processor mode) refers to the mode of execution in a processor that grants access to all system memory and all CPU instructions; providing the operating system software with a higher privilege level than the applications software. The Executive interfaces with all the user mode subsystems.
Note: Windows provides several base mechanisms which kernel-mode (or Ring 0) components such as the kernel and HAL uses and, various components of the Windows kernel (e.g., I/O Manager, Memory Manager, and Process Manager) and several core device drivers (e.g., graphic interface), that are instrumented to record trace data of their operation for use in system troubleshooting. Code executing at the Ring 0 privilege level runs with full system privileges so full memory access and the ability to execute privileged instructions are available. User-mode is Ring 3 and the Windows NT family operating system’s security model restricts user mode processes such as applications and system services from arbitrarily switching to Ring 0. Nevertheless, user processes, for example, will at times need the freedom and power of the kernel level. The Native API internal functions execute within kernel mode using the interrupt 0x2 (via the INT 0x2e instruction) under Windows 2000 and Windows XP/Server 2003 using the instruction pair SYSENTER and SYSEXIT, making the transition between the two privilege levels, therefore bridging this need and offering a safer means of calling kernel mode services from user mode. The i396 architecture supports a ring-based security schema consisting of four rings (or protection rings) in total or privilege levels. The Windows NT family operating system uses only two protection rings; ring 0 (kernel mode with the highest privilege; most trusted) is the level with the highest privilege rating and interacts most directly with physical hardware such as the CPU and memory and ring 3. Special gates between rings provide access of an outer (higher numerical ring) to access an inner ring’s resources in a predefined manner, as opposed to allowing arbitrary usage. Windows XP does not exploit the ring-based security schema fully (using only two rings: 0 and 3), unlike the operating system OS/2 (using three rings). Ring protection can be combined with processor modes (master, kernel, privileged, and supervisor versus slave, user, and unprivileged) in some systems. Often the security model is simplified to kernel and user even if hardware provides finer granularity through rings.
See: Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6), Processes & Thread, Windows Registry, and Windows Services. |
|
| |
|
| Windows NT Architecturally Based Operating Systems |
|
Microsoft’s Windows NT family operating systems are all (symmetric multi-processing (SMP))-based Intel x86 computeroperating systems. Windows 2000/XP (Home and Pro)/Server 2003 (built on the proven reliability, scalability, and manageability of Windows 2000 Server) are 32-bit pre-emptive multi-tasking (the operating system has the ability to stop a currently scheduled task or process in favour of a higher priority task), re-entrant operating systems. Windows XP/Server 2003 operating systems support two types of multi-processor systems: hyperthreading and NUMA (non-uniform memory architecture): both operating systems are available in distinct 32-bit and 64-bit formats. Windows NT family operating systems contain no 16-bit code, other than support for running 16-bit Windows applications.
One of the main architectural design features of Windows NT family operating systems is the kernel, or hybrid kernel. The kernel is the operating system’s core component consisting of a set of functions in Ntoskrnl.exe that provides the fundamental (basic level) mechanisms (operations), such as, thread (blocks of executing code), scheduling (pre-emption) and multi-processor synchronisation (to optimise performance), used by the executive components, as well as allowing low-level hardware architecture-dependent support, such as, interrupt and exception scheduling and dispatching, trap handling and exception dispatching that are different on each processor architecture, to keep it as busy as possible.
Because the kernel provides a low-level base of well-defined, predictable operating system primitives and mechanisms that allow higher-level components of the executive to do what they need to do it separates itself from the rest of the executive by implementing operating system mechanisms so avoiding policy making. It leaves almost all policy making decisions to the executive, with the exception of thread scheduling and dispatching.
The kernel also synchronises activities among executive-level sub-components, such as the I/O Manager and Process Manager, and handles hardware exceptions and other hardware-dependent functions. The kernel works closely with the Hardware Abstract Layer (HAL), drivers and Executive, which all exist in kernel mode.
To protect user applications from accessing and/or modifying critical operating system system data the architecture of the Windows NT highly modular operating system family uses two processor access modes (or layers): kernel and user mode (also referred to as Kernel Land and User Land, respectively). User application code runs in user mode (non-privileged processor mode or slave mode), comprising of two subsystems; the Environment (Win32: Win64; 32-bit: 64-bit) running applications; Integral: consisting of a security subsystem (dealing with security tokens, grants or denies access to user accounts based on resource permission, handles logon requests and initiates logon authentication; besides overseeing the Active Directory), a workstation service (an API to the network redirector, providing access to the network and a server service (an API (Application Programming Interfaces)) that allows the computer to provide network services)) operating specific functions on behalf of the Environment ((Win32 or Win64) subsystem) capable of passing I/O requests to the appropriate kernel mode software drivers by using the I/O Manager (existing in kernel mode), so that errant applications cannot disrupt the stability of a system as a whole as it does not have direct access to the code and data of the privileged part of the operating system. Operating system code on the other hand, such as system services and kernel mode device drivers (existing in three levels: highest, intermediate and low) run in the unrestricted environment of kernel mode (other designations being master mode, supervisor mode, and privileged mode etc) and only then when absolutely necessary. Kernel mode (privileged processor mode) refers to the mode of execution in a processor that grants access to all system memory and all CPU instructions; providing the operating system software with a higher privilege level than the applications software. The Executive interfaces with all the user mode subsystems.
Note: Windows provides several base mechanisms which kernel-mode (or Ring 0) components such as the kernel and HAL uses and, various components of the Windows kernel (e.g., I/O Manager and Memory Manager) and several core device drivers (e.g., graphic interface), that are instrumented to record trace data of their operation for use in system troubleshooting. Code executing at the Ring 0 privilege level runs with full system privileges so full memory access and the ability to execute privileged instructions are available. User-mode is Ring 3 and the Windows NT family operating systems security model restricts user mode processes, such as applications and system services from arbitrarily switching to Ring 0. Nevertheless, user processes, for example, will at times need the freedom and power of the kernel level. The Native API internal functions execute within kernel mode using the interrupt 0x2 (via the INT 0x2e instruction) under Windows 2000 and Windows XP/Server 2003 using the instruction pair SYSENTER and SYSEXIT, making the transition between the two privilege levels, therefore bridging this need and offering a safer means of calling kernel mode services from user mode. The i396 architecture supports a ring-based security schema consisting of four rings (or protection rings or privilege levels) in total. The Windows NT family operating system uses only two protection rings; ring 0 (kernel mode with the highest privilege; most trusted) is the level with the highest privilege rating and interacts most directly with physical hardware such as the CPU and memory) and ring 3. Special gates between rings provide access of an outer (higher numerical ring) to access an inner ring’s resources in a predefined manner, as opposed to allowing arbitrary usage. Windows XP does not exploit the ring-based security schema fully (using only two rings: 0 and 3), unlike the operating system OS/2 (using three rings). Ring protection can be combined with processor modes (master, kernel, privileged, and supervisor versus slave, user, and unprivileged) in some systems. Often the security model is simplified to kernel and user even if hardware provides finer granularity through rings.
The amount of work a digital computer can do in a clock cycle is dependent on the width of its register. If Windows is a 32-bit operating system then the processor execution is in 32-bit protected mode. If Windows is a 64-bit operating system then the processor execution is in 64-bit protected mode. A 32-bit computer can do twice as much work per clock cycle as an otherwise-identical 16-bit computer; a 64-bit computer can do twice as much again compared to a 32-bit computer.
There are three important mechanisms involved with the management infrastructure of Windows: the registry, services, and Windows Management Instrumentations (WMI; \Windows\System32\Winmgmt.exe), which the Windows Service Control Manager (SCM) starts the first time a management application or WMI provider (loaded as in-process DCOM servers that execute within the Winmgmt service process) tries to access WMI APIs. In Windows XP and Server 2003, the WMI service runs in a shared Svchost process that executes in the local system account; loads providers into the Wmiprvse.exe (as a child of the RPC service) provider-hosting process, executes it in the local system, local service, or network service accounts and them closes after receiving the last provider request.
See: Device Drivers (location - systemroot\System32\Drivers - Windows NT-based operating system system startup file #9), FAT (12-, 16-, and 32-bit), File Allocation Table, Filesystem, Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), NTFS (New Technology Filesystem), Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6), Processes & Threads, Windows Services, Processes & Thread, Registry, Windows Kernel (Lower Windows Executive), Windows Services. |
|
| |
|
| Windows Startup Phases NT-Based |
|
When a computer (also referred to as a general-purpose computer or PC) is powered on to operate, each power supply unit (PSU) completes internal checks and tests before allowing the system to start. If the tests are completed successfully without incident, the PSU sends a special signal to the motherboard called the Power_Good (or Power_OK or POK) signal. It takes a few moments to generate reliable and stable power (between 0.1 to 0.5 seconds) for the rest of the computer. If the POWER_GOOD signal is not continuously present, the computer will not run. In short, the PSU actually prevents the computer from starting up or operating until all the correct power levels are present.
There was a time when the System BIOS, that all motherboards have and in some cases two single-chip BIOSes; rudimentary yet very important software that boots the system initially, contained all the device drivers such as, keyboard, video adapters, serial and parallel ports, floppy controller, hard disk drive controller for the entire system, Power-On Self Test (POST) routine and bootstrap loader all burned into one or more non-volatile motherboard (True or Mask) ROM (Read-Only Memory) chips of finite capacity. In essence, the device drivers were once self-contained, preloaded into memory and accessible anytime the PC was powered on. However, the old styled motherboard ROM chip is no longer used as a more advanced non-volatile EEPROM memory chip is used. The advantage of the EEPROM chips is that it can be electrically programmed partially or completely while in situ. Since 1994, motherboards have tended to use EEPROM chips for their reprogramming ease as well as being faster; they deal with blocks of memory rather than in single bytes. The difference in speed is not significant.
On a modern (x86) computer (or 80x86 the generic name of a micro-processor architecture) the operating system and disk format independent Plug and Play (PnP) System BIOS is stored on an EEPROM memory chip sitting on a Firmware Hub (FWH interface) or Serial Peripheral Interface Bus (SPI interface), so that it can, when the computer is powered on, begin its complex and convoluted POST sequence of duties when the CPU is reset, i.e., powered on, cold or warm boot.
Nowadays, it is impossible to self-contain all necessary device drivers in the System BIOS within a motherboard's ROM chip. For this reason the BIOS, discussed later, has grown across three physically distinct locations.
One of the responsibilities of the System BIOS, and the first set of instructions once the computer is powered, is POST. One of the main duties of POST, carried out by the BIOS, is to isolate and initialise all PnP cards and assign them a valid Card Select Number (CSN) - PnP devices have a 3-character vendor specific device ID stored in the hardware so that the operating system can recognise it. After a CSN has been assigned, some of the duties of POST are actually performed by other programs designed to initialise very specific peripheral devices, notably, for video, SCSI (pronounced scuzzy) and ATA/IDE host initialisation. These other duty-specific programs are generally known collectively as option ROMs or individually as the video BIOS, SCSI BIOS, Network Interface Card BIOS and RAID BIOS and so forth – (all option ROM within adapter cards start with the signature byte 55AAAh; otherwise, the motherboard will not recognise them). The first to be summation checked and released is the video BIOS; each following thereafter. Option ROMs, stored on EEPROM chips also, contain auxiliary BIOS routines and drivers needed by the particular adapter card; complementing or superseding the System's BIOS code for the given component. An add-in adapter usually requires an option ROM if it is necessary for it to be used prior to the time that the operating system loads or are complex enough not be handled by the main BIOS directly, e.g., video and SCSI adapters. The System BIOS can scan and test many of the motherboard circuits and designate resources to the cards such as DMA channels, IRQs, I/O ports, and memory locations for these various other tested components, e.g., RAM (also known as physical memory), discover, initialise, and catalogue all system buses and devices, hard disk drives and optical disc drives, keyboard and mouse and so forth. Add-on cards/adapters carry out their own BIOS/firmware internal diagnostic tests. The BIOS must carry out an inventory of the hardware installed; then communicate or interrogate the hardware to ensure that it is functioning correctly. The BIOS Setup configuration information is stored on a motherboard chip called the RTC/NVRAM digital clock chip, where CMOS configuration information is stored and POST can refer to the hardware setup information. The BIOS is only responsible for the configuration of boot devices. Note: For all other PnP devices detection runs asynchronously during the logon process. The PnP Manager determines which drivers are required to support a particular device and loads these drivers. Any un-configured PnP devices are configured by the appropriate application software. At this point, the operating system is loaded and takes control over PnP system resources. Advanced Configuration and Power Interface (ACPI) is designed not only to control power, but also all PnP hardware configurations throughout the system. With ACPI, system configuration (PnP) as well as power management configuration is no longer controlled via the BIOS Setup; it is entirely controlled within the operating system instead, from Windows 98 onwards. Moreover, ACPI also uses the PnP BIOS data structures and controls PnP interfaces, providing an operating-system-independent interface for configuration and control.
Modern BIOSes have the additional functionality to automatically collect settings: memory timings (based on the memory type found), dynamically set a hard disk drive's parameters and access modes, display an onscreen message for each device detected and configured in this way. The BIOS must integrate the plethora of competing, evolving, and even mutually exclusive standards and initiatives for the matrix of hardware and operating systems the PC is expected to support. To the computer user, all that will be evident as POST and BIOS activity is the simple visible memory test and setup text in the form of detected hard disk drives, optical drives and adapter cards, where applicable. This is the final stage of the BIOS POST routine.
Today, all Windows NT family operating systems have been designed so that all 32-bit device drivers are loaded from disk to replace all the device drivers that once resided in the motherboard ROM (but 16-bit drivers are still used in part in real mode), such as drivers for graphics adapters, sound cards, scanners, printers, SCSI host board adapters (HBA), and many more hardware devices that are installed over time. The motherboard ROM exists only to initialise the system startup, to initialise specific hardware, to offer security in a way of a power-on-pass-word, and to perform some basic install configuration. Under these operating systems the motherboard ROM and option ROMs are used simply to get the system functional long enough to get the initial 32-bit device drivers to take over and the operating system loaded, at which point any 16-bit drivers are shut down and no longer required. 64-bit operating systems require all 64-bit device drivers to be loaded without exception. No 32-bit or 16-bit device drivers are used.
Once a Windows NT family operating system is loaded, the BIOS may be mostly in ROM, but at this time it resides entirely in RAM.
The BIOS consists of all the individual driver programs that operate between the operating system and the actual hardware. Consequently, the operating system does not communicate directly with the hardware but through the appropriate operating system specific driver supplied normally by the hardware manufacture. This provides a consistent way to communicate with the hardware and a consistent way that an operating system can be used with different hardware. There is no perceptible different to the computer user using the operating system because the drivers provide the same basic functions, so applications will be perceived as identical from system to system, but the hardware can differ substantially. Consequently, many device drivers can be loaded once the operating system is loaded.
The BIOS, once contained entirely in a single location within the motherboard ROM chip, is now constructed of programs located in three different physical locations in the system; yet it functions as a single entity because all the programs are linked together via the BIOS subroutine calling system-of-software interrupts. The combination of the motherboard BIOS, option ROMs and device drivers loaded from disk, contribute to the BIOS as a whole. The portion of the BIOS contained within the motherboard ROM and option ROM chips are often referred to as firmware.
Once all tests have been completed a beep sound comes from the internal system speaker if this initial test indicates devices are properly connected, and operating for proper system performance. If problems are found, these routines alert the user with a series of beeps or a message, often accompanied by a diagnosis numeric value. If POST is successful, it passes control to the bootstrap loader.
Specifically, before an operating system can be loaded the (x86) CPU attempts to begin the process of processing data. However, as the system memory is empty, the processor will not have anything to execute, or even begin to know where to look for it. Therefore, to ensure that the system will boot regardless of the BIOS programming instructions, both CPU and BIOS manufacturers together developed code so that the processor, once turned on, always started executing its first instruction at the default location (reset vector); initiated by a jump instruction/command at memory address/location FFFF:0000h. The actual reset vector is a pointer or address for x86 CPUs at memory address 0xFFFFFFF0, although the value of the CS register at reset is 0xF000 and the value of the IP (instruction pointer) register at reset is 0xFFFF0. Without the system's RAM address space being mapped into one of the ROM chips and its location, on powering off, the CPU would have its location to execute instruction but no instructions would exist. As it stands now, on powering off, the CPU will execute instructions on each system power on.
At the completion of POST, assuming there are no fatal problems, INT 19 is called.
The computer’s hardware alone cannot perform the complex actions of which an operating system is capable, such as loading a program from disk; so a seemingly irresolvable paradox is created. The solution to the paradox involves using a special small program, called a bootstrap loader or boot loader. This program doesn't have the full functionality of an operating system, but is tailor-made to load enough other software for the operating system to start.
Generally, INT 19 is a routine that tries to read the first physical sector from the first floppy diskette drive. If a boot sector, in this case the boot record is found on the floppy diskette, the boot sector is read/loaded into memory at location/address 0000:7C00 - INT 19 jumps, initiated by a jump instruction. The unique characteristics of an operating system and filesystem become important when the boot sector's executable code (boot code) starts.
However, if no boot sector is found on the first floppy diskette, INT 19 tries to read the first physical sector of various hard disk drives searching for a valid Master Boot Record (MBR) from the first hard disk drive. If during this INT 19 process, any other essential boot devices BIOSes are found, they are executed, i.e., SCSI ROM that potentially has a hard disk drive with a valid MBR. If on meeting certain minimum criteria (ending in a signature byte or signature word, 55AAh or 0x55AA) indicating the start of a ROM is detected, the code within the MBR is executed. If no valid MBR is found, the ROM puts into effect interrupt 18 (or INT 18) displaying a message and the boot process will stop.
The valid MBR code then continues the boot process by reading the first physical sector of the bootable volume; the start of the Volume Boot Record (VBR). The VBR (also known as the volume boot sector) then loads the first operating system startup file: IO.SYS for non-Windows NT family operating systems and Ntldr.exe (NT Loader) for the Windows NT family operating systems, upon which the operating system is then in control and continues the boot process. CMOS is a small area of memory (64-bytes) which is maintained by the current of a small battery attached to the motherboard. Most importantly for the ROM BIOS startup routines CMOS indicates the order in which devices should be examined for an operating system to load, e.g., floppy diskette device first, or optical device first, or hard disk drive first and so forth.
The first sector of the active partition contains boot code that enables the computer to do the following.
- The small program in the MBR will attempt to locate (scan) an active (bootable) primary partition in its partition table containing a flag (or marker) signalling that it is in fact bootable. If a flag is located, it reads the first sector from the flagged partition of that partition into memory at location/address 0000:7C00, transferring control to code within the partition (called the boot partition) and the first sector (boot sector) of this partition. The volume defined for the boot partition is called the system volume. Each operating system has its own boot sector format. The small program in the boot sector must locate the first part of the operating system's kernel (the lowest layer in Ntoskrnl.exe and a component of the executive (Windows Executive: Ntoskrnl.exe)) loader program and read that into memory.
If an active partition does not exist or if the boot sector information is missing or corrupt, a message similar to any of the following might appear and the boot process will stop.
- "NO ROM BASIC - SYSTEM HALTED" or "No boot device available, strike F1 to retry, F2 for setup utility" or "No boot sector on fixed disk, strike F1 to retry boot, F2 for setup utility" or "Non-System disk or disk error, replace and strike any key when ready" or "DISK BOOT FAILURE, INSERT SYSTEM DISK AND PRESS ENTER". (Solution: Set a primary partition to "active", partition the hard disk drive and then set the primary partition to "active". Each partition table entry is 16-bytes long, with a maximum of four entries, each with a Boot Indicator byte: these bytes are at offset 446 (partition table entry #1 (0x1BE or 1BEh)), at offset 462 (partition table entry #2 (0x1CE or 1CEh)), at offset 478 (partition table entry #3 (0x1DE or 1DEh)), and finally at offset 494 (partition table entry #4 (0x1EE or 1EEh)). These Boot Indicators are used to determine if the partition is active (bootable) by checking for the value 0x80 or 80h. The remaining Boot Indicators will have a value of 0x00 or 00h. Consequently, if all four table entries have 00h then the MBR returns control to the motherboard ROM, putting into effect interrupt 18 (INT 18) and the boot process stops). .
- "Invalid partition table". The source of the error message is the MBR. There is more than one Boot Indicator byte with a value of 0x80 or 80h - more than one partition marked "active." (Solution: deactivate the non-booting partitions. However, a thorough investigation of the partition table may be necessary, since the actual problem may be more complex). .
- "Error Loading Operating system". The source of the error message is the MBR. An error was returned from the BIOS when the boot loader attempted to read the active partition's boot sector into memory. (Solution: In many cases this will be due to a "soft" ECC error and can be repaired by rewriting the boot sector.)
- "Missing operating system” or “Operating system not found". The source of the error is BIOS related. The MBR is corrupted due to any of the reasons mentioned above. However, it is primarily related to small capacity hard disk drives where the translation settings are changed from LBA to CHS. The bootstrap loader in the BIOS translates drive sector locations differently and possibly incorrectly. For this reason the valid MBR's location and in turn the VBR will not be where they are expected to be; they are lost. (Solution: firstly, for hard disk drives of 528MB (504MiB) through to 8.4GB (7.9GiB) reverse the translation mode. Alternatively, rebuild the MBR and partition table using Recovery Console command "fixmbr". Any boot problems can be corrected using "fixboot").
- The small program in the boot sector must locate the first part of the operating system’s kernel (the lowest layer in Ntoskrnl.exe and a component of the executive (Windows Executive: Ntoskrnl.exe)) loader program and read that into memory. See . Ntldr.exe is loaded (or read) into memory. In some cases the kernel itself or a boot manager program is read into memory. This process will occur on a cold boot (all RAM being forcibly cleared), or warm boot. Note: ntlder.exe (NTLDR or NT Loader) is the boot loader for Windows NT family operating systems, including later versions (2000/XP/Server 2003 but not Windows Vista, which divides the functionality of NTLDR between two new components: winload.exe and the Windows Boot Manager). Ntldr.exe requires, at a minimum, the following two files to be on the system volume: Ntldr.exe, which contains the main boot loader itself, and Boot.ini, which contains configuration options for a boot menu. To load a Window NT family operating system, ntdetect.com must also be present. The VBR written to disc by the Windows NT format command attempts to load and to run the NTLDR program.
If an active partition is successfully loaded, the code in the boot sector locates and starts Ntldr and the BIOS releases control to it. However, if a message similar to any of the following appears the boot process will stop.
- "BOOT: couldn't find Ntldr". (Solution: see Boot.ini entry pertaining to the bootcfg /rebuild (Windows XP Recovery Console (RC) command).
- "NTLDR missing". The boot loader was unable to locate NTLDR. Very often this indicates a corrupted file system. (Solution: Using the RC, copy a new NTLDR file from directory \i386 on the Windows XP/2000/Server 2003 Setup CD-ROM using CD \, then ATTRIB -C NTLDR. Otherwise use the bootcfg /rebuild (Windows XP Recovery Console command)).
- "NTLDR is compressed". The NTLDR file is compressed. As NTLDR is necessary prior to the operating system loading, normal booting is prevented as there is no way to decompress the compressed NTLDR file. (Solution: Using the RC, copy a new NTLDR file from directory \i386 on the Windows XP/2000/Server 2003 Setup CD-ROM using CD \, then ATTRIB -C NTLDR. Otherwise use the bootcfg /rebuild (Windows XP Recovery Console command)).
The sequence of events, described above.
Boot Loader Phase:
Ntldr loads startup files from the boot partition and then does the following:
- Sets an x86-based processor to run in 32-bit flat memory mode: An x86-based computer first starts in real mode. In real mode, the processor disables certain features to allow compatibility with software designed to run 8-bit and 16-bit processors. Ntldr then switches the processor to 32-bit mode, allowing access to a large amount of memory and enabling Windows NT family operating systems to start.
- Starts the filesystem: Ntldr contains the program code that Windows NT family operating systems need to read and write to hard disk drives with the NTFS or file allocation table (FAT16 or FAT32) filesystem.
- Reads the Boot.ini file: Ntldr parses the Boot.ini file to determine the location of the operating system system boot partition. For systems that use a single-boot configuration, Ntldr initiates the hardware-detection phase by starting Ntdetect.com. For multiple boot configurations that include Windows NT family operating systems, the boot-selection menu is created. Choosing one of the Windows NT family operating systems, Ntldr proceeds with the hardware-detection phase. If a non-Windows NT family operating system is chosen, control is passed to the boot sector of the other operating system. Ntldr passes control to Bootsect.dos.
- Hardware Detection & Configuration Phase: After processing the Boot.ini file, Ntldr starts Ntdetect.com. Ntdetect.com collects information about installed hardware by calling to System BIOS (firmware) routines. Ntdetect.com then passes this information back to Ntldr. Ntldr gathers the data received from Ntdetect.com and organises the information into internal data structures. Ntldr then passes Boot.ini information, as well as hardware and software data in the registry, to Ntoskrnl.exe (the kernel being the lower layer; the Windows executive being the upper layer) and provides it with information obtained from Ntdetect.com. Ntdetect.com detects hardware profile information and checks for information stored in Advanced Configuration Power Interface (ACPI) tables. ACPI defines a method for integrating power management as well as system configuration features throughout the computer, including the hardware, operating system, and application software. Moreover, not only does ACPI control power, but also all PnP hardware configurations throughout the system. With ACPI, system configuration (PnP) as well as power management configuration is no longer controlled vial the BIOS Setup; it is entirely operating system controlled from Windows 98 onwards. ACPI also uses the PnP BIOS data structures and controls PnP interfaces, providing an operating-system-independent interface for configuration and control. Nevertheless, Ntdetect.com plays a greater role for device enumeration in computers that are non-ACPI compliant because in those computers, the firmware, not the operating system, determines the resources assigned to devices. ACPI-compliant firmware enables Windows compliant operating systems to detect power management features and assign the device hardware resources. During this phase, Ntdetect.com searches for hardware profile information. Windows NT family operating systems create a single default profile for desktop computers, while creating a default profile for portable computers.
Kernel Loading Phase:
Ntldr is responsible for loading the core operating system component, the Windows kernel hybrid kernel, (the lowest layer in Ntoskrnl.exe and a component of the executive situated between the Hardware Abstract Layer (HAL) and the Executive) and HAL into memory. The kernel provides a low-level base of well-defined, predictable operating system primitives and mechanisms that allow higher-level components of the executive to do what they need to do. The kernel separates itself from the rest of the executive by implementing operating system mechanisms so avoiding policy making. It leaves almost all policy making decisions to the executive, with the exception of thread scheduling and dispatching. Although there are a number of HAL files to choose from during installation, a Windows NT family operating system’s Setup copies the most applicable HAL file to the system disk and then renames the file to Hal.dll. Therefore the Hal.dll file can vary from system to system (See. The kernel also synchronises activities among executive-level sub-components, such as the I/O Manager and Process Manager, and handles hardware exceptions and other hardware-dependent functions. The kernel works closely with HAL, drivers and the Executive, which all exist in kernel mode. Together, the kernel and HAL initialise groups of software components that are called the Windows executive. The Windows executive (upper layer of Ntoskrnl.exe) processes the configuration information stored in registry control sets, and starts services and drivers.
Control Sets
Ntldr reads control set information from the HKEY_LOCAL_MACHINE\SYSTEM registry key, which is created from information in the systemroot\System32\Config\System file, so that Ntldr can determine which device drivers are needed during startup – generally, 80 start-load drivers are loaded during a normal Windows startup. Generally, several control sets exist, with the actual number depending on how often system configuration settings change.
Typical registry control set subkeys are:
- \CurrentControlSet: A symbolic registry link that points to one of the copies, e.g., ControlSetnnn subkey with nnn representing a control set number, such as 001) designated in the \Select\Current entry.
- \Clone: A copy of CurrentControlSet, created each time the computer is started.
- \Select: Contains the following entries:
- Default: Points to the control set number, e.g., 001= ControlSet001, that the system has specified for use at the next startup. If no error or manual invocation of the LastKnownGood startup options occurs, this control set number is designated as a value of the Default, Current, and LastKnownGood entries. Assuming that a user is able to log on successfully. In more detail, the system charges the Service Control Manager (SCM) with determining when the system’s registry configuration, HKLM\SYSTEM\CurrentControlSet, should be saved as the Last Known Good Configuration control set. Once the successful auto-start process of services is complete, Winlogon notifies SCM when there is a successful logon, and SCM will save the current registry startup configuration as part of the LastKnownGood control set.
- Current: Points to the last control set which was used to start the system.
- Failed: Points to a control set that did not start a Windows NT family operating system successfully. This value is updated when the LastKnownGood option is used to start the system.
- LastKnownGood: Points to the control set that was used during the last user session. When a user logs on, the LastKnownGood control set is updated with configuration information from the previous user session. In more detail, the system charges the SCM with determining when the system’s registry configuration, HKLM\SYSTEM\CurrentControlSet, should be saved as the Last Known Good Configuration control set. Once the successful auto-start process of services is complete, Winlogon notifies SCM when there is a successful logon, and SCM will save the current registry startup configuration as part of the LastKnownGood control set.
Ntldr uses the control set identified by the Default values unless the user chooses the Last Known Good Configuration from the Windows Advanced Options menu.
The kernel uses the internal data structures provided by Ntldr to create one of the systemwide configuration subkeys HKLM\HARDWARE (hive file path: volatile hive), which contains the hardware data collected at system startup. The HARDWARE subkey maintains hardware-orientated information, such as the system’s hardware and all hardware device-to-driver mappings; probably the most important task, connecting the operating system with hardware installed on a particular computer the registry performs. The Device Manager applet is a GUI representation of the information read directly from the HARDWARE subkey. To monitor the kernel load process, watch the Starting Up progress indicator that appears during startup. For the most important event pertaining to the progress bar, see
Service Packs (or Service Releases such as Windows 2000 SP1 through to SP4, Windows XP SP1 though to SP2 or Windows Server 2003 SP1 or RC2) includes, besides other things, additional device drives that are not available on the original operating system CD-ROM.
Drivers are kernel-mode components required by devices to function within an operating system. Services are components that support operating system functions and applications. Services can run in a different context than user applications and typically do not offer many user-configurable options. A number of Windows components are implemented as services, e.g., Event Log, Spooler, Task Scheduler, and various networking components and do not require a user to be logged on to run, acting independently of the user who is logged on to the system. Windows NT family operating system driver and service files are typically stored in the systemtoot\System32 and systemroot\System32\Drivers folder and use .exe, .sys, or .dll file named extensions.
Drivers are also services. Therefore during kernel initialisation, Ntldr and Ntoskrnl.exe use the information stored in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\servicename registry subkeys to determine both the drivers and the services to load. For example, Ntldr searches for Services subkeys for drivers with a Start value of 0, such as hard disk drive controllers. After Ntldr starts Ntoskrnl.exe, an Ntoskrnl.exe component searches for and starts drivers, such as network protocols, that have a Start value of 1. Regardless of their Start value, boot drivers (those with a value of 0) and filesystem drivers are always loaded, as they are necessary in order to start the operating system.
Certain drivers and services require that certain dependencies be met before they start. For details on dependencies, these can be found under DependOnGroup: At least one item from this group must start before this service is loaded. The subkey SYSTEM\CurrentControlSet\Control\ServiceGroupOrder contains the service group load order and the DependOnService lists the dependent service, in order to load successfully entries in the HKEY_LOCAL_MACHINE\CurentControlSet\Services\serviceame subkey for each service or driver.
Session Manager (smss.exe)
All entries with Boot and Startup data types are processed, the kernel starts the Son of the Kernel, Session Manager (smss.exe) - the first user-mode component/process and the only parentless process to be created and loaded during a boot. The Ntoskrnl.exe initialises the Session Manager using its functions RtlCreateUserThread and RtlCreateUserProcess. The Session Manager is like any other user-mode process except that Windows considers it a trusted part of the operating system, and so it is the kernel-mode system thread that performs the final stage of the initialisation of the executive and kernel that creates the actual Smss process. Smss is also a native application performing important initialisation functions also, e.g., responsible for a number of important steps in Windows startup, such as opening additional page files, performing delayed file rename and delete operations, and creating system environment variables. It also launches the subsystem process, i.e., Csrss.exe, and the Winlogon process, which in turn creates the rest of the system processes. As Smss is a trusted operating system component, it can perform actions few other processes can, i.e., creating security tokens. As Smss is a native application, it uses only core executive APIs because the Windows subsystem (an environment subsystem that is required for Windows to run) is not executing when Smss launches. In fact, Smss is responsible, and it is one of its first tasks, to launch the Windows subsystem. Smss then calls the Configuration Manager executive subsystem to finish initialising the registry. The Configuration Manager executive is programmed to know the location of the core registry hives (System hives or root keys) stored on the hard disk drive and is also responsible for implementing and managing them. After these initialisation steps, the main thread in Smss waits indefinitely on the process handles to Csrss and Winlogon. If either of these processes terminates unexpectantly Smss crashes the system as Windows relies on their existence. In the mean time, Smss will wait for requests to load subsystems, debug events, and to create new terminal server sessions created by Smss.
- Staring the user-mode portion of the Windows subsystem processes such as Csrss (systemroot\System32\Csrss.exe).
Client/Server Run-Time Subsystem (Csrss.exe)
The Windows subsystem process that maintains a parallel structure for each Windows process that executes a Windows program starts the Winlogon process described below.
- Creating system environment variables.
- Starting the kernel-mode portion of the Windows subsystem (implemented by the Windows subsystem device drive (systemroot\System32\Win32k.sys; windowing system driver) that causes Windows NT family operating systems to switch from text mode to graphical mode. Moreover, this kernel-mode device driver contains the Window Manager, which controls window displays, manages screen output, collects input from the keyboard, mouse, other devices, and passes user messages to applications. Windows-based applications run in the Windows subsystem. This environment allows applications to access the operating system functions, such as displaying information to the screen. The initialisation code in Win32k.sys uses the video driver to switch the screen to the resolution defined by the default profile. This is the point at which the screen changes from the VGA mode the boot video driver (boodvid.dll) uses to the default resolution chosen by the system. Moreover, the Windows subsystem device driver (Win32k.sys) creates system threads in the Windows subsystem process Csrss.exe so that they can easily access data in the user-mode address space of that process.
- Starting the Logon Manager (systemroot\System32\Winlogon.exe).
- Creating additional virtual memory paging files.
- Delayed rename operations performed. It is impossible for core system files to be updated once Windows has finished booting. This is the point at which a file to be updated is delayed until the next boot occurs, e.g., after a Service Pack, hotfix, new driver, or application install. Files listed for updating on the next boot are located at the registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\PendingFileRenameOperation.
The Windows subsystem and the applications that run within it are user-mode processes: they do not have direct access to hardware or device drivers. User-mode processors run at a lower priority than kernel-mode processes. When the operating system needs more memory, it can page to disk the memory that is used by user-mode processes.
- Contains a list of commands to run before loading services. The Autochk.exe tool is specified by the value of the BootExecute entry and virtual memory (paging or swap file) settings stored in the Memory Management (kernel-mode component) subkey. Autochk, which is a version of the chkdsk tool, runs at startup if the operating system detects a filesystem inconsistency that requires repair before completing the startup process.
- Contains a list of available subsystems, e.g., Csrss.exe contains the user-mode portion of the Windows subsystem.
- Almost all operating systems have a mechanism to start processes at system startup that provide services not tied to an interactive user, and are called Windows Services or services for short. When a setup program registers a service, a message is sent to the SCM on the machine where the service will reside. The SCM then creates a registry key for the service under HKLM\SYSTEM\CurrentControlSet\Services. The services key is the non-volatile representation of the SCM’s database. The individual keys for each service define the path of the executable image that contains the service (Path To Executable) as well as the parameters and configuration options. As some service-based applications must initialise during the boot process to function, the setup program may register its service as an auto-start service. SCM will start the service on a system boot thereafter. A service can have a number and unique characteristics: whether a service runs on its own process rather than a service that shares a process with other services, the location of the service’s executable image file, an optional display name, an optional account name and password used to start the service in a particular account’s security context, a start type that indicates whether the service starts automatically when the system boots or manually under the direction of a service control program (SCP), error code that indicates how the system should react if the service detects an error when starting, if the service start automatically, and optional information that specifies when the service starts relative to other services. These are all stored by the SCM as a value in the service registry key. The SCM is responsible for starting drivers with a Start value of SERVICE_AUTO_START or SERVICE_DEMAND_START, so it is quite normal for the SCM database to include drivers. An advantage in having a process run more than one service is that the system resources that would otherwise be required to run them as distinct processes are saved. The downside is that one service error will result in dependent services terminating. The SCM executable file is \Windows\System32\Services.exe, and like most service processes, it runs as a Windows console program. A service’s registry key contains an options Group value if that service or devise driver needs to control its startup ordering with respect to services from other groups. The SCM internally creates a group list that preserves the ordering of the groups it reads from the registry. The SCM adds entries for device drivers to its database as well as for services because the SCM starts services and drivers marked as auto-start and detects startup failures for drivers marked boot-start and system-start. The SCM also provides a means for applications to query the status of drivers. The I/O Manager loads drivers marked boot-start and system-start before any user-mode processes execute and therefore any drivers having these start types loaded before the SCM starts. The SCM sorts the service list alphabetically, as the SCM creates the list from the Services registry key and Windows stores registry keys alphabetically. During startup, the SCM may need to call on the Local Security Authority Subsystem Service (LSASS), e.g., to log on a service in a user account. Winlogon also starts the LSASS process, so the initialisation of LSASS is concurrent with that of SCM and the order in which LSASS and SCM complete initialisation can vary. Before starting auto-start services, the SCM performs a number of steps. It creates its Remote Procedure Call (RPC) named pipe, and then RPC launches a thread to listen on the pipe for incoming messages from SCPs. The SCM then signals its initialisation-complete event.
Logon Phase:
The Windows subsystem starts winlogon.exe, a system service that enables and is therefore responsible for capturing the username and password during logging on and logging off. Winlogon.exe then does the following:
- Starts the Services subsystem (services.exe), known also as the SCM, responsible for loading all auto-start services and drivers.
- SCM then starts the Local Security Authentication Subsystem Service (Lsass) process (Lsass.exe).
- Parses, therefore in turn, Winlogon is notified of a user logon request when the secure attention sequence (SAS) keystroke combination is entered – default is Ctrl+Alt+Del (interrupt 19 is called when the CTRL-ALT-DEL keys are used. On most systems, CTRL-ALT-DEL causes a short version of the POST to be executed before interrupt 19 is called) at the Begin Logon prompt. Presents the standard interactive Windows logon dialog box. The reason for the SAS is to protect the user(s) from password-capturing programs that simulate the logon process, because this keyboard sequence cannot be intercepted by a user-mode application.
The identification and authentication aspects of the logon process are implemented in a replaceable DLL named GINA. The Graphical Identification and Authentication component collects the username and password, and passes this information securely to the LSASS for authentication. Windows uses the Msgina.dll or Gina.dll as the standard GINA.
If valid credentials are supplied by the interactive user, access is granted by using either the Kerberos V5 authentication protocol - conceptually, an authentication protocol based on tickets and session keys, or NTLM. The standard Windows GINA (Graphical Identification aNd Authentication), Msgina.dll, implements the default Windows logon interface.
Winlogon.exe initialises security and authentication components while the SCM initialises auto-load (start) drivers and Windows services. Once the successful auto-start process of services is complete, Winlogon notifies the SCM when there is a successful logon and SCM will save the current registry startup configuration as part of the Last Known Good control set. Moreover, the CurrentControlSet key contains the Services key as a subkey, so CurrentControlSet includes the registry representation of the SCM database. It also contains the control set, which stores many kernel-mode and user-mode subsystem configuration settings.
A successful boot consists of a successful startup of auto-start services and a successful user logon. A boot failure occurs if the system halts because a device driver crashes the system during the boot or if an auto-start service reports a startup error.
When GINA receives a logon and validates the logon, Winlogon loads the registry hive from the profile of the user logging in and maps it to HKEY_CURRENT_USER. It then sets the user’s environment variables that are stored in HKCU\Software\Microsoft\Windows NT\Current\Version\Winlogon\Notify, which a logon has occurred. Once the username and password have been captured, they are sent to the Local Security Authentication Subsystem Service process (\Windows\System32\Lsass.exe) to be authenticated. LSASS calls the appropriate authentication package (implemented as a DLL) to perform the actual verification, such as checking whether a password matches what is stored in the active directory or SAM. The SAM subkey (hive file path: \Windows\System32\Config\Sam) holds local account and group information, e.g., user password, group definitions, and domain associations and linked into the SECURITY subkey under HKLM\SECURITY\SAM. The SECURITY subkey stores a substantial amount of security related information, such as, systemwide security polices and user-rights assignments (hive file path: \Windows\System32\Config\Security). Upon a successful authentication, LSASS calls a function on the security reference monitor to generate an access token object that contains the user’s security profile. This access token is then used by Winlogon to create the initial process(es) in the user’s session. The initial process(es) is stored in the registry value Userinit under the registry key HLKM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon – default is Userinit.exe.
Winlogon next instructs GINA to start the shell. In response to this request, Unserinit.exe (HKCU\Software\Microsoft\Windows NT\Current\Version\Winlogon\Userinit - with multiple executables separated by commas, and by default \Windows\System32\Unserinit.exe) carries out a number of steps. Once Unserinit.exe performs its function, some initialisation of the user environment, e.g., running the logon script and applying group policies, it then looks in the registry at the Shell under HLKM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, creating a process to run the system-default shell – default is Explorer.exe; Userinit.exe then exits. (This is the reason why Explorer.exe is shown without any parent, because the parent Userinit.exe has already exited, and it is the grandchild of Winlogon.exe). Winlogon is not only active during user logon and logoff but also whenever it intercepts the SAS from the keyboard. For example, if a user, while logged on, presses the key combination Ctrl+Alt+Del, the Windows Security dialog box appears, providing the option to log off, start the Task Manager, lock the workstation, shut down the system, and so on. Winlogon is the process that handles this interaction. Winlogon then notifies registered network providers that a user has logged in. The Microsoft network provider, Multiple Provider Router, restores the user’s persistent driver letter and printer mappings.
After the interactive user logs on, the events occur as follows:
- Control sets are updated: The control set referenced by the LastKnownGood registry entry is updated with the contents in the Clone entry. Clone, which is a copy of the CurrentControlSet entry, is created each time the computer is started. When a user logs on, the LastKnownGood control set is updated with configuration information from the previous user session by the SCM.
- Group policy settings take effect: Group Policy settings that apply to the user and computer take effect.
- Startup programs run: Windows NT family operating systems start logon scripts, startup programs, and services referenced in these registry subkeys and folder locations:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- HKCU\Software\Microsoft\WindowsNT\CurrentVersion\Windows\Run
- HKCU\Software\Microsoft\Windows\CurrentVersion\Windows\Run
- HKCU\Software\Microsoft\Windows\CurrentVersion\Windows\Runonce
- Systemdrive\Documents and Settings\All Users\Start Menu\Programs\Startup
- Systemdrive\Documents and Settings\username\Start Menu\Programs\Startup
- Windir\Profiles\All Users\Start Menu Programs Startup
- Windir\Profiles\username\Start Menu\Programs\Startup
The windir\ Profiles folder exists only on systems that are upgraded from Windows NT V4.0.
A Windows NT family operating system’s startup is not complete until a user successfully logs on to the computer.
Plug & Play (PnP) Device Detection
The Plug & Play (PnP) Manager determines which drivers are required to support a particular device (Plug & Play devices have a specific PnP 3-character vendor device ID stored in the hardware device so that the operating system can recognise it) and loads these drivers.
Plug & Play detection runs asynchronously with the logon process and relies on system firmware, hardware, device drivers, and operating system features to detect and enumerate new devices. It retrieves the hardware resource requirements for each device during enumeration. Based on the resource requirements of each device, the PnP Manager assigns the appropriate hardware resources such as I/O ports, IRQs, DMA channels, and memory locations. It is also responsible for sending proper event notifications for device changes, i.e., installation or un-installation of a device on a system.
Windows NT family operating systems optimise PnP support for computers equipped with Advanced Configuration and Power Interface (ACPI) firmware and enables enhanced features, such as hardware resource sharing.
When PnP components are well co-ordinated, Windows NT family operating systems can detect new devices, allocate system resources, and install or request drivers with minimal user intervention/interaction. ACPI features are especially useful for mobile users who use portable computers that support standby, hibernation, hot and warm docking, or undocking features.
Prior to PnP hardware resources such as IRQs, I/O ports and DMA channels would need to be known and configured manually if a conflict were to be avoided. The vast majority of motherboard suppliers license a BIOS "core", and toolkit from a commercial third party such as American Megatrends (AMI) or Phoenix Technologies, which creates and maintains such a core. The motherboard manufacturer then customises these BIOSes to suit its own hardware. PnP has been incorporated within modern-day BIOSes. In concert, Microsoft (PnP operating systems), hardware manufactures (PnP Device IDs) and BIOS developers are creating a PnP compatible environment, although by no means fail proof, a step in the right direction.
The Windows NT family operating systems logon process is complete.
For operating system recovery information use the detailed entries within “More Than Just A Glossary” for hints and remedies. Note: The Windows NT family operating system provides numerous ways to identify the cause of a problem and then to resolve it.
With regards to the term input and output, the term I/O can be referred as part of an action. For example, input devices of a computer would be a mouse, keyboard or optical devices, while an output device for a computer would be a monitor, printer, speakers, headphones or scanner. Devices for communication or transferring between computers are for both input and output, such as modems and network cards.
It is important to note that the previous designations of devices as either input or output change when the perspective changes. Mice and keyboards, the primary means of entering information from the outside world by the user, take as input physical movement that the human user outputs that is converted into signals. The output or results of the computations from these devices is treated as input. Similarly, printers and monitors, the primary means information is present back to the user, are taken as input signals, then converted to outputs. The complete process creates a representation that human users can see or read.
See: Active Partition, Basic Input/Output Subsystem (BIOS), Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2), Boot Code (executable instructions within the MBR), Boot Partition, Bootsect.dos (multiple-boot system; Windows NT-based operating system system startup file #3 (if necessary only)), Bootstrap, Bootstrap Loader, Boot Partition, Boot Volume, Boot Record, Boot Sector, Environment Variable, Device Drivers (location - systemroot\System32\Drivers - Windows NT-based operating system system startup file #9), FAT (12-, 16-, and 32-bit), File Allocation Table, Filesystem, IO.SYS, Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), Master Boot Record (MBR), MBR Disk, Ntdetect.com (Windows NT-based operating system system startup file #4), NTFS (New Technology Filesystem), Ntldr (NT Loader; Windows NT-based operating system system startup file #1), Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6), Partition, Primary Partition, Partition Table, POST (Power-On-Self-Test), Routine, Subroutine, System Partition, System Volume, Variable, Windows NT Architecturally Based Operating System, Windows Kernel, Windows Registry, Windows Services, Processes & Thread, Windows Shutdown, Volume, and Volume Boot Records (VBR). |
|
| |
|
| Windows Registry |
|
The continually referenced Windows registration database or registry plays a vital role as the system’s central relational hierarchical binary (text format for non-Windows NT family operating systems) database of parameters.
It is the Configuration Manager – the executive subsystem that implements the registry – that organises the registry as a series/set of discrete files located on-disk, called hives or root-keys, (including associated logs) in the %systemroot%system32\config directory or C:\WINDOWS or WINNT\system32\config. The Configuration Manager manages the registry as applications and other operating system components read and change registry keys and values, ensuring through various mechanisms that the registry always remains in a recoverable state, even if the system suffers from a system halt failure, while the registry is being modified.
Each hive contains a registry tree, which has a key that serves as the root or starting point of the tree. Subkeys and their values reside beneath the root. Pathnames of all hives except for user profiles are coded into the Configuration Manager. As the Configuration Manager loads hives, including system profiles, it notes each hive’s path in the values under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\hivelist subkey, removing the path if the hive is unloaded, e.g., user profiles are unloaded when not referenced. The Configuration Manager creates the root keys, linking these hives together to build the registry structure as is seen when using the Registry Editor (regedit.exe). Some of the on-disk files, e.g., HKLM (HKEY_LOCAL_MACHINE) is the root-key/hive containing all the systemwide configuration subkeys: HARDWARE (hive file path: volatile hive), SAM (hive file path: \Windows\System32\Config\Sam), SECURITY (hive file path: \Windows\System32\Config\Security), SOFTWARE (hive file path: \Windows\System32\Config\Software), and SYSTEM (hive file path: \Windows\System32\Config\System), HKEY_USER\<security ID of username> (hive file path: \Documents and Settings<username.\Ntuser.dat) and HKLM\SYSTEM\Clone (hive file path: volatile and in Windows 2000 only). Volatile hives do not have associated files and are created each time the system boots. The system creates and manages these hives entirely in memory; hives are therefore transitory. For example, the HARDWARE hive, assigns and stores information about physical devices and the devices assigned resources on each system boot.
Some hives are limited in the maximum size they can be. Windows places a limit on the size of the HKLM\SYSTEM hive because Ntldr reads this entire hive into physical memory near the start of the boot process when virtual memory paging is not enabled as a read-only hive. Ntldr also loads Ntoskrnl.exe and boot device drivers into physical memory, therefore the amount of physical memory assigned to this hive must be limited. The upper limit that Ntldr places on HKLM\SYSTEM for Windows 2000 and Windows XP/Server 2003 is 12MB and 200MB respectively (or ¼ of physical memory, whichever is lower).
Moreover, Windows 2000 also limits the combined sizes of all loaded registry hives by using a type of kernel memory called paged pool to hold registry hives in memory, and therefore, the total amount of loaded registry data is limited by the amount of paged pool that is available. The amount of paged pool the Memory Manager creates during its initialisation is based on a number of factors, such as the amount of physical memory available to the system. On a Windows 2000 system the Memory Manager can create a paged pool no more than 376MB in size. Windows 2000 will not operate smoothly if there is not enough paged pool remaining for other uses, and so the registry is permitted a maximum size equal to 80 per cent of the paged pool or a user-configurable registry quota if it is less than 80 per cent of the paged pool. This registry limit also limits the total number of concurrently logged-on users. For Windows XP and Server 2003, the Configuration Manager does not use paged pool but relies on the Memory Manager’s memory-mapping functions instead to map into system memory. Even then, it is only the sections of the registry hives that Windows XP and Server 2003 are accessing. As there is no registry quota, the total size of loaded hives does not present a problem for concurrently logged-on users.
A special kind of key known as a symbolic link makes it possible for the Configuration Manager to link hives to organise the registry. A symbolic link is a key that redirects the Configuration Manager to another key. Consequently, the HKLM\SAM key is a symbolic link to the key at the root of the SAM hive.
The Configuration Manager structurally and logically divides a hive into allocation units called blocks in much the same way as a filesystem divides a disk into clusters. By definition, the registry block size is 4096 bytes (4KB). When new data expands a hive, the hive always expands in block-granular increments. The first block of a hive is called the base block. The base block includes the following information: global information about the hive, a signature that identifies the file as a hive, updated sequence number, a timestamp that shows the last time a write operation was initialised on the hive, the hive format version number, a checksum and the hive’s file’s internal filename, e.g., \Device\HarddiskVolume1\WINDOWS\SYSTEM32\CONFIG\SAM.
Windows organises the registry data that a hive stores in containers called cells. A cell can hold a key, a value, security descriptor, a list of subkeys, or a list of key values.
The Configuration Manager does not access a hive’s image on disk every time a registry access occurs. Windows 2000 keeps a version of every hive in the kernel’s address space. When a hive initialises, the Configuration Manager determines the size of the hive file, allocates enough memory from the kernel’s paged pool to store it, and reads the hive file into memory. Consequently, as all loaded registry hives are read into the paged pool, the registry data is generally the largest consumer of the paged pool. For Windows XP and Server 2003, the Configuration Manager maps portions of a hive into memory as it needs to access them. It uses the Cache Manager’s file mapping functions to map in 16KB views into the hive files.
If a hive did not expand in size, the Configuration Manager would not be able to perform all of it registry management on the in-memory version of a hive as if it were a file. However, hives expand in size as they add additional keys and values. Consequently, the system must allocate paged pool memory. The paged pool that keeps the registry data in memory may not always be contiguous, therefore, the Configuration Manager deals with non-contiguousness memory addresses referencing hive data in memory in a similar way to the Memory Manager and mapped virtual memory addresses to physical memory addresses.
To ensure that a non-volatile registry hive, one with an on-disk file, is always in a recoverable state, the Configuration Manager uses log hives. Each non-volatile hive has a hidden associated log hive, which is a hidden file with the same base name as the hive, e.g., System.log, Sam.log etc in the \Windows\system32\Config directory. When a hive initialises, the Configuration Manager allocates a bit array in which each bit represents a 512-byte portion, or sector, of the hive. This array is called the dirty sector array because an on bit in the array means that the system has modified the corresponding sector in the hive in memory and must write the sector back to the hive file. An off bit corresponds to a sector that is up to date with the in-memory hive’s contents.
When the creation of a new key or value or the modification of an existing key or value occurs, the Configuration Manager notes the sectors of the hive that changed in the hive’s dirty sector array. The Configuration Manger subsequently schedules a lazy write operation, or a hive synchronisation. The hive lazy writer system thread wakes up five seconds after the request to synchronise the hive and writes dirty hive sectors for all hives from memory to the hive files on disk. Therefore, the system flushes, at the same time, all the registry modifications that take place between the time a hive synchronisation is requested and the time the hive synchronisation occurs. (Note: The default delay lazy write thread of five seconds can be modified on Windows Server 2003).
In order to prevent inconsistent (corrupted) unrecoverable hive file states, the lazy write first dumps the hive dirty sector array and the entire dirty sector’s to the hive’s log file, increasing the log files size if necessary. The lazy writer then updates a sequence number in the hive’s base block and writes the dirty sectors to the hive. When this process is finished, the lazy writer updates the second sequence number in the base block. If a system were to suffer from a system halt failure, for example, during the write operation (mid-operation) to the hive, at the next boot the Configuration Manager will notice that the two sequence number in the hive’s back block are inconsistent with each other. The Configuration Manager can update the hive with the dirty sectors in the hive’s log file to roll the hive forward. The hive is consequently up to date and consistent.
To protect the integrity of the crucial SYSTEM hive in Windows 2000, the Configuration Manager maintains a copy/mirror (System.alt) of it on disk. During hive synchronisation the System.alt hive is also updated. If the Configuration Manager detects that the SYSTEM hive is corrupt when the system boots, it attempts to load the hive’s alternative, System.alt. The System.alt on a successful boot will then update the original SYSTEM hive. Windows XP and Server 2003 do not rely on a System.alt hive. Instead, the more sophisticated NTLDR knows how to process the System.log file to bring up-to-data a SYSTEM hive that becomes corrupted. Windows Sever 2003 goes even further; it has the tolerance to reinitialise (self-heal) corrupted data structures by deleting subkeys if necessary to continue normal operation.
The Configuration Manager also carries out a few registry performance optimisations. Virtually every registry key has a security descriptor that protects access to the key. Storing a unique security-descriptor copy for every key in a hive would be highly inefficient but as the same security settings typically apply to entire subtrees of the registry, when the system applies security to a key in Windows 2000, the Configuration Manager first checks the security descriptors associated with the key’s parent key and then checks all the parent’s subkeys. If any of those security descriptors match the security descriptor the system is applying to the key, the Configuration Manager shares the exiting descriptors with the key, employing a reference count to track how many keys share the same descriptor. For Windows XP and Server 2003, the Configuration Manager checks a pool of the unique security descriptors used within the same hive as the key to which new security is being applied; sharing any existing descriptor for the key, ensuring that there is at most one copy of every unique security descriptor in a hive. Additional optimisation is carried out by the Configuration Manager but it is outside the scope of this glossary entry to discuss this any further.
There are three principal times that configuration data is read:
- During the boot process, the system reads settings that specify what device drivers to load and how various subsystems, e.g., Memory Manager and Process Manager, configure themselves and tune the system’s behaviour.
- During logon, Explorer and other Windows components read per-user configuration settings/preferences from the registry.
- During startup, systemwide software settings are read by applications that control the operation of Windows (Windows systems), the security database and hardware devices and per-user configuration settings/preferences that Windows needs in order to function.
In addition, the registry is not static but a window into the current hardware state of the system (which device drivers are loaded and so forth), and the Windows performance counters (access through the registry functions but do not reside in it) and also a window into various in-memory structures maintained by the Windows executive and kernel - the upper and lower layer of Ntoskrnl.exe respectively - the responsibility of the Configuration Manager and executive components for implementing the registry database.
Important issues covered are how Windows retrieves configuration information when an application requests it, and what measures are employed to protect this critical database and the role of the Configuration Manager, the executive component, responsible for implementing the registry database.
It is normally the case, that applications and system settings stored in the registry that may require manual changes will have a corresponding Graphical User interface (GUI), e.g., via a number of Control Panel applets to control their modifications. However, not all registry changes have a corresponding applet. Therefore, manually editing is the only option for advanced and experienced users.
Each time Windows 2000 through to Server 2003 boots, the registry is reconstructed from a set of files that are updated on shutdown. Once in memory, the registry is maintained continually.
To view and modify the registry Windows 2000 has two tools for editing the registry - Regedit.exe (has flexible searching, importing and exporting capabilities) and Regedit32.exe (supporting security for specific Windows 2000 data types). Windows XP and Server 2003 have Regedit.exe only but include security editing and knowledge of all the registry data types. The registry editor begins with all its root keys (hives) in separate cascading windows.
- System: there are six system-defined hive keys, known by the first portion of their name: HKEY_. Hive keys are abbreviated “HK” plus the first initials of the components words in the underscored space. These are top-level keys in descending hierarchy that cannot be subkeys.
- HKEY_LOCAL_MACHINE (HKLM)
- HKEY_CURRENT_USER (HKCU)
- HKEY_CLASSES_ROOT (HKCR)
- HKEY_USERS (HKU)
- HKEY_CURRENT_CONFIG (HKCC)
- HKEY_PERFORMANCE_DATA (HKD)
Windows predominately uses registry links: three of which of the six registry root keys are links to subkeys within the three non-link root keys. Links are not saved so must be dynamically created after each boot. These root keys will be explained in more details. (Please refer to Table 1.). Root-key names begin with the letter “H” because the root-key name represents the Windows handle (H) to keys (KEY).
Table 1: The following table lists the predefined keys used by the system. The maximum size of a key name is 255 characters for Windows 9x & Millennium and 16,383 for Windows NT V4 upwards (Unicode characters). Value, greater than 2,048 bytes, should be stored as files with the file names stored in the registry, i.e., Windows 9x & Millennium 16,300 bytes and Windows NT 4.0 upwards (available memory).
Folder/Pre-defined Key |
Description |
HKEY_CURRENT_USER (HKCU) |
This hive key contains the root of the configuration information; points to the user profile, for the user currently logged on to the computer the registry serves. Its subkeys include environment variables, personal program groups, desktop settings, network connections, printer, and application preferences. Windows NT family operating systems use environment variables to allow scripts, registry entries, and other applications to use wildcards for important system information that might change. This information is mapped from the HKEY_USERS hive key's Security ID (SID) subkey for the currently logged on user. |
HKEY_USERS
(HKU) |
This hive key contains subkeys that stores, (or the root), the entire/all loaded user profiles for the current computer. One of its subkeys is always mapped to HKEY_CURRENT_USER (via the user's SID value). Another HKEY_USERS\.DEFAULT\, contains Windows configuration information (or settings) used before a user has logged on. |
HKEY_LOCAL_MACHINE (HKLM) |
This hive key contains the operating system and hardware-orientated information, such as the bus type of the computer, total system memory available, currently loaded device drivers, and boot-up control data. This hive key holds most of the information in the registry because it is the placeholder for two other hive keys that are aliased to its subkeys. |
HKEY_CLASSES_ROOT (HKCR) |
This hive key contains subkeys listing all COM (OLE) servers currently registered on the computer and the entire file extensions/associations currently associated with applications. This information is mapped from the HKLM\SOFTWARE\Classes subkeys. For Windows 2000 through to Server 2003, this information is stored both under the HKLM and HKU hive keys. The HKLM\Software\Classes key contains default settings that can apply to all users on the local computer. The HKCU\Software\Classes key contains settings, which override the default settings and apply only to the logged on user. The HKCR key provides a view of the registry that merges the information from these two sources. HKCR also provides this merged view for programs designed for previous versions of Windows. For example, to change the settings for the logged on user, changes should be made under HKCU\Software\Classes instead of HKCR. To change default settings, changes should be made under HKLM\Software\Classes. Adding keys to a key under HKCR, the system stores the information under HKLM\Software\Classes. Adding a key under HKCR and the key already exists under HKCU\Software\Classes instead; HKLM\Software\Classes. |
HKEY_CURRENT_CONFIG (HKCC) |
This hive key contains subkeys listing all the hardware profile information for the current session of the computer. Hardware profiles are a new feature from Windows NT family operating systems that allows the choosing of which device drivers to support for a given session on a machine. This information is mapped from the HKLM\SYSTEMS\CurrentControlSet\ subkeys. |
HKEY_PERFORMACE_DATA
(HKD) |
Stores performance information. |
Note: A key is a container that can consist of other keys (subkeys) or values. These are user-defined and system-defined keys. These keys have no special naming convention and they exist as subdirectories of the main HKEY_ hive keys. Most keys and subkeys have no associated data; they serve only to organise access to data as is the case with subkeys too.
As the registry is such a large database store of data it must be accessed quickly to avoid degrading system performance. To improve reaction times of obtaining a given piece of information, the registry is organised like a filesystem on the hard disk drive.
Using Windows 2000 through to Server 2003 as the operating system used in this example, there are three levels of organisation of the registry, in a descending hierarchy:
- User: Defined and system-defined keys and subkeys. There is no specific naming convention; they exist as subdirectories of the main HKEY_hive keys. Keys and subkeys have no associated data; they serve only to organise access to data.
- Values: There are 15 recognised registry data types for Windows NT family operating systems at the end of the chain; similar to files in a filesystem and similar to a disk’s directory on a disk volume. They store data that is used in the performance of the computer and the applications installed. They have a small but very effective set of available data types:
- REG_BINARY
- REG_DWORD
- REG_EXPAND_SZ
- REG_MULTI_SZ
- REG_SZ
- REG_RESOURCE_LIST
- REG_RESOURCE_REQUIREMENTS_LIST
- REG_FULL_RESOURCE_DESCRIPTOR
- REG_NONE
- REG_LINK
- REG_QWORD
- REG_QWORD_LITTLE_ENDIAN
- REG_QWORD_BIG_ENDIAN
- REG_DWORD_LITTLE_ENDIAN
- REG_DWORD_BIG_ENDIAN
Values store different kinds of data in keys (or subkeys). The majority of registry values are REG_DWORD, REG_BINARY, or REG_SZ. Values of type REG_DWORD can store numbers or Boolean (on/off values); REG_BINARY values can store numbers larger than 32 bits or raw data such as encrypted passwords; REG_SZ values store strings (Unicode) that can represent elements such as names, filenames, paths, and types. These values will be explained in more details. (Please refer to Table 2.)
Table 2: The 11 recognised Registry data types and their capabilities, and above the hives that contain all the data in the Registry. As the Registry is a relational database, it logically needs a schematic representation to define its organisation. This structure, aside from the hierarchical discussed later, and represented in Table. 1., is provided by a restricted set of data types that Registry values can contain. Most of these raw format types have a dedicated editor, namely, number, binary, string, and multi-string.
Name |
Data Type |
Description |
Binary Value |
|
Raw binary data. Most hardware component information is stored as binary data and is displayed in the registry editor in hexadecimal format. Raw format type: binary; function: binary data. |
DWORD
Value |
|
Data represented by a number that is 4 bytes long (a 32-bit integer). Many parameters for device drivers and services are this type and are displayed in the registry editor in binary, hexadecimal, or decimal format. Related values are DWORD_LITTLE_ENDIAN (least significant byte is at the lowest address) and REG_DWORD_BIG_ENDIAN (least significant byte is at the highest address). Raw format type: number; function: numerical data. |
Expandable
String Value |
|
A variable-length data string. This data type includes variables that are resolved when a program or service uses the data. Raw format type: this expandable string is a more sophisticated type of string-based data type. |
Multi-String
Value |
|
A multiple string (or groups of strings). Values that contain lists or multiple values in a form that people can read are usually of this type. Spaces, commas, or other marks that separate entries. Raw format type: multi-string; function: string arrays. Rather than having to make each string a separate value this data type provides a way to edit string arrays. |
String Value |
|
A fixed-length text string. Raw format type: string; function: text characters. |
Binary Value |
|
A series of nested arrays designed to store a resource list used by a hardware device driver or one of the physical devices it controls. This data is detected and written into the \ResourceMap tree by the system and is displayed in the registry editor in hexadecimal format as a binary value. Raw format type: string; function: hardware resource list. |
Binary Value |
|
A series of nested arrays designed to store a device driver's list of possible hardware resources it or one of the physical devices it controls can use, from which the system writes a subset into the \ResourceMap tree. This data is detected by the system and is displayed in the registry editor in hexadecimal format as a binary value. Raw format type: string; function: hardware resource ID. |
Binary Value |
|
A series of nested arrays designed to store a resource list used by a physical hardware device. This data is detected and written into the \HardwareDescription tree by the system and is displayed in the registry editor in hexadecimal format as a binary value. |
None |
|
Data with no particular type. This data is written to the registry by the system or applications and is displayed in the registry editor in hexadecimal format as a binary value. Raw format type: string; function: hardware resource ID. |
Link |
|
A Unicode string naming a symbolic link. Raw format type: string; function: path to a file. |
QWORD
Value |
|
Data represented by a number that is a 64-bit integer. This data is displayed in the registry editor as a binary value and was first introduced in Windows 2000. |
QWORD
Value |
|
64-bit number, with low byte first. This is equivalent to REG_QWORD. |
QWORD
Value |
|
64-bit number, with high byte first. |
DWORD
Value |
|
32-bit number, with low byte first. This is equivalent to REG_DWORD. |
HKLM is the root key/hive containing all the systemwide configuration subkeys: HARDWARE (hive file path: volatile hive), SAM (hive file path: \W | |
