Windows 2000 boot process

This sector contains the code that starts Ntldr which is the boot strap loader for Windows XP. The first role of Ntldr is to allow full memory addressing, start the file system, read boot. Ntldr then uses the ARC path specified in the boot. The one where Windows XP is installed. It might look like this: Ntldr, then, loads the two files that make up the core of XP: Ntoskrnl. Ntldr reads the registry files, selects a hardware profile, control set and loads device drivers, in that order.

Then, Ntoskrnl. You don't. A machine will not boot without that file. Boot from the XP CD use the recovery tool within the disk. Four 4 startup disks are needed to boot Windows from floppy disks.

Windows Boot Manager bootmgr File,Windows boot loader winload. Dual Booting, using a program called a 'Boot Loader'. Note: If you want boot both opreting system win xp and win at a time then you use VM ware software. The floppy disk has nothing to do with the operating system on the hard drive. Install both. Then at boot time press f12 and select the system you want to boot.

Log in. Learning Theories. Book Reports. Study now. See answer 1. Best Answer. Study guides. If the 5-second wait times out that is, if 5 seconds elapse , the Session Manager is assumed to have started successfully, and the phase 1 initialization function calls the memory manager's zero page thread function explained in Chapter 7.

Thus, this system thread becomes the zero page thread for the remainder of the life of the system. Smss is like any other user-mode process except for two differences: First, Windows considers Smss a trusted part of the operating system. Second, Smss is a native application.

Because it's a trusted operating system component, Smss can perform actions few other processes can perform, such as creating security tokens. In fact, one of Smss's first tasks is to start the Win32 subsystem. Smss then calls the configuration manager executive subsystem to finish initializing the registry, fleshing the registry out to include all its keys. Typically, this value contains one command to run Autochk the boot-time version of Chkdsk.

Pending file deletes are in PendingFileRenameOperations2. Initializes the registry. Loads the kernel-mode part of the Win32 subsystem Win23k. Smss determines the location of Win32k. The initialization code in Win32k.

Starts the subsystem processes, including Csrss. Starts the logon process Winlogon. The startup steps of Winlogon are described shortly. After performing these initialization steps, the main thread in Smss waits forever on the process handles to Csrss and Winlogon. If either of these processes terminates unexpectedly, Smss crashes the system, since Windows relies on their existence.

Winlogon then performs its startup steps, such as creating the initial window station and desktop objects, loading GINA DLLs, and so on.

For more details on the startup sequence for Winlogon and Lsass, see the section "Winlogon Initialization"in Chapter 8. After the SCM initializes the auto-start services and drivers and a user has successfully logged on at the console, the SCM deems the boot successful.

If a user chooses to boot to the last known good menu during the first steps of a boot, or if a driver returns a severe or critical error, the system uses the LastKnownGood value as the current control set.

Doing so increases the chances that the system will boot successfully, because at least one previous boot using the last known good profile was successful.

Previous page. Table of content. Next page. Figure Example hard disk layout Physical disks are addressed in units known as sectors. Table Boot. See MicrosoftKnowledge Base article Q for more information. Thus, the year used in the switch affects every piece of software on the system,including the Windows kernel.

This switch was created to assist in Y2K testing. Next, Ntldr begins loading the files from the boot partition needed to start the kernel initialization: Loads the appropriate kernel and HAL images Ntoskrnl.

Figure Logical Disk Manager driver service settings Adds the file system driver that's responsible for implementing the code for the type of partition FAT, FAT32, or NTFS on which the installation directory resides to the list of boot drivers to load.

Prepares CPU registers for the execution of Ntoskrnl. Initializing the Kernel and Executive Subsystems When Ntldr calls Ntoskrnl, it passes a data structure that contains a copy of the line in Boot. These components perform the following initialization steps: The memory manager constructs page tables and internal data structures that are necessary to provide basic memory services.

The power manager's initialization is called. The progress bar is set to 5 percent. The progress bar is set to 10 percent. National language support NLS tables are mapped into system space. Global file system driver data structures are initialized. The progress bar is set to 20 percent.

The progress bar is set to 25 percent. The progress bar is set to 75 percent. If booting in safe mode, this fact is recorded in the registry. The progress bar is set to 80 percent.

The power manager is called to initialize various power management structures. The progress bar is set to 85 percent. The progress bar is set to 90 percent. Smss, Csrss, and Winlogon Smss is like any other user-mode process except for two differences: First, Windows considers Smss a trusted part of the operating system. Opens known DLLs. Creates additional paging files. Creates system environment variables.

That action brings us to the end of the boot process. Authors: David A. Solomon , Mark E. Reversing: Secrets of Reverse Engineering. Network Security Architectures. If you may any questions please contact us: flylib qtcs.

Privacy policy. This website uses cookies. Click here to find out more. Accept cookies. Reads Boot. Initializes executive subsystems and boot and system-start device drivers, prepares the system for running native applications, and runs Smss. Loads Win32 subsystem, including Win32k. Enables kernel-mode debugging and specifies anoverride for the default baud rate at which aremote kernel debugger host will connect. Causes the standard x86 multiprocessor HAL Halmps. Causes the kernel debugger to be loaded when the system boots, but to remain inactive unless a crash occurs.

