The Windows Startup and Shutdown Process

Introduction Have you ever wondered what Windows does when it starts up, or when it shuts down? In this thread I will be covering and going in-depth (to a certain extent) the process of Windows startup and shutdown. I must warn you, there will be some X rated content – if you faint at the sight of raw, naked technical information, I would advise you do not read this thread.

...who am I kidding, this is Overclock.net after all!

This thread covers the Windows startup and shutdown process in Windows NT 6.1 (i.e. Windows 7 and Windows 2008 R2). It does not cover the startup and shutdown process of previous or later versions, however with or Windows 8, you can expect minimal changes. Versions prior to Windows Vista (e.g. Windows XP) differ quite a bit, however.

I would expect that some of you probably already know much of this, but I am hoping that for those who do there are some extra tidbits that you didn’t know, and perhaps were even curious about. I know I certainly was asking many of the questions a long time ago that if I could go forward in time, would have been able to answer from this thread.

Topics covered  Windows boot installation  BIOS boot process o Windows setup program interaction o Getting up off the ground o The Windows Boot Manager  UEFI boot process  The Windows Boot Loader  Windows startup process o Kernel initialization . Phase zero initialization . Phase one initialization o Subsystem startup and interactive logon  Windows shutdown process o Initiating shutdown . User process termination  Windows GUI applications  Console applications and services . Powering off the system

Windows boot installation Before we even begin to describe the startup (or shut down for that matter!) process of Windows, there must be some steps prior. These steps are part of the Windows setup process, and while this thread will not be going into detail about the Windows setup process, this topic on Windows boot installation will briefly describe how the Windows setup process prepares the primary storage device (hard disk or solid state) on a legacy BIOS system, or UEFI nonvolatile RAM (NVRAM) with the code that begins the Windows boot process.

It is important to note here the term “boot process”. This is different from the Windows “startup process”, although they are often treated as encompassing of each other. There are two ways that Windows currently boots the system and this depends on your hardware:

1. The legacy BIOS boot process. 2. The newer UEFI boot process.

This thread will describe both boot processes, and then describe the unified Windows “startup process”, and finally the shutdown process.

BIOS boot process Going back to days when MS-DOS was dominant, and since then, there has been a standard on x86 computers that specifies the way that physical storage devices such as hard disks are separated. This is known as partitioning and recognized in Windows as logical storage devices.

The Windows BIOS boot components are primarily made up of the Master Boot Record (MBR) and the system volume (also known as the boot partition). It is this boot partition that contains the bootable code for the rest of the system.

NOTE: Do not be confused between the system volume and the system partition. The system partition is where Windows is installed itself, while the system volume is of the type “System Partition”. From here, I will refer to the system volume as the boot partition, and system partition (where Windows files are actually installed) as itself. Windows setup program interaction starts with the Windows setup program – the first time you install Windows.

When the Windows setup program writes the Master Boot Record, it also writes to this bootable partition the boot code (which is part of the boot sector, also known as the Volume Boot Record, on this bootable partition).

Before the Windows setup program writes to the boot sector it must check to make sure that this boot partition is formatted with NTFS, which is the only file system that Windows supports booting (again, this is not the same as the system partition where Windows is installed, which can be formatted with any file system that Windows supports, e.g. FAT32). If the boot partition is not formatted with NTFS, Windows setup will format it, erasing anything on that partition.

After this stage, the Windows setup program then formats the partition to install Windows, copies the BOOTMGR file to the boot partition and initializes the Boot Configuration Database (BCD) which is also stored on the boot partition. The BCD stores information about the operating systems installed on the computer and how to boot them (even non- ones). This is what the Windows Boot Manager uses to display a menu and then, or, boot the selected or default .

Getting up off the ground The first sector of the boot partition (described above as the boot sector) contains the code needed to load the Windows Boot Manager. The way these two parts of the storage device interact during the boot process is described below.

When a legacy BIOS-based computer starts, the first piece of code that is executed is the BIOS itself, after which it selects a storage device and proceeds to read the MBR from it. If there is no MBR present, the BIOS will continue to try other storage devices, if any. If it exhausts them all without success, or there weren’t any more, an error message is displayed on the screen and the boot process stops here.

Assuming the BIOS has loaded a valid Master Boot Record into memory, the next task is for the MBR to find the boot partition that is described above. To start, the MBR scans the primary partition table which is located inside the MBR itself, looking for one with a special flag called “active”. This flag is the sign to the MBR code that the partition is bootable. The next stage now is to execute the code in the boot sector, which involves reading the Windows Boot Manager into memory and executing it.

