1. 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.
2. 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.
3. 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.

  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). This is a non-fatal POST error message.
• "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). This is a non-fatal POST error message.
• "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, Windows NT-based operating system system startup file #1). 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 Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7). 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:
1. 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.
2. Current: Points to the last control set which was used to start the system.
3. 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.
4. 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 (Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6).
  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) (in user-mode and not a Windows service unless started by the Service Control Manager (SCM))
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.

• (HKLM) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager: 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.
• (HKLM) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems: Contains a list of available subsystems, e.g., Csrss.exe contains the user-mode portion of the Windows subsystem.
• (HKLM) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\servicename: 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: (in user-mode and not a Windows service unless started by the Service Control Manager (SCM))
  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).

There are three principal times that configuration data is read:

1. 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.
2. During logon, Explorer and other Windows components read per-user configuration settings/preferences from the registry.
3. 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.

1. HKEY_LOCAL_MACHINE                 (HKLM)
2. HKEY_CURRENT_USER                  (HKCU)
3. HKEY_CLASSES_ROOT                  (HKCR)
4. HKEY_USERS                                (HKU)
5. HKEY_CURRENT_CONFIG               (HKCC)
6. 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).

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:
1. REG_BINARY
2. REG_DWORD
3. REG_EXPAND_SZ
4. REG_MULTI_SZ
5. REG_SZ
6. REG_RESOURCE_LIST
7. REG_RESOURCE_REQUIREMENTS_LIST
8. REG_FULL_RESOURCE_DESCRIPTOR
9. REG_NONE
10. REG_LINK
11. REG_QWORD
12. REG_QWORD_LITTLE_ENDIAN
13. REG_QWORD_BIG_ENDIAN
14. REG_DWORD_LITTLE_ENDIAN
15. 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.

1. HKEY_LOCAL_MACHINE - (HKLM)

HKLM 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 SYSYTEM (hive file path: \Windows\System32\Config\System). The HARWARE subkey maintains hardware-orientated information, such as the system’s hardware and all hardware device-to-drivers 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. 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. The SAM subkey holds local account and group information, e.g., user password, group definitions, and domain associations. The SECURITY subkey stores a substantial amount of security related information, such as systemwide security polices and user-rights assignments. The SAM subkey is linked into the SECURITY subkey under HKLM\SECURITY\SAM. The SOFTWARE subkey is where Windows stores systemwide configuration information not required in booting the system. Moreover, third-party applications store their systemwide settings here also, e.g., paths to application files and directories, and licensing and expiration date information. The SYSTEM subkey contains the systemwide configuration information needed in booting the system, e.g., device drivers to load and which services to start. As this information is vital for starting the system, Windows also maintains a copy of part of this information, called the Last Known Good control set, under this key. The maintenance of a copy allows the user to select the Last Known Good control set in the event that configuration changes made to the current control set prevent the system from booting due to current hardware settings, instability and startup problems caused by a driver and so forth, rolling back the system’s registry configuration to a successful booting state. When the Last Known Good Configuration is used, restoring previous drivers and registry settings for the subkey HKLM\SYSTEM\CurrentControlSet loses all configuration changes that were made since the last successful logon. The Last Known Good Configuration is a useful mechanism for getting a system that crashes during the boot process back to a bootable state.

2. HKEY_CURRENT_USER - (HKCU)

The HKCU rook key contains data regarding the preferences and software configuration of the locally logged-on user. It points to the currently logged-on user’s user profile for the user logged on to the computer the registry serves, located on the hard disk drive at HKEY_USER\<security ID of username> (hive file path: \Documents and Settings<username.\Ntuser.dat). Whenever a user profile is loaded, as at logon or when a service process runs under the context of a specific username, HKCU is created as a link to the user’s key under HKCU. HKCU subkeys are: AppEvent, Console, Control Panel, Environment, Keyboard Layout, Network, Printers, Software, UNICODE Program Groups and Windows 3.1 Migration Status. This information is mapped from the HKEY_USERS hive key's Security ID (SID) subkey for the currently logged on user.

3. HKEY_CLASSES_ROOT – (HKCR)

The HKCR root key consists of two types of information: file extension association (currently associated with applications) and COM class registrations (COM (OLE)) servers registered on the computer). A key exists for every registered filename extension. Most keys contain a REG_SZ value (string format) that points to another key in HKCR containing the association information for the class of files that extension represents. For example, HKCR\.doc would point to the information on Microsoft Word files in a key such as HKCR\Word.financial affairs. Other keys contain configuration details for COM objects registered on the system.

  The user data HKCR comes from is two source root keys, HKLM and HKU:

• The per-user class registration data in HKCR\SOFTWARE\Classes or HKU\<security ID of username>_Classes (mapped to the file on the hard disk drive \Documents and Settings\<username>\Local Settings\Application Data\Microsoft\Windows\Usrclass.dat).
• Systemwide class registration data in HKLM\SOFTWARE\Classes.

  The purpose of the separation of per-user registration data from systemwide registration data is so that roaming profiles can contain these customisations. It also closes a security hole: a non-privileged user cannot change or delete keys in the systemwide version HKCR, and therefore cannot affect the operation of applications on the system. Non-privileged users and application can read systemwide data and can add new keys and existing keys and values in their private data only.

4. HKEY_USER – (HKU)

The HKU root key contains a subkey for each loaded user profile and user class registration database on the system. It also contains a subkey called HKU\.DEFAULT (hive file path: \Windows\System32\Config\Default) that is linked to the profile for the system used by processes running under the local system account. When a user logs on to a system for the first time and their account does not depend on a roaming domain profile, i.e., the user’s profile is obtained from a central network location at the direction of a domain controller, the system creates a profile for their account that is based on the profile stored in C:\Documents and Settings\Default User.
  The location under which the system stores profiles is defined by the registry value HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory, which is by default set to the environmental variable %SystemDrive%\Documents and Settings. The ProfileList key also stores the list of profiles present on a system. Information for each profile resides under a subkey that has a name reflecting the Security Identifier (SID) of the account which the profile corresponds. Data stored in a profile’s key includes the time of the last load of the profile, the binary representation of the account SID, and the path to the profile’s on-disk hive. For Windows XP and Server 2003 the list of profiles stored on a system are shown in the User Profiles management dialog box (Settings>User Profiles>Advanced Tab in Control Panel).

5. HKEY_CURRENT_CONFIG – (HKCC)

The HKCC root key is simply a link to the current hardware profile, stored under HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current. Hardware profiles allow the administrator to configure variations to the base system driver settings. Although the underlying profile might change from boot to boot, applications can always reference the currently active profile through this key. Hardware profile management is managed through the Hardware Profile dialog box, Settings>Hardware Profiles on the Hardware Tab in the Control Panel’s System Properties applet (sysdm.cpl). During the boot process, Ntldr will prompt the user to specify which profile it should use if there is more than one to choose from.

6. HKEY_PERFORMANCE_DATA – (HKD)

The mechanism to access performance counter values in Windows is through the registry, whether those are from operating system components or server applications.
  The total size allowed for the registry database, stored in a paged pool (a proportion of the virtual memory that is written to physical disk when not in use). By default the registry size is 33 per cent of the size of the paged pool but has an upper limit of 80 per cent. It is only necessary to change the registry’s maximum size allowed for the registry database if the computer is a domain controller for a very large network or if an error message is displayed warning that the registry database is too small. The simplest route to increasing the maximum allowed size of the registry database is by clicking on the System Properties (sysdm.cpl) applet in the Control Panel>Advanced Tab>Performance Options>Virtual Memory>Change>Registry size.
  The registry editor is not the only tool used to directly manipulate the Windows NT family operating system. Other tools include, the Microsoft Management Console (MMC), the Control Panel applets (around nineteen applets), user profiles using the System Policy Editor (SPE, poledit.exe), the Group Policies using the Group Policy MMC snap-in, and a command-line tool called REG.
  Systems and applications depend heavily on configuration settings to guide their behaviour. Consequently, system and application failures can occur from changing registry or security data. When a system or application fails to read settings that it assumes will remain accessible, a system may suffer a system halt failure and/or an application may fail to initialise or function correctly, displaying error messages that may hide the root cause of the failure or problem. For this reason, problems where the registry is implicated may be intractable to solve. Genie-soft’s Backup Manager family will backup and restore the complete registry or a portion of it with ease.  This may save many hours of fruitless troubleshooting.
  Side note: The HKU\.Default is the location of all settings that were given to every new user. Consequently, if a user registry error is undesirable and if the entry changed by the user does not exist in HKU\.Default then it must have been added to HKCU. Deleting the entry in HKCU will restore it back to the default value and fix the problem.
  Registry editing is for advanced users only. Damaging the registry in some way is not immediately detected by the system but can cause the damaged copy to be considered the Last Known Good Configuration (the backup copy maintained for problems with registry corruption and so forth), which destroys the information needed to restore the system by replacing the previous (working) copy. For the less experienced user Genie Backup Manager (GBM) can at least backup a fully working registry or use a working registry backup to restore a system from intractable problems.
  One of the most intractable problems to resolve on a Windows XP system relates to registry corruption. There can be no guarantee that the solution described below will be completely successful, it may allow access to otherwise lost data on a non-OEM Windows installed operating system.

  The most common errors presented when starting a Windows XP-based operating system, for example, are as follows:

1. Windows XP could not start because the following file is missing or corrupt:

“…\WINDOWS\SYSTEM32\CONFIG\SYSTEM”

2. Windows XP could not start because the following file is missing or corrupt:

“…\WINDOWS\SYSTEM32\CONFIG\SOFTWARE”

3. Stop: c0000218 {Registry File Failure} The registry cannot load the hive (file):

“\SystemRoot\System32\Config\SOFTWARE” - or its log or alternate.

  The procedure requires the use of the Recovery Console (RC) and System Restore (SR). In order to ensure a high probability of success, the recovery process prescribed below is required to be performed in a specific order, so that the system returns to a state as close a possible, prior to the failure.

Stage 1:
  Start the RC, create a temporary folder, back up the existing registry files to a new location, delete the registry files at their existing location, and then copy the registry files from the repair folder to the System32\Config folder. A new registry is created that can be used to start Windows XP. This registry was created and saved during the initial setup of Windows XP. Therefore any changes and settings that occurred after the Setup program was finished are lost.
  To complete part one, follow these steps:

1. Insert the Windows XP startup disk into the floppy diskette drive, or insert the Windows XP CD-ROM into the CD-ROM drive, and then restart the computer. Click to select any options that are required to start the computer from the CD-ROM drive if you are prompted to do so.
2. When the "Welcome to Setup" screen appears, press R to start the RC.
3. For dual-boot or multiple-boot system setups, select the problem installation to access from the RC.
4. When prompted, type the Administrator password. If the administrator password is blank, press ENTER.
5. At the RC command prompt, type the following lines, pressing ENTER after typed line:

md tmp
copy c:\windows\system32\config\system c:\windows\tmp\system.bak
copy c:\windows\system32\config\software c:\windows\tmp\software.bak
copy c:\windows\system32\config\sam c:\windows\tmp\sam.bak
copy c:\windows\system32\config\security c:\windows\tmp\security.bak
copy c:\windows\system32\config\default c:\windows\tmp\default.bak

delete c:\windows\system32\config\system
delete c:\windows\system32\config\software
delete c:\windows\system32\config\sam
delete c:\windows\system32\config\security
delete c:\windows\system32\config\default

copy c:\windows\repair\system c:\windows\system32\config\system
copy c:\windows\repair\software c:\windows\system32\config\software
copy c:\windows\repair\sam c:\windows\system32\config\sam
copy c:\windows\repair\security c:\windows\system32\config\security
copy c:\windows\repair\default c:\windows\system32\config\default

6. Exit the RC, and reboot the computer.

  Note: The procedure described above assumes that Windows XP is installed to the C:\WINDOWS folder. If this is not the case, ensure that all references point to the appropriate Windows folder if it is a different location.

Stage 2:
  To complete the following procedure described, either log on as an administrator, or an administrative user (a user who has an account in the Administrators group). Under Windows XP, log on as an administrative user. Logged on as an administrator, it is important first to start Windows XP in Safe Mode (SM). Refer to the SM entry within “More Than Just A Glossary”
  Copy the registry files from their backed up location by using SR. This folder is not available in the RC and is generally not visible during typical usage. Before continuing with this procedure, change several settings to make the folder visible:

1. Start Windows Explorer.
2. On the Tools menu, click Folder Options…
3. Click the View tab.
4. Under Hidden files and folders, select Show hidden files and folders; click to clear the Hide protected operating system files (Recommended) check box.
5. Click Yes on the dialog box to confirm the displaying of these files.
6. Double-click the drive where Windows XP is installed to display a list of the folders. It is important to click the correct drive.
7. Open the System Volume Information folder. (The System Volume Information folder is a hidden system folder that the SR tool uses to store its information and restore points. There is a System Volume Information folder on every voluem). This folder is unavailable and appears dimmed because it is set as a super-hidden folder.

  Note: This folder contains one or more _restore {GUID} folders such as:
"_restore{87BD3667-3246-476B-923F-F86E30B3E7F8}"

  You may receive the following error message:

C:\System Volume Information is not accessible. Access is denied.

Gaining access to the System Volume Information folder: Windows XP Professional & Home (FAT32 filesystem).

• Click Start; then click My Computer.              
• On the Tools menu, click Folder Options...   
• Click the View tab.
• Under Hidden files and folders, select Show hidden files and folders; click to clear the Hide protected operating system files (Recommended) check box.
• Click Yes on the dialog box to confirm the displaying of these files.
• Click OK.              
• Double-click the System Volume Information folder in the root folder to open it.

Gaining access to the System Volume Information folder: Windows XP Professional (NTFS file system on a Domain).

• Click Start; then click My Computer.              
• On the Tools menu, click Folder Options...   
• Click the View tab.
• Under Hidden files and folders, select Show hidden files and folders; click to clear the Hide protected operating system files (Recommended) check box.
• Click Yes on the dialog box to confirm the displaying of these files.
• Click OK.              
• Right-click the System Volume Information folder in the root folder, then click Sharing and Security
• Click the Security tab.        
• Click Add; then type the name of the user to permit access to the folder. Choose the account location if appropriate (either local or from the domain). Typically, this is the logged on account. Click OK, then OK again.
• Double-click the System Volume Information folder in the root folder to open it.

8. Open a folder that was not created at the current time. You may have to click Details on the View menu to see when these folders were created. There may be one or more folders starting with "RPx” under this folder. These are restoring points.
9. Open one of these folders to locate a Snapshot subfolder. The following path is an example of a folder path to the Snapshot folder:

C:\System Volume Information\_restore{D86480E3-73EF-47BC-A0EB-A81BE6EE3ED8}\RP1\Snapshot

10. _REGISTRY_USER_.DEFAULT

• _REGISTRY_MACHINE_SECURITY
• _REGISTRY_MACHINE_SOFTWARE
• _REGISTRY_MACHINE_SYSTEM
• _REGISTRY_MACHINE_SAM

11. Rename the files in the C:\WINDOWS\Tmp folder as follows:

• Rename _REGISTRY_USER_.DEFAULT to DEFAULT
• Rename _REGISTRY_MACHINE_SECURITY to SECURITY
• Rename _REGISTRY_MACHINE_SOFTWARE to SOFTWARE
• Rename _REGISTRY_MACHINE_SYSTEM to SYSTEM
• Rename _REGISTRY_MACHINE_SAM to SAM

  These files are the backed up registry files from SR. Because the registry file that the Setup program created is to be used, this registry does not know that these restore points exist and are available. A new folder is created with a new GUID under System Volume Information and a restore point is created that includes a copy of the registry files that were copied during Stage 1. Therefore, it is important not to use the most current folder, especially if the time stamp on the folder is the same as the current time.
  The current system configuration is not aware of the previous restore points. In order to make the previous restore points available again, the previous copy of the registry from a previous restore point must be used.
  The registry files that were copied to the Tmp folder in the C:\WINDOWS folder are moved to make sure that the files are available under the RC. These files must be used to replace the registry files currently in the C:\WINDOW\System32\Config folder. By default, the RC has limited folder access and cannot copy files from the System Volume folder.
  Note: The procedure described assumes that the file system is FAT32. For a NTFS file system see, Gaining access to the System Volume Information folder: Windows XP Professional (NTFS file system on a Domain).
  Note: Ensure that all five of the registry hives are replaced. It is inadvisable to replace only a single hive or two, as this can cause potential issues; software and hardware may have settings in multiple locations in the registry.

Stage 3:
 The final stage requires that the existing registry files be deleted, and then to copy the SR registry files to the C:\WINDOWS\System32\Config folder:

1. Start Recovery Console (or by using a Windows 98 Boot Diskette).
2. At the command prompt, type the following lines, pressing ENTER after each line:

del c:\windows\system32\config\sam
del c:\windows\system32\config\security
del c:\windows\system32\config\software
del c:\windows\system32\config\default
del c:\windows\system32\config\system

copy c:\windows\tmp\software c:\windows\system32\config\software
copy c:\windows\tmp\system c:\windows\system32\config\system
copy c:\windows\tmp\sam c:\windows\system32\config\sam
copy c:\windows\tmp\security c:\windows\system32\config\security
copy c:\windows\tmp\default c:\windows\system32\config\default

