Booting Windows
11.3.2 Booting Windows
Getting an operating system to run requires several steps. When a computer is turned on, the first processor is initialized by the hardware, and then set to start ex- ecuting a program in memory. The only available code is in some form of non- volatile CMOS memory that is initialized by the computer manufacturer (and sometimes updated by the user, in a process called flashing). Because the software persists in memory, and is only rarely updated, it is referred to as firmware. The firmware is loaded on PCs by the manufacturer of either the parentboard or the computer system. Historically PC firmware was a program called BIOS (Basic Input/Output System), but most new computers use UEFI (Unified Extensible Firmware Interface ). UEFI improves over BIOS by supporting modern hard- ware, providing a more modular CPU-independent architecture, and supporting an extension model which simplifies booting over networks, provisioning new ma- chines, and running diagnostics.
The main purpose of any firmware is to bring up the operating system by first loading small bootstrap programs found at the beginning of the disk-drive parti- tions. The Windows bootstrap programs know how to read enough information off
a file-system volume or network to find the stand-alone Windows BootMgr pro- gram. BootMgr determines if the system had previously been hibernated or was in stand-by mode (special power-saving modes that allow the system to turn back on without restarting from the beginning of the bootstrap process). If so, BootMgr loads and executes WinResume.exe. Otherwise it loads and executes WinLoad.exe to perform a fresh boot. WinLoad loads the boot components of the system into memory: the kernel/executive (normally ntoskrnl.exe), the HAL (hal.dll), the file containing the SYSTEM hive, the Win32k.sys driver containing the kernel-mode parts of the Win32 subsystem, as well as images of any other drivers that are listed in the SYSTEM hive as boot drivers—meaning they are needed when the system first boots. If the system has Hyper-V enabled, WinLoad also loads and starts the hypervisor program.
Once the Windows boot components have been loaded into memory, control is handed over to the low-level code in NTOS which proceeds to initialize the HAL,
CHAP. 11 kernel, and executive layers, link in the driver images, and access/update configu-
CASE STUDY 2: WINDOWS 8
ration data in the SYSTEM hive. After all the kernel-mode components are ini- tialized, the first user-mode process is created using for running the smss.exe pro- gram (which is like /etc/init in UNIX systems).
Recent versions of Windows provide support for improving the security of the system at boot time. Many newer PCs contain a TPM (Trusted Platform Mod- ule ), which is chip on the parentboard. chip is a secure cryptographic processor which protects secrets, such as encryption/decryption keys. The system’s TPM can
be used to protect system keys, such as those used by BitLocker to encrypt the disk. Protected keys are not revealed to the operating system until after TPM has verified that an attacker has not tampered with them. It can also provide other cryptographic functions, such as attesting to remote systems that the operating sys- tem on the local system had not been compromised.
The Windows boot programs have logic to deal with common problems users encounter when booting the system fails. Sometimes installation of a bad device driver, or running a program like regedit (which can corrupt the SYSTEM hive), will prevent the system from booting normally. There is support for ignoring re- cent changes and booting to the last known good configuration of the system. Other boot options include safe-boot, which turns off many optional drivers, and the recovery console, which fires up a cmd.exe command-line window, providing an experience similar to single-user mode in UNIX.
Another common problem for users has been that occasionally some Windows systems appear to be very flaky, with frequent (seemingly random) crashes of both the system and applications. Data taken from Microsoft’s Online Crash Analysis program provided evidence that many of these crashes were due to bad physical memory, so the boot process in Windows provides the option of running an exten- sive memory diagnostic. Perhaps future PC hardware will commonly support ECC (or maybe parity) for memory, but most of the desktop, notebook, and handheld systems today are vulnerable to even single-bit errors in the tens of billions of memory bits they contain.
Parts
» The Second Generation (1955–65): Transistors and Batch Systems
» The Third Generation (1965–1980): ICs and Multiprogramming
» The Fourth Generation (1980–Present): Personal Computers
» System Calls for Process Management
» System Calls for Directory Management
» RESEARCH ON OPERATING SYSTEMS
» Implementing Threads in User Space
» Implementing Threads in the Kernel
» Making Single-Threaded Code Multithreaded
» Mutual Exclusion with Busy Waiting
» Avoiding Locks: Read-Copy-Update
» Scheduling in Interactive Systems
» Scheduling in Real-Time Systems
» The Dining Philosophers Problem
» The Readers and Writers Problem
» The Notion of an Address Space
» Page Tables for Large Memories
» DESIGN ISSUES FOR PAGING SYSTEMS
» Segmentation with Paging: MULTICS
» Segmentation with Paging: The Intel x86
» An Example Program Using File-System Calls
» Device-Independent I/O Software
» Disk Arm Scheduling Algorithms
» Preemptable and Nonpreemptable Resources
» Deadlock Detection with One Resource of Each Type
» Deadlock Detection with Multiple Resources of Each Type
» The Banker’s Algorithm for Multiple Resources
» REQUIREMENTS FOR VIRTUALIZATION
» TYPE 1 AND TYPE 2 HYPERVISORS
» TECHNIQUES FOR EFFICIENT VIRTUALIZATION
» ARE HYPERVISORS MICROKERNELS DONE RIGHT?
» Challenges in Bringing Virtualization to the x86
» VMware Workstation: Solution Overview
» ESX Server: VMware’s type 1 Hypervisor
» Multiprocessor Operating System Types
» Multiprocessor Synchronization
» Low-Level Communication Software
» User-Level Communication Software
» Network Services and Protocols
» File-System-Based Middleware
» Coordination-Based Middleware
» Authentication Using a Physical Object
» Authentication Using Biometrics
» Antivirus and Anti-Antivirus Techniques
» Model-Based Intrusion Detection
» Process-Management System Calls in Linux
» Implementation of Processes and Threads in Linux
» Implementation of the Linux File System
» NFS: The Network File System
» HISTORY OF WINDOWS THROUGH WINDOWS 8.1
» The Native NT Application Programming Interface
» The Win32 Application Programming Interface
» Implementation of the Object Manager
» Subsystems, DLLs, and User-Mode Services
» Job, Process, Thread, and Fiber Management API Calls
» Implementation of Processes and Threads
» Memory-Management System Calls
» Implementation of Memory Management
» Why Is It Hard to Design an Operating System?
» Static vs. Dynamic Structures
» Synchronous vs. Asynchronous Communication
» TRENDS IN OPERATING SYSTEM DESIGN
» SUGGESTIONS FOR FURTHER READING
Show more