The Windows Boot Manager As already described, the boot partition contains the BOOTMGR file (the Windows Boot Manager executable) and the Boot Configuration Database (BCD). The first sector of this partition, the boot sector, contains the minimal code necessary that is able to read the simple NTFS boot partition to load and begin executing the Windows Boot Manager. The file system code is only just enough – i.e. it can only simply read files on the NTFS partition and it cannot read more than one directory level.

Once the boot sector code has finished reading the BOOTMGR file into memory, it transfers the control of the processor (CPU) to the entry point of BOOTMGR. If this file cannot be found on the boot partition, the boot sector code then displays an error message that is dreaded by many of us – “BOOTMGR is missing”. The process then stops here – otherwise, the boot sector code has finished its job and the Windows Boot Manager now takes control of continuing to boot the system. BOOTMGR will be referred to as the Windows Boot Manager from now on.

NOTE: The BOOTMGR file is actually two files joined together: The first is STARTUP.COM and the second is BOOTMGR.EXE. When BOOTMGR is first executed, it begins in what is called the x86 real mode. In this mode, there is no such thing as virtual memory – all programs that run in this mode use memory addresses as direct physical addresses and only the first one megabyte (1MB) of physical memory is accessible.

The first thing that the Windows Boot Manager does is switch the x86 operation mode to what is called protected mode. There is still no virtual memory, but a full 32-bit physical address space is available. After protected mode is enabled, the Windows Boot Manager is active, but BIOS functions are still required for it to access devices such as the display and IDE storage. When the Windows Boot Manager must interface with the BIOS, it will temporarily switch back into real mode to perform the operation – BIOS services can only be executed in real mode.

The Windows Boot Manager then creates enough page table structures to be able to access memory below 16MB with paging turned on. After this, the Windows Boot Manager enables paging and executes in a mode called protected mode with paging. This is also the mode that Windows executes in normally.

The next stage for the Windows Boot Manager is to read what is in the Boot Configuration Database (BCD). After this, the screen is cleared, and what happens next depends what lives inside the BCD.

If the system was put into hibernation, there will be a flag set in the BCD and when the Windows Boot Manager notices this flag, it transfers execution to the WINRESUME.EXE program. This program will then read the contents of the HIBERFIL.SYS file into memory. After reading the hibernation state into memory (which contains a copy of the previously running kernel), WINRESUME.EXE transfers control to the portion of that kernel that is responsible for resuming the system, which will then restart all device drivers that were previously active and the boot process then ends here.

If this is a clean boot (i.e. no hibernation state), then the Windows Boot Manager will check the Boot Configuration Database (BCD) for operating system entries. If there is more than one, the Windows Boot Manager displays a menu for the user to choose which operating system to start. If there is only one, Windows Boot Manager skips the menu and loads that one, which will be WINLOAD.EXE for a Microsoft operating system. The intrinsic of the Boot Configuration Database is beyond the scope of this thread. This is then the end of the BIOS boot process, and the rest of the process continues with the Windows Boot Loader, described further below.

UEFI boot process Just like the legacy-BIOS system, the UEFI system also contains code that is programmed during Windows setup. However instead of writing this code to the storage device (like a hard disk or solid state drive), Windows setup installs it into the system’s nonvolatile RAM (NVRAM).

The Boot Configuration Database (BCD) is also stored here inside this NVRAM, rather than on the storage device. The boot code that is written by Windows setup in the UEFI NVRAM reads the contents of the BCD (just like the BIOS-based BOOTMGR did) and displays a menu to the user to select an operating system to start.

Resuming from hibernation in the UEFI boot process is the same as the BIOS process, except that the EFI Boot Manager loads the WINRESUME.EFI (instead of WINRESUME.EXE) file to read the hibernation state and restart the kernel. Otherwise, if there is no hibernation state and a Windows operating system is selected to start, the EFI Boot Manager loads the Windows Boot Loader as normal (WINLOAD.EFI).

As Windows presents an abstracted boot process, everything is the exact same that is described from here on regardless of UEFI or BIOS system (except that boot loader components are EFI instead of EXE files, and they use the EFI instead of the BIOS functions described in the BIOS boot process above).

The Windows Boot Loader For Windows operating systems started by the Windows Boot Manager, the next step in the process is the Windows Boot Loader, contained inside the WINLOAD.EXE program for legacy BIOS systems or WINLOAD.EFI for UEFI systems. At this stage, either BIOS or UEFI processes have been completed and we are now into booting a operating system (the Windows Boot Manager can also boot non-Microsoft operating systems).

The Windows Boot Manager is the core program that loads the files from the Windows installation to begin the NT kernel initialization. It is loaded by the Windows Boot Manager during the BIOS or UEFI boot process, after which the Windows Boot Manager no longer has a role in the process henceforth.

To start, the Windows Boot Loader loads files from the Windows installation volume required to initialize the kernel. This is done in a series of steps: 1. The applicable kernel and HAL files are loaded. These are NTOSKRNL.EXE and HAL.DLL by default. If either of these files do not load for any reason, the Windows Boot Loader displays an error on the screen that reads “Windows could not start because the following file was missing or corrupt”, and then displays the name of the file that failed to load. Dependencies of these two files are also loaded. 2. The default VGA font (VGAOEM.FON) is loaded. The same message in step one is displayed if this file fails to load for any reason. 3. The SYSTEM registry hive is loaded. This hive contains the information necessary so that the Windows Boot Loader knows which device drivers need to be loaded to successfully complete the boot, for example the storage controller driver. A list of SERVICE_BOOT_START drivers are gathered at this point – but they are not loaded yet. 4. The NTFS file system driver is loaded. This driver is loaded first, otherwise the boot time device drivers would need to load themselves, however because they are necessary for the boot, the file system driver must first be loaded, otherwise a circular dependency is introduced. 5. The boot time device drivers are now loaded. In practice, this should only be a couple of drivers, because it should only be ones that are necessary to prevent a circular dependency. The drivers, while loaded, are not yet initialized - driver initialization comes later in the boot process.

This is the end of the Windows Boot Loader. At this point, the Windows Boot Loader now having loaded the kernel image (NTOSKRNL.EXE), executes the KiSystemStartup function, transferring it control. NTOSKRNL.EXE and thus KiSystemStartup perform the rest of the process – referred to as the Windows startup process in the next section.

Windows startup process Kernel initialization The kernel initialization starts when the Windows Boot Loader calls the KiSystemStartup function of the kernel. When it calls this function, it passes a structure of boot information so that NTOSKRNL is able to continue booting the system and initializing the kernel.

The kernel initialization of NTOSKRNL is separated into two phases, named Phase 0 and Phase 1. We will call them phase zero and phase one here. Routines involved in kernel initialization have a parameter that NTOSKRNL passes to them to indicate in which phase of initialization they are running.

Why are the two NTOSKRNL initialization phases named zero (0) and one (1), rather than one (1) and two (2)? My guess is that someone had a giggle, as in programming many things start at zero rather than one – for example array indexes. Phase zero initialization In this primary phase, interrupts are first disabled. This is so that initialization can execute smoothly without external events interrupting the process. The KiSystemStartup routine now begins by first asking the Hardware Abstraction Layer (HAL) to initialize each processor on the system. The appropriate HAL for the system has already been loaded by the Windows Boot Loader, described above.

Next, the KiInitializeKernel routine is called on the processor that the system is booting from. This routine is responsible for initializing kernel code and data structures that is shared between all of the processors on the system.

After the shared kernel components are initialized, the boot processor continues in phase zero execution by transferring control to a routine called InitBootProcessor. Any other processors on the machine at this point only request the HAL to initialize the remainder of the system before phase zero is completed.

On the boot processor, the InitBootProcessor routine starts by doing the following:

1. Removes access to the specified amount of physical memory from the BCD option BURNMEMORY. 2. Initializes the translation between ANSI. OEM and Unicode text. 3. Prepares the kernel interrupt controller for each processor. 4. Initializes the processor clock timer interrupt.

After the above steps are completed, the routine then begins phase zero execution of some primary kernel components, which includes setting up more internal structures and validation of the Windows license information stored in the registry. Next, the memory manager initializes its page table structures and reserves an area of memory for the file system cache and initializes paged and non-paged pool which is memory used by the system and drivers.

Lastly, the InitBootProcessor routine initializes some other core kernel components:

 The is initialized. This system is responsible for the object namespace for providing access to device drivers, devices, and tracking resources such as window stations, files and other objects.  The process manager is initialized. During process manager initialization, it creates the very first process in the system – the . The System process is created during this step.  The plug and play manager is initialized. Not much happens here, as the plug and play manager simply initializes its required resources to synchronize access to hardware resources.

At the end of the InitBootProcessor routine, the last bit is to initialize the Deferred Procedure Call (DPC) structures for the processor, after which control is then transferred to the System Idle Process. This process then causes a special thread created in the System process to begin the second phase of initialization, called phase one initialization.