Enables kernel-mode debugging and specifies an override for the default serial port COM1 to which a remote kernel-debugger host is connected. Default boot option for Windows Directs the standard x86 multiprocessor HAL Halmps. Enable you to override Ntldr's default filename for the kernel image Ntoskrnl.

Limits Windows to ignore not use physicalmemory beyond the amount indicated. For the standard x86 multiprocessor HAL Halmps. Prevents kernel-mode debugging from being initialized. Instructs Windows not to initialize the VGA video driver responsible for presenting bitmapped graphics during the boot process. Specifies the number of CPUs that can be used on a multiprocessor system. Causes Ntldr to load Ntkrnlpa. The PAE version of the kernel presents bit physical addresses to device drivers, so this switch is helpful for testing device driver support for large memory systems.

If Ntldr is running on an x64 system and the kernel specified by the entry selected in the boot menu is for x64, Ntldr switches the processor to long mode , where the native word size is bits. Next, Ntldr begins loading the files from the boot volume needed to start the kernel initialization. The steps Ntldr follows here include:. Loads the appropriate kernel and HAL images Ntoskrnl. If Ntldr fails to load either of these files, it prints the message "Windows could not start because the following file was missing or corrupt", followed by the name of the file.

A hive is a file that contains a registry subtree. You'll find more details about the registry in Chapter 4. Boot device drivers are drivers necessary to boot the system. For a detailed description of the Services registry entries, see the section "Services" in Chapter 4. Adds the file system driver that's responsible for implementing the code for the type of partition FAT, FAT32, or NTFS on which the installation directory resides to the list of boot drivers to load.

Ntldr must load this driver at this time; if it didn't, the kernel would require the drivers to load themselves, a requirement that would introduce a circular dependency. Loads the boot drivers, which should only be drivers that, like the file system driver for the boot volume, would introduce a circular dependency if the kernel was required to load them. To indicate the progress of the loading, Ntldr updates a progress bar displayed below the text "Starting Windows".

The progress bar moves for each driver loaded. It assumes there are 80 boot device drivers each successful load moves the progress bar by 1. Keep in mind that the drivers are loaded but not initialized at this time they initialize later in the boot sequence.

This action is the end of Ntldr's role in the boot process. At this point, Ntldr calls the main function in Ntoskrnl. Table lists the files involved in the IA64 boot process.

The boot code reads the IAequivalent of the x86 and x64 Boot. Hardware detection occurs next, where the boot loader uses EFI interfaces to determine the number and type of the following devices:. Just as Ntldr does on x86 and x64 systems, the boot loader then presents a menu of boot selections with an optional timeout. Once a boot selection is made, the loader navigates to the subdirectory on the EFI System partition corresponding to the selection and loads several other files required to continue the boot: Fpswa.

The first installation is assigned the folder Winnt50, the second Winnt When Ntldr calls Ntoskrnl, it passes a data structure that contains a copy of the line in Boot.

Ntoskrnl then begins the first of its two-phase initialization process, called phase 0 and phase 1. Most executive subsystems have an initialization function that takes a parameter that identifies which phase is executing. During phase 0, interrupts are disabled. The purpose of this phase is to build the rudimentary structures required to allow the services needed in phase 1 to be invoked. KiInitializeKernel , if running on the boot CPU, performs systemwide kernel initialization, such as initializing internal listheads and other data structures that all CPUs share.

Each instance of KiInitializeKernel then calls the function responsible for orchestrating phase 0, ExpInitializeExecutive. One responsibility of HalInitSystem is to prepare the system interrupt controller of each CPU for interrupts and to configure the interval clock timer interrupt, which is used for CPU time accounting.

Next, ExpInitializeExecutive calls the phase 0 initialization routines for the memory manager, object manager, security reference monitor, process manager, and Plug and Play manager. These components perform the following initialization steps:. The memory manager constructs page tables and internal data structures that are necessary to provide basic memory services. The memory manager also builds and reserves an area for the system file cache and creates memory areas for the paged and nonpaged pools.

The other executive subsystems, the kernel, and the device drivers use these two memory pools for allocating their data structures. During the object manager initialization, the objects that are necessary to construct the object manager namespace are defined so that other subsystems can insert objects into it. A handle table is created so that resource tracking can begin.

The security reference monitor initializes the token type object and then uses the object to create and prepare the first local system account token for assignment to the initial process. See Chapter 8 for a description of the local system account. The process manager performs most of its initialization in phase 0, defining the process and thread object types and setting up lists to track active processes and threads.

The process manager also creates a process object for the initial process and names it Idle. As its last step, the process manager creates the System process and a system thread to execute the routine Phase1Initialization. This thread doesn't start running right away because interrupts are still disabled. The Plug and Play manager's phase 0 initialization then takes place, which involves simply initializing an executive resource used to synchronize bus resources. When control returns to the KiInitializeKernel function on each processor, control proceeds to the Idle loop, which then causes the system thread created in step 4 of the previous process description to begin executing phase 1.