3.  Exit the RC, and reboot the computer.

  Note: The procedure described above assumes that Windows XP is installed to the C:\WINDOWS folder. If this is not the case, ensure that all references point to the appropriate Windows folder if it is a different location.
  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 presented 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: Boot.ini, GUI (Graphical User Interface, spoken as GU-EE), Last Known Good Configuration, Symbolic Link (or Junction), Windows Shutdown, and Windows NT-Based Startup Phases.

 HKCU\Control Panel\Desktop\WaitToKillAppTimeout

  Csrss displays the hung-program dialog box.
  Winlogon has Csrss terminate any COM processes that are part of the interactive logon session.
  Now that all the processes in the interactive user’s session have been terminated, Winlogon instructs Csrss to search for all the processes belonging to the system context and performs and sends the WM_QUERYENDSESSION/WM_ENDSESSION message pair to GUI threads. Instead of sending CTRL_LOGOFF_EVENT, however, it sends CTRL_SHUTDOWN_EVENT to console applications that have a registered controlled handler, e.g., SCM. Csrss encounters the SCM process, it also notifies it that the system is shutting down but employs a timeout specified by SCM. Csrss recognises the SCM using the process ID Csrss saved when the SCM registered communications with Csrss during system initialisation. The SCM’s shutdown handler is responsible for sending shutdown notifications to all the services that registered shutdown notification when they initialised with the SCM. The SCM will cycle through its services database searching for services requesting shutdown notifications and sends each one a shutdown command. For each service to which it sends a shutdown command, the SCM records the value of the service’s wait hint, a value that a service also specifies when it registers with the SCM. The SCM keeps track of the largest wait hint it receives. After sending the shutdown commands, the SCM waits either until one of the services it notified of shutdown exits or until the time specified by the largest wait hint passes. If the wait hint expires without a service exiting, the SCM determines whether one or more of the services it was waiting on to exit have sent a message to the SCM signalling to the SCM that the service is progressing in its shutdown process. If the service is making progress the SCM waits again for the duration of the wait hint. The SCM continues executing this wait cycle until either all services have exited or none of the services upon which it is waiting has notified it of progress within the wait hint timeout progress.  Whilst the SCM is signalling services to shut down and waiting for them to exit, Csrss waits for the SCM to exit. If Csrss’s wait ends without the SCM having exited, Csrss moves on, continuing the shutdown process. Therefore, services that fail to shut down in a timely fashion are left running, consequently with the SCM, Smss, Winlogon and Lsass running while the system shuts down. Many processes are in fact running when the system shuts down.
  Once Csrss has finished its part notifying system processes that the system is shutting down, Winlogon finishes the shutdown process. All drivers and the rest of the executive subsystem, i.e., PnP Manager (supports device detection and installation during boot time and stop and start devices on demand i.e., a bus gains a new device and needs to have the device driver loaded to support that device), Power Manager (co-ordinates power events and generates power management I/O notifications to device drivers). When the system is idle, it can be configured to reduce power consumption by putting the CPU to sleep. Changes to power consumption by individual devices are handled by device drivers but are co-ordinated by the Power Manager), Executive, I/O Manager (implements device-independent I/O and is on the local computer. It guards operating system resources, performing run-time object protection and auditing via a collections of interfaces that different functional units (subsystems) of an information processing system uses to communicate with each other, or signals (inputs or information) sent and received through these interfaces from information outputting devices), Configuration Manager (programmed to know the location of core registry hives (or System hives) stored on disk and is responsible for implementing and managing them), and Memory Manager (implements virtual memory, a memory management scheme that provides a large, private address space for each process that can exceed available physical memory. The Memory Manager also provides the underlying support for the Cache Manager (it improves performance of file-based I/O (read and write) by causing recently referenced disk data to reside in the main memory for quick access, by deferring disk writes by holding the updates in memory for a short period of time before sending them to the disk – it does this by using the Memory Manager’s support for mapped files)).
  System shutdown ends with the Power Manager, and its action is dependent on whether the user has specified a shutdown, a reboot or a power down.
  Side note: The I/O Manager sends shutdown I/O packets to all device drivers that have requested a shutdown notification. This gives device drivers time to perform any special processing their drivers may require carrying out before Windows shuts down. The Configuration Manager flushes any modified registry data to disk, and the Memory Manager writes all modified pages containing file data back to the respective files. The Memory Manager will also clear the paging file if this has been enabled on shutdown also. The I/O Manager is recalled to inform the filesystem drivers that the system is shutting down.
  Note: The Windows startup phases have significantly changed for Windows Vista.
  See: Windows Services, Processes & Thread.