Phase one initialization At this point, still only the boot processor is involved in phase one initialization. The other processors on the system are initialized a little bit later during phase one initialization. Phase one initialization is the bulk of the kernel initialization during the boot, and takes up most of the boot time.

Firstly, any memory that is not needed is freed and then the thread running the phase one initialization sets it priority to the highest possible – this makes sure that it is not preempted during the initialization phase after the scheduler is started.

At this point, the HAL prepares all of the system interrupt handling and then subsequently turns on interrupts that up until now, were still disabled. After interrupts have been set up, the following steps occur:

1. The driver responsible for the boot screen is initialized (bootvid). This is the first point where you’ll see the black screen with a loading bar. Up until now, nothing has displayed on the screen – if you actually go and follow this real-time while your system is booting, you notice that getting to this step happens very fast. In most cases, you never even see this screen. 2. The initialization for the power manager is started. At this step, the time that the system has booted is also recorded. 3. Remaining processors in a multi-processor system are initialized. Once this is complete, the System process is modified so that it can run on all processors by changing its process affinity. 4. The object manager and the kernel executive are initialized. Here, the object manager creates the global namespaces and other directories, while the executive creates various objects such as semaphores and mutexes. At this point, the I/O manager also initializes device and driver objects. 5. The kernel scheduler is initialized. This is also known as the dispatcher, and is responsible for thread scheduling.

Once the above stages have been completed (I have left out a few really boring details), the next stages involve some memory manager initialization, the registry is properly initialized with the object manager and the cache manager starts its system threads and initializes data structures for file system caching.

Next, a list of drivers to start is created and SuperFetch and the prefetcher are initialized, after which file system drivers are asked perform some preliminary initialization.

If enabled (for example on Windows 7), the high resolution boot graphics are also initialized and the fancy “Starting Windows” screen is displayed. Otherwise, the black screen with the loading bar is kept on screen. The most complicated stage of phase one initialization is performed by the I/O manager, and this stage is what takes most of the boot time. During this stage, the I/O manager performs the following functions:

1. Initializes its data structures and registers its object types. 2. The plug and play manager is requested to perform enumeration and initialization of devices. 3. All of the boot and system drivers are finally initialized, which takes most of the time.

The next critical step is performed by the configuration manager. It checks to see that all of the processors on the system are identical in the features they support. If it determines that they are not, the system crashes.

At the end of phase one initialization, the power manager completes initializing and the Session Manager Subsystem (SMSS) is started. Any memory used by the parameters for booting the system is then freed and the startup process continues with SMSS, which is then described below.

NOTE: The thread that performs the phase one initializes now waits on the process handle of the Session Manager with a timeout of five seconds. If the Session Manager terminates within those five seconds, the system is crashed at this point and the error displayed on the screen will be SESSION5_INITIALIZATION_FAILED. Otherwise, the process is considered a success and this system thread then becomes the zero page thread for the memory manager, which is responsible for zeroing memory when it is freed by the system and applications.

Subsystem startup and interactive logon Post-kernel initialization starts with the Session Manager Subsystem (SMSS) process that was started just at the end of phase one. SMSS is a native application, meaning it uses Windows NT APIs rather than Win32 subsystem APIs. This is because one of the tasks of SMSS is actually loading the Win32 (and other) application subsystems. SMSS is also a trusted application that can perform many operations that normal applications cannot, mainly involving security.

The Session Manager Subsystem first marks itself, and its main thread as critical objects. This means that if either the process or thread exits unexpectedly, the system will crash with CRITICAL_OBJECT_TERMINATION displayed on the blue screen. Next, the registry initialization is completed and then SMSS performs some routines that tune the concurrency level for it.

The following process is then followed by SMSS:

1. The programs defined in HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Session Manager\BootExecute are read, and they are run. For example, the boot-time version of CHKDSK runs at this point to check the file systems on the storage devices attached. 2. The registry key at HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations (2) is read and any delayed file rename operations are now performed. This registry key is populated when a file in use needs to be renamed or moved. 3. System environment variables such as PROCESSOR_ARCHITECTURE are defined.

After these steps are completed, SMSS is then responsible for loading the list of subsystems to be started in each session, and session 0 initialization program (by default the Windows Start-Up Application, WININIT.EXE).

Next, SMSS creates the initial session (called session 0). This then executes a function named SmpCreateInitialSession which instructs the Client/Server Runtime Subsystem (CSRSS) to start in each created session. This is the Win32 subsystem startup, which is handled by CSRSS, performing the following tasks:

1. The kernel-mode portion of the Win32 subsystem (located in Win32k.sys) is loaded. 2. The initialization routine in this driver instructs the installed video driver to switch from VGA mode to the default screen resolution chosen for the system.

While CSRSS is initialized, any remaining SMSS processes will start other subsystems, for example PSXSS (which is the Posix/Unix Subsystem) if that feature is installed.

The SMSS process executing in session 0 then executes the session 0 initialization program (as described above, is WININIT.EXE by default). Any other instances of SMSS in other sessions will at this point launch the hard-coded Windows Logon Application (.EXE). After this is done, the main thread of SMSS waits forever for WINLOGON to exit. If it ever does, the session associated with it is logged off.

If either CSRSS or WINIT exit unexpectedly, the system crashes with CRITICAL_OBJECT_TERMINATION displayed on the blue screen, because like SMSS, these are also critical processes.

The next stage of initialization involves both WININIT in session 0, and WINLOGON in session 1. WININIT performs the following as part of its initialization:

1. The first window station and initial desktop objects are created. UI0DETECT.EXE is also started here, which handles services displaying a user interface. 2. The user-mode portion of the (SCM) is started – SERVICES.EXE. This then loads all of the automatic start services and device drivers. 3. The Local Security Authority Subsystem (LSASS.EXE) is started.

WINLOGON performs the following as part of its initialization:

1. The system registered credential providers are loaded (for example password and smartcard credential providers). 2. The login user interface is initialized with the credential providers and the process is started (LOGONUI.EXE). This is responsible for displaying the logon user interface. WINLOGON now waits for someone to issue an interactive logon request (for example, a user is wanting to logon). Once this is issued and the logon is validated, WINLOGON then loads the user’s registry hive and links it to HKEY_CURRENT_USER, and then loads the user’s environment variables stored in HKEY_CURRENT_USER\Environment.

A successful logon has now occurred, and WINLOGON now moves into the next stage to complete starting the system. First, it starts the shell program that is stored at the registry location HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit. The default value is USERINIT.EXE, which once executed then performs the following:

1. Runs any user and machine scripts stored in the registry. Machine scripts are executed after user scripts, making them able to override user script settings. 2. Runs the specified shell, or shells specified in either HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell or HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell. The default shell is EXPLORER.EXE which loads the familiar , and desktop.

Once the shell is launched, this is the end of the Windows startup process.

Windows shutdown process The shutdown process is not nearly as complicated as the startup process (thankfully, otherwise this thread might turn into a small book). Shutdown is primarily handled by two components – CSRSS (Client/Server Runtime Subsystem) and WINLOGON (Windows Logon Application).

Initiating shutdown The process of system shutdown in Windows begins when a program calls the Windows ExitWindowsEx function. For example, Windows Explorer (EXPLORER.EXE) calls this function when you choose the shutdown option from the .

Bonus Reading: “Why do you have to click the Start button to shut down?” – Raymond Chen at http://blogs.msdn.com/b/oldnewthing/archive/2003/07/22/54559.aspx

The ExitWindowsEx function is then responsible sending an RPC (Remote Procedure Call) message to CSRSS to tell it to begin the shutdown of the system. After CSRSS receives this message, it then sends another message, this time to WINLOGON.

Because the initial call to ExitWindowsEx was from an ordinary application, and not WINLOGON, WINLOGON will now impersonate the user that is currently logged on (this may or may not be the same user who called ExitWindowsEx the first time) and calls ExitWindowsEx a second time. Once again an RPC message is sent to CSRSS, but this time it notices that the call came from WINLOGON itself, and that the shutdown is indeed authorized – CSRSS now performs the duty of shutting down all the processes running in each user’s interactive session.

User process termination When the time comes for CSRSS to shutting down all of the processes running in interactive user sessions, CSRSS loops through them all in reverse order of their specified shutdown level. This is a special number that programs can set to specify the order in which they should be shutdown in regard to other processes running on the system. A higher number means that the process will be shutdown earlier in the order, while a lower number means that the process will be shutdown later in the order.

Windows GUI applications If a particular process owns what is called a top-level window, CSRSS then sends a WM_QUERYENDSESSION message to that window. This allows a program to prevent a system shutdown if necessary (for example, a word processor program might return FALSE from this message if the user has an unsaved document open). If TRUE is returned from the WM_QUERYENDSESSION message, then CSRSS can proceed with the system shutdown. It does this for every process that owns a top-level window – the first process to return FALSE will prevent the shutdown from continuing.

Assuming that all top-level windows responded with TRUE to the WM_QUERYENDSESSION message, CSRSS then sends a second message to these windows, called WM_ENDSESSION. This requests the thread to exit and allows any cleanup to be done if necessary before the shutdown continues. Programs cannot block shutdown at this point, and as such CSRSS enforces a timeout, which by default is five (5) seconds.

TIP: You can change this value by modifying the registry key HKEY_CURRENT_USER\\Desktop\HungAppTimeout. Its value is specified in milliseconds.

If the thread fails to exit before this timeout, this is the point where you see the “Programs still need to close” message, with the screen dimmed and a list of programs that are preventing the shutdown. This screen can display indefinitely. I’m sure we have all been bitten by this, shutting down the system, walking away, only to return to this screen and a computer that is still powered on!

TIP: You can revert to the previous behavior of Windows and disable this screen by setting the registry key HKEY_CURRENT_USER\Control Panel\Desktop\AutoEndTasks to 1. This will cause Windows to simply terminate the processes that are hanging the shutdown.

This process continues for every top-level window, until all their threads exit, after which CSRSS terminates the processes by calling NtTerminateProcess for each one, which is a native Windows NT kernel routine. Console applications and services If a particular process is a console application (for example, Command Prompt), it does not have a top-level window with which to receive window messages. Instead, console applications register control handlers to receive events. When CSRSS finds one of these console applications during shutdown, it sends the CTRL_LOGOFF_EVENT to it. This is where it gets a little bit confusing. Unlike the WM_QUERYENDSESSION message described above, the console handler returns FALSE to continue the shutdown, and TRUE to prevent the shutdown. When FALSE is returned, CSRSS will then terminate the process. Otherwise (or if the process does not respond within 20 seconds), the same “Programs still need to close” screen will again be shown.

The next stage, after all of the processes in the user’s interactive sessions have been successfully terminated, involves the WININIT component. WININIT calls ExitWindowsEx a third time – this time the execution is inside the context of the system process, which again sends an RPC message to CSRSS living in session 0 on the system.

Session 0 is where the services on the system are started and run from. Once again CSRSS sends a combination of WM_QUERYENDSESSION and WM_ENDSESSION messages to any GUI applications running in session 0 (although GUI applications should not be running here, but this is an issue for another day), and the same flow described above applies. Instead of sending CTRL_LOGOFF_EVENT to console applications in session 0, it sends the CTRL_SHUTDOWN_EVENT.

This is where service shutdown begins, as the Service Control Manager (SCM) running inside SERVICES.EXE is a console application that responds to CTRL_SHUTDOWN_EVENT. When the SCM receives this event, it sends a stop control to all of the services that are running on the system.

Because the shutdown process is now running in session 0, CSRSS does not terminate any of the processes, however it does enforce the same timeouts as described above, if for example a service takes a long time to stop. The timeouts are only so that the system processes can perform their own cleanup and exit themselves before the actual power off occurs. Ultimately, the following critical system processes are still running by the time the system is about to be powered off:

 Session Manager Subsystem (SMSS.EXE)  Windows Start-Up Application (WININIT.EXE)  Service Control Manager (SERVICES.EXE)  Local Security Authority Subsystem (LSASS.EXE)

All of these processes are marked as critical – if they were to be terminated before the system is powered off, the kernel would actually crash the system with the CRITICAL_OBJECT_TERMINATION blue screen code – leading to a not-so clean shutdown! Powering off the system At this point, CSRSS has completed its duties in terminating all user session processes, and finished notifying system processes running in session 0 that the shutdown is occurring. Control now returns with WINLOGON that completes its process by calling the native Windows NT routine NtShutdownSystem.

This routine then calls another native NT routine PoSetSystemPowerState, which then begins the following process:

1. The I/O manager sends shutdown IRPs (I/O request packets) to all registered device drivers. This will allow the driver to perform any operations necessary that their hardware requires before the system is shutdown. 2. The memory manager now writes any modified memory pages with file data back to their respective files on the storage volume. 3. The configuration manager flushes any registry changes back to the respective hive files on the storage volume. 4. The I/O manager notifies all the file system drivers about the shutdown so they can perform their operations, such as flushing data back to their underlying physical storage devices. 5. Lastly, the power manager completes the entire shutdown process by powering off the system, rebooting it, etc.

The process is now complete, ready for you to begin it all over again!