Secondary processors wait to begin their initialization until step 5 of phase 1, described in the following list. Phase 1 consists of the following steps. The boot splash screen of Windows systems includes a progress bar, and the steps at which the progress bar on the screen is updated are included in this list:.

HalInitSystem is called to prepare the system to accept interrupts from devices and to enable interrupts. On Windows XP and Windows Server systems, the driver presents the same graphic that Ntldr placed on the screen earlier in the boot.

The system time is initialized by calling HalQueryRealTimeClock and then stored as the time the system booted. On a multiprocessor system, the remaining processors are initialized and execution starts.

The executive is called to create the executive object types, including semaphore, mutex, event, and timer. The kernel initializes scheduler dispatcher data structures and the system service dispatch table. The memory manager is called to create the section object and the memory manager's system worker threads which are explained in Chapter 7. National language support NLS tables are mapped into system space. The cache manager initializes the file system cache data structures and creates its worker threads.

This stage is a complex phase of system startup that accounts for 50 percent of the "progress" reported in the progress bar. If there are more than 25 drivers to load, the progress bar stops at 75 percent.

It then calls the Plug and Play manager, power manager, and HAL to begin the various stages of dynamic device enumeration and initialization. See the section "Windows Management Instrumentation" in Chapter 4 for more information. Next, all the boot-start drivers are called to perform their driver-specific initialization, and the system-start device drivers are loaded and initialized.

Details on the processing of the driver load control information on the registry are also covered in Chapter 9. If the computer is booting in safe mode, this fact is recorded in the registry.

Unless explicitly disabled in the registry, paging of kernel-mode code in Ntoskrnl and drivers is enabled. The power manager is called to initialize various power management structures. The security reference monitor is called to create the Command Server Thread that communicates with Lsass. See the section "Security System Components" in Chapter 8 for more on how security is enforced in Windows. The last step is to create the Session Manager subsystem Smss process introduced in Chapter 2.

Smss is responsible for creating the user-mode environment that provides the visible interface to Windows its initialization steps are covered in the next section. As a final step before considering the executive and kernel initialization complete, the phase 1 initialization thread waits for the handle to the Session Manager process with a timeout value of 5 seconds. If the 5-second wait times out that is, if 5 seconds elapse , the Session Manager is assumed to have started successfully, and the phase 1 initialization function calls the memory manager's zero page thread function explained in Chapter 7.

Thus, this system thread becomes the zero page thread for the remainder of the life of the system. Smss is like any other user-mode process except for two differences: First, Windows considers Smss a trusted part of the operating system.

Second, Smss is a native application. Because it's a trusted operating system component, Smss can perform actions few other processes can perform, such as creating security tokens. In fact, one of Smss's first tasks is to start the Windows subsystem. Smss then calls the configuration manager executive subsystem to finish initializing the registry, fleshing the registry out to include all its keys. Typically, this value contains one command to run Autochk the boot-time version of Chkdsk.

Creates additional paging files. Initializes the registry. Loads the kernel-mode part of the Windows subsystem Win32k. Smss determines the location of Win32k. The initialization code in Win32k. Starts the subsystem processes, including Csrss. Starts the logon process Winlogon. The startup steps of Winlogon are described shortly. Pending File Rename Operations The fact that executable images and DLLs are memory-mapped when they are used makes it impossible to update core system files after Windows has finished booting.

Service Packs and hotfixes that must update in-use memorymapped files install replacement files onto a system in temporary locations and use the MoveFileEx API to have them replace otherwise in-use files. Delete operations use an empty string as their target path. After performing these initialization steps, the main thread in Smss waits forever for the process handles to Csrss and Winlogon.

If either of these processes terminates unexpectedly, Smss crashes the system, because Windows relies on their existence. Winlogon then performs its startup steps, such as creating the initial window station and desktop objects. For more details on the startup sequence for Winlogon and Lsass, see the section "Winlogon Initialization" in Chapter 8. After the SCM initializes the auto-start services and drivers and a user has successfully logged on at the console, the SCM deems the boot successful.

Because noninteractive servers might never have an interactive logon, they might not get LastKnownGood updated to reflect the control set used for a successful boot. When it receives a logon and validates the logon a process for which you can find more information in the section "User Logon Steps" in Chapter 8 , Winlogon loads the registry hive from the profile of the user logging in and maps it to HKCU.

Winlogon next tells the GINA to start the shell. Because machine scripts run after user scripts, they can override user settings. If that value doesn't exist, Userinit. Winlogon then notifies registered network providers that a user has logged in. Figure shows the process tree as seen in Process Explorer during a login before Userinit has exited.

In addition to the Userinit and Shell registry values in Winlogon's key, there are many other registry locations and directories that default system components check and process for automatic process startup during the boot and logon process. By default, Autoruns shows only the locations that are configured to automatically execute at least one image, but checking the Include Empty Locations entry in the View menu causes Autoruns to show all the locations it inspects.

The View menu also has selections to direct Autoruns to display information about other types of autostarting images, such as Windows services and Explorer add-ons.