Boot Loader Phase
The boot loader phase varies by platform. Since the earlier phases are not specific to the OS, the boot process is considered to start:
For x86 or x64: when the partition boot sector code is executed in real mode and loads NTLDR
For IA-64: when the IA64ldr.efi EFI program is executed (later referred as simply IA64ldr)
From that point, the boot process continues as follows:
An NTLDR file, located in the root folder of the boot disk, is composed of two parts. The first is the StartUp module and immediately followed by the OS loader (osloader.exe), both stored within that file. When NTLDR is loaded into memory and control is first passed to StartUp module, the CPU is operating in real mode. StartUp module's main task is to switch the processor into protected mode, which facilitates 32-bit memory access, thus allowing it to create the initial Interrupt descriptor table, Global Descriptor Table, page tables and enable paging. This provides the basic operating environment on which the operating system will build. StartUp module then loads and launches OS loader.
NTLDR's OS loader includes basic functionality to access IDE-based disks formatted for NTFS or FAT file systems, or CDFS (ISO 9660), ETFS or UDFS in newer operating system versions. Disks are accessed through the system BIOS, through native ARC routines on ARC systems, or via network using TFTP protocol. All BIOS calls are done through virtual 8086 mode beyond this point, as the BIOS can not be directly accessed within protected mode. If the boot disk is a SCSI disk and the SCSI controller is not using real-mode INT 0x13, an additional file, Ntbootdd.sys is loaded to handle disk access in place of the default routines. This is a copy of the same SCSI miniport driver that is used when Windows is running.
The boot loader then reads the contents of boot.ini to locate information on the system volume. If the boot.ini file is missing, the boot loader will attempt to locate information from the standard installation directory. For Windows NT machines, it will attempt to boot from C:\WINNT. For Windows XP and 2003 machines, it will boot from C:\WINDOWS.
At this point, the screen is cleared, and in the Windows 2000 or later versions of NTLDR and IA64ldr which support system hibernation, the root directory default volume as defined in boot.ini is searched for a hibernation file, hiberfil.sys. If this file is found and an active memory set is found in it, the contents of the file (which will match the amount of physical memory in the machine) are loaded into memory, and control is transferred into the Windows kernel at a point from which hibernation can be resumed[1]. The file is then immediately marked as non-active, so that a crash or other malfunction cannot cause this (now-outdated) memory state to be re-loaded. If a state resume fails, the next time NTLDR runs it will ask the user whether to try resuming again or to discard the file and proceed with normal booting.
If boot.ini contains more than one operating system entry, a boot menu is displayed to the user, allowing the user to choose which operating system is to be loaded. If a non NT-based operating system such as Windows 98 is selected (specified by an MS-DOS style of path, e.g. C:\), then NTLDR loads the associated "boot sector" file listed in boot.ini (by default, this is bootsect.dos if no file name is specified) and passes execution control to it. If an NT-based operating system is selected, NTLDR runs ntdetect.com, which gathers basic information about the computer's hardware as reported by the BIOS.
At this point in the boot process, NTLDR clears the screen and displays a textual progress bar, (which is often not seen on XP or 2003 systems, due to their initialization speed); Windows 2000 also displays the text "Starting Windows..." underneath. If the user presses F8 during this phase, the advanced boot menu is displayed, containing various special boot modes including Safe mode, with the Last Known Good Configuration, with debugging enabled, and (in the case of Server editions) Directory Services Restore Mode.
Once a boot mode has been selected (or if F8 was never pressed) booting continues.
If an x64 version of Windows is being booted (Windows XP Professional x64 Edition or Windows Server 2003 x64 Editions), the CPU is switched into long mode, enabling 64-bit addressing.
Next, the Windows kernel Ntoskrnl.exe and the Hardware Abstraction Layer hal.dll are read into memory. If either of these files fails to load, the message "Windows could not start because the following file was missing or corrupt" is displayed to the user, and the boot process comes to a halt.
If multiple hardware configurations are defined in the registry, the user is prompted at this point to choose one.
With the kernel in memory, boot-time device drivers are loaded (but not yet initialized). This information (along with information on all detected hardware and Windows Services) is stored in the HKLM\SYSTEM portion of the registry, in a set of registry keys collectively called a Control Set. Multiple control sets (typically two) are kept, in the event that the settings contained in the currently-used one prohibit the system from booting. HKLM\SYSTEM contains control sets labeled ControlSet001, ControlSet002, etc., as well as CurrentControlSet. During regular operation, Windows uses CurrentControlSet to read and write information. CurrentControlSet is a reference to one of the control sets stored in the registry. Windows picks the "real" control set being used based on the values set in the HKLM\SYSTEM\Select registry key:
Default will be NTLDR or IA64ldr's choice if nothing else overrides this.
If the value of the Failed key matches Default, then NTLDR or IA64ldr displays an error message, indicating that the last boot failed, and gives the user the option to try booting, anyway, or to use the "Last Known Good Configuration".
If the user has chosen Last Known Good Configuration from the boot menu, the control set indicated by the LastKnownGood key is used instead of Default.
When a control set is chosen, the Current key gets set accordingly. The Failed key is also set to the same as Current until the end of the boot process. LastKnownGood is also set to Current if the boot process completes successfully.
For the purposes of booting, a driver is either a "Boot" driver that is loaded by NTLDR or IA64ldr prior to starting the kernel and started before system drivers by the kernel, a "System" driver, which is loaded and started by ntoskrnl.exe after the boot drivers or an "Automatic" driver which is loaded much later when the GUI already has been started. "Boot" drivers are almost exclusively drivers for hard-drive controllers and file systems (ATA, SCSI, file system filter manager, etc.); in other words, they are the absolute minimum that ntoskrnl.exe will need to get started with loading other drivers, and the rest of the operating system. "System" drivers cover a wider range of core functionality, including the display driver, CD-ROM support, and the TCP/IP stack.
The appropriate file system driver for the partition type (NTFS, FAT, or FAT32) which the Windows installation resides on is also loaded.
With this finished, control is then passed from NTLDR or IA64ldr to the kernel. At this time, Windows NT shows the famous "blue screen" displaying number of CPUs and the amount of memory installed, whilst Windows 2000, XP and 2003 switch into a graphical display mode to display the Windows logo, unless the /noguiboot or /sos switches are present in boot.ini.
Kernel loading phase
ntoskrnl.exe < the kernel
hal.dll < type of hardware abstraction layer
kdcom.dll < Kernel Debugger HW Extension DLL
bootvid.dll < for the windows logo and side-scrolling bar
config\system registry
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute
Process services in the order provided
HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroup Order
The initialization of the kernel subsystem and the Windows Executive subsystems is done in two phases.
During the first phase, basic internal memory structures are created, and each CPU's interrupt controller is initialized. The memory manager is initialized, creating areas for the file system cache, paged and non-paged pools of memory. The Object Manager,[1] initial security token for assignment to the first process on the system, and the Process Manager itself. The System idle process as well as the System process are created at this point.
The second phase involves initializing the device drivers which were identified by NTLDR as being system drivers.
Through the process of loading device drivers, a "progress bar" is visible at the bottom of the display on Windows 2000 systems; in Windows XP and Windows Server 2003, this was replaced by an animated bar which does not represent actual progress. Prior to Windows XP, this part of the boot process took significantly longer; this is because the drivers would be initialized one at a time. On Windows XP and Server 2003, the drivers are all initialized asynchronously.
Session Manager
Once all the Boot and System drivers have been loaded, the kernel (system thread) starts the Session Manager Subsystem (smss.exe).
Before any files are opened, Autochk [2] is started by smss.exe. Autochk mounts all drives and checks them one at a time whether they were not shut down cleanly before. In that case it will automatically run chkdsk, however just before the user can abort this process by pressing any key within 10 seconds (this was implemented in Windows NT 4.0 Service Pack 4, in earlier versions you could not skip chkdsk). Since Windows 2000, XP and 2003 show no text screen at that point (unlike NT, which still shows the blue text screen), they will show a different background picture holding a mini-text-screen in the center of the screen and show the progress of chkdsk there.
At boot time, the Session Manager Subsystem :
Creates environment variables (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment)
Starts the kernel-mode side of the Win32 subsystem (win32k.sys). This allows Windows to switch into graphical mode as there is now enough infrastructure in place.
Starts the user-mode side of the Win32 subsystem, the Client/Server Runtime Server Subsystem (csrss.exe). This makes Win32 available to user-mode applications.
Creates virtual memory paging files (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management)
Any rename operations queued up are performed. This allows previously in-use files (e.g. drivers) to be replaced as part of a reboot.
Starts the Windows Logon Manager (winlogon.exe). Winlogon is responsible for handling interactive logons to a Windows system (local or remote). The Graphical Identification And Authentication (GINA) library is loaded inside the Winlogon process, and provides support for logging in as a local or Windows domain user.
The Session Manager stores its configuration at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. The exact operation of most of these items is based on the configuration set in the registry.
Winlogon
Winlogon starts the Local Security Authority Subsystem Service (LSASS) and Service Control Manager (SCM), which in turn will start all the Windows services that are set to Auto-Start [3]. It is also responsible for responding to the secure attention sequence (SAS), loading the user profile on logon, and optionally locking the computer when a screensaver is running.
The logon process is as follows:
Winlogon calls GINA
(Optional) Logon prompt is displayed by GINA, and the user presses the secure attention sequence (Control-Alt-Delete)
Logon dialog is displayed by GINA
User enters credentials (username, password, and domain)
GINA passes credentials back to Winlogon
Winlogon passes credentials to LSASS, which determines which account database is to be used:
Local SAM
Domain SAM
Active Directory
LSASS enforces the local security policy (checking user permissions, creating audit trails, doling out security tokens, etc.).
After a user has successfully logged in to the machine, Winlogon does the following:
Updates the Control Sets; the LastKnownGood control set is updated to reflect the current control set.
User and Computer Group Policy settings are applied.
Startup programs are run from the following locations [4]:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Once
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\pol icies\Explorer\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run Once
%ALLUSERSPROFILE%\Start Menu\Programs\Startup\ (please note that this path is localized on non-English versions of Windows)
%USERPROFILE%\Start Menu\Programs\Startup\ (please note that this path is localized on non-English versions of Windows)
Riferimento: [Circolino] Puru puru pururin ~ Kore wa Inbou da! [NIPPON NERDS INSAID]
interessante
Originariamente Scritto da Haruki
vieni dall'haruki tuo
Permessi di Scrittura
