Sie sind auf Seite 1von 14

NTLDR

From Wikipedia, the free encyclopedia

Jump to: navigation, search NTLDR (abbreviation of NT Loader) is the boot loader for all releases of Microsoft's Windows NT operating system up to and including Windows XP and Windows Server 2003. NTLDR is typically run from the primary hard disk drive, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file. NTLDR requires, at the minimum, the following two files to be on the system volume:
NTLDR, which contains the main boot loader itself boot.ini, which contains configuration options for a boot menu.

To load an NT-based OS, ntdetect.com must also be present. (Strictly speaking, only NTLDR is actually required. If boot.ini is missing, NTLDR will default to C:\Windows on the first partition of the first hard drive. Many desktops in the home are in this configuration and a missing boot.ini file will simply generate an error stating it is missing, then boot into Windows successfully.) The Volume Boot Record written to disk by the Windows NT format command attempts to load and to run the NTLDR program. In Windows Vista and Windows Server 2008, NTLDR was replaced; the boot loader functionality is instead provided by two new components: winload.exe and the Windows Boot Manager.

Contents
[hide]

1 Startup process 2 boot.ini o 2.1 Example o 2.2 NT Kernel switches 3 See also 4 References 5 External links

[edit] Startup process

When booting, the loader proper portion of NTLDR does the following in order: 1. Accesses the file system on the boot drive (either FAT or NT File System, NTFS). 2. If hiberfil.sys is found, and it finds a hibernation image, its contents are loaded into memory and the system resumes where it left off. 3. Otherwise, reads boot.ini and prompts the user with the boot menu accordingly. 4. If a non NT-based OS is selected, then NTLDR loads the associated file listed in boot.ini (bootsect.dos if no file is specified or if the user is booting into a DOS based OS) and gives it control. 5. If an NT-based OS is selected, then NTLDR runs ntdetect.com, which gathers information about the computer's hardware. (If ntdetect hangs during hardware detection there is a debug version called ntdetect.chk which can be found on Microsoft support.[1]) 6. Starts Ntoskrnl.exe, passing to it the information returned by ntdetect.com. [2]

[edit] boot.ini
NTLDR allows the user to choose which operating system to boot from at the menu; for NT and NT-based operating systems, it also allows the user to pass preconfigured options to the kernel. The menu options are stored in boot.ini, which itself is located in the root of the same disk as NTLDR. For NT-based OSs, the location of the operating system is written as an Advanced RISC Computing (ARC) path. boot.ini is protected from user configuration by having the following file attributes: system, hidden, read-only. To make it editable, you must first unlock it with the following command under a console attrib -s -h -r boot.ini. A more secure fashion to edit the file is to use the bootcfg command from a console. bootcfg will also relock the file (setting the file back to system, hidden and read-only). Additionally, the file can be edited within Windows using a text editor if the folder view option "Show hidden files and folders" is selected and the folder view option "Hide protected operating system files" is unchecked and the "Readonly" option is unchecked under file properties. bootsect.dos is the boot sector loaded by NTLDR to load DOS. If there is no file specified, NTLDR loads bootsect.dos

[edit] Example
An example of a boot.ini file:
[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

If the boot loader timeout option in boot.ini is set to 0, the NTLDR boot menu does not appear. Extreme caution should be taken when modifying the boot loader, as erroneous information can result in an OS that fails to boot.

[edit] NT Kernel switches

NTLDR Bootloader's Advanced Option Menu

/3gb Allocate 3 GB of virtual address space to programs and 1 GB to the kernel; used for some programs that require more than the standard 2gb allocation for user programs. /basevideo The computer starts up using the standard VGA video driver. /baudrate=nnn Sets the baud rate of the debug port that is used for kernel debugging. /bootlog Write a log file when Windows boots. /bootlogo Display an alternate 640x480 16 color bitmap at boot (WinXP+ only, needs also /noguiboot) /burnmemory Amount of memory Windows is not allowed to use. /channel Use with /debug and /debugport to have kernel debugging messages sent over an IEEE 1394 (FireWire) port /crashdebug Causes the kernel debugger to load, but remain inactive until a crash is detected. /debug Causes the kernel debugger to load and activate. /debugport=comx /fastdetect Turn off serial mouse detection. /HAL=filename Define Hardware Abstraction Layer to use. /kernel=filename Use an alternate kernel on boot. /maxmem=nn Set the highest memory address Windows can use (use of /burnmemory recommended instead, for stability and precision reasons). /minint Boot windows in WinPE mode (XP and later, can be used to boot windows from CD, see [3]) /nodebug Turn off debugging; can cause Stop Error if a program uses debugging. /noexecute=off/optin/optout/on (DEP). Default with PAE is optin under Windows XP post-SP1. /noguiboot Don't use the bitmap progress bar when starting up. This also disables the text output used by CHKDSK and various partitioning tools, so you should use this switch with extreme caution. Those programs will actually run correctly; the only exception is when they need some text input to continue. /nopae Do Not Support Physical Address Extension. /noserialmice:comx Turn off serial mouse detection on port x. /numproc=CPUs Set number of processors Windows is allowed to use; useful if some processors are failing or defective. /onecpu Equivalent to using /numproc=1; only lets Windows use one CPU.

/pae Support Physical Address Extension. /pcilock Let the BIOS assign device addresses instead of Windows. /redirect Turn on Emergency Management Services on certain versions of Windows. /safeboot Enter Safe mode. o /safeboot:dsrepair Starts a domain controller in Directory Services Restore Mode. o /safeboot:minimal Enter safe mode with minimal device drivers o /safeboot:minimal(alternateshell) and an alternate shell o /safeboot:network with network support /usepmtimer compatibility switch for energy saving processors so that they can run in full speed (always on) /userva Specify additional memory rules in combination with /3gb switch. /sos Display driver names while loading. /w95 Loads C:\BOOTSECT.W40 as a bootsector. /w95dos Loads C:\BOOTSECT.DOS as a bootsector. /year Tells Windows to ignore the system clock and use the year you specify. For example, /year=2001 was used when Y2K testing. [4][5]

Windows NT startup process


From Wikipedia, the free encyclopedia

Jump to: navigation, search The Windows NT startup process is the process by which Microsoft's Windows NT, Windows 2000, Windows XP and Windows Server 2003 operating systems initialize. In Windows Vista, this process has changed slightly (see Windows Vista startup process).

Contents
[hide]

1 Boot Loader Phase 2 Kernel loading phase 3 Session Manager 4 Winlogon 5 Logon phase 6 Remote booting & installation 7 Additional information 8 See also 9 Footnotes 10 References 11 External links

[edit] Boot Loader Phase


For more details on this topic, see NTLDR. 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[clarify] or UDFS[clarify] 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. It should be noted that all BIOS calls are done through virtual 8086 mode beyond this point, because the BIOS can not be accessed directly 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 NTbased 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 now 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:

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

[edit] Kernel loading phase


1. 2. 3. 4. 5. 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 1. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute 2. Process services in the order provided HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

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.

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

[edit] Winlogon
"Begin logon" dialog box in Windows XP. For more details on this topic, see Winlogon. Winlogon is responsible for responding to the secure attention key (called secure attention sequence in Windows and it is the Control-Alt-Delete key combination), loading the user

profile on logon, and optionally locking the computer when a screensaver is running. In Windows Vista and later operating systems, Winlogon's roles and responsibilities have changed significantly. 1. Winlogon calls GINA 1. GINA begin logon prompt is displayed (image) 2. User presses SAS (Control-Alt-Delete) 3. GINA logon dialog is displayed 4. User inputs credentials (Username, Domain and Password) 5. GINA passes credentials back to Winlogon 2. Winlogon passes credentials to LSA LSA determines which account databases is to be used Local SAM Domain SAM Active Directory 2. Winlogon (loaded by SMSS) o At this point, Winlogon starts the Service Control Manager (SCM), which in turn will start all the Windows services that are set to "Auto-Start". The Local Security Authority Subsystem Service (lsass.exe) is also started, which enforces the local security policy (checking user permissions, creating audit trails, doling out security tokens, etc.).
userinit.exe

[edit] Logon phase


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: 1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce 2. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Exp
lorer\Run

3. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run 4. HKCU\Software\Microsoft\Windows
NT\CurrentVersion\Windows\Run

5. HKCU\Software\Microsoft\Windows\CurrentVersion\Run 6. HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce 7. All Users ProfilePath\Start Menu\Programs\Startup\ (please note that this path is localized on non-English versions of Windows) 8. Current User ProfilePath\Start Menu\Programs\Startup\ (please note that this path is localized on non-English versions of Windows)

[edit] Remote booting & installation


Please help improve this section by expanding it. Further information might be found on the talk page or at requests for expansion. (January 2007)

The Boot Information Negotiation Layer (BINL) is a Windows 2000 service that makes it possible for installation to be done on computers that are able to remotely boot. For more details on this topic, see Remote_Installation_Services.

[edit] Additional information


The HKLM\HARDWARE section of the registry is populated by the kernel at boot-time with the information about detected hardware that was gathered by ntdetect.com. More specifically:

If ACPI is supported by the hardware, the Fixed ACPI Description Table (FADT), Firmware ACPI Control Structure (FACS) and Root System Description Table (RSDT) are written to HKLM\HARDWARE\ACPI. Details about installed CPU(s), such as the brand, speed, and feature set (MMX, SSE, etc.) installed are stored in HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\#. In similar fashion, details about installed FPU(s) are stored in HKLM\HARDWARE\DESCRIPTION\System\FloatingPointProcessor\#. Information about the various multifunction adapters (ISA, PNP, ACPI, etc.) and the devices on them that are detected by ntdetect.com, is stored in HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\#.

Windows Vista startup process


From Wikipedia, the free encyclopedia

Jump to: navigation, search This refers to the boot components for Windows Vista and Windows Server 2008. The Windows Vista startup process is the process by which Microsoft's Windows Vista operating system initializes.

Contents
[hide]

1 Quick Overview 2 Booting sequence 3 Windows Boot Manager 4 Boot Configuration Data 5 winload.exe 6 See also 7 References 8 External links

[edit] Quick Overview


Bios > Master Boot Record > Boot Sector > Windows Boot Manager > Read from BCD > Search for hibernation file > Start winload.exe > Start ntoskrnl.exe > Start smss.exe > Start winlogon.exe > start services and login interface

[edit] Booting sequence


Vista boot sequence The sequence of booting Windows Vista is slightly different from any previous version of Windows that uses the NT kernel. First, when the computer is switched on, either the BIOS or the EFI is loaded. In the case of a BIOS system, the MBR of the boot disk, which can be a hard drive or external media, is accessed, followed by the boot sector of the drive or of relevant hard disk partition. This boot sector then loads the rest of the boot blocks.

For Windows Vista, the boot sector loads the Windows Boot Manager (Filename:Bootmgr.) which accesses the Boot Configuration Data store and uses the information to load the final stage, the Operating System.

[edit] Windows Boot Manager


The Windows Boot Manager reads the Boot Configuration Data and "displays an operating system selection menu",[1] and is thus, in some respects, equivalent to the boot selection menu functionality of NTLDR in prior versions of Windows NT. To maintain a consistent boot experience, on Extensible Firmware Interface systems, which also have a boot manager of their own, the Windows Boot Manager, and hence all of the installed Windows operating systems that can be booted using it, appear as a single entry on the EFI boot manager menu. (On EFI systems, the Windows Boot Manager is an EFI application stored on the EFI System Partition.) Microsoft only adds multiple entries to the Windows Boot Manager(BCD) menu itself, and sets the timeout of the EFI boot manager to 2 seconds.

[edit] Boot Configuration Data


Boot Configuration Data (BCD) is a firmware-independent database for boot-time configuration data. It replaces the boot.ini that was used by NTLDR, and is used by Microsoft's new Windows Boot Manager.[2] Boot Configuration Data is stored in a data file (formatted in the same way as a Windows registry hive) that is located either on the EFI System Partition (on machines that use Extensible Firmware Interface firmware) or in \Boot\Bcd on the system volume (on machines that use IBM PC compatible firmware). Boot Configuration Data may be altered using a command-line tool (bcdedit.exe), by using Windows Management Instrumentation, or with 3rd party tools like EasyBCD which allow for more advanced configuration and support for non-Windows operating systems. Boot Configuration Data contain the menu entries that are presented by the Windows Boot Manager, just as boot.ini contained the menu entries that were presented by NTLDR. These menu entries can include:

Options to boot Windows Vista by invoking winload.exe. Options to resume Windows Vista from hibernation by invoking winresume.exe. Options to boot a prior version of Windows NT by invoking its NTLDR. Options to load and to execute a Volume Boot Record.

Boot Configuration Data allows for third party integration so anyone can implement tools like diagnostics or recovery options.

[edit] winload.exe
winload.exe is the operating system boot loader. It is invoked by the Windows Boot Manager in order to load the operating system kernel (ntoskrnl.exe) and (boot-class) device drivers,[1] and is in that respect functionally equivalent to (the operating system loader functionality of) NTLDR in prior versions of Windows NT. (It is worth noting that the filename winload.exe is also used by a parental control software program, PC Tattletale. This program has nothing to do with the Windows Vista startup process or the Microsoft program winload.exe.)