Windows ShutDown Process:
The Windows shutdown process is not complicated as Windows Booting Process. The shutdown is primarily handled by two components – CSRSS (Client/Server Runtime Subsystem) and WINLOGON (Windows Logon Application).
Initiating shutdown
The Windows shutdown process 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 Start Menu. The ExitWindowsEx function is then responsible for 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\Control Panel\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 has 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, 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, service takes a long time to stop. The timeouts are only so that the system processes can perform their own cleanup and exit 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 which 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:
- 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.
- The memory manager now writes any modified memory pages with file data back to their respective files on the storage volume.
- The configuration manager flushes any registry changes back to the respective hive files on the storage volume.
- 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.
- Lastly, the power manager completes the entire shutdown process by powering off the system, rebooting it, etc.
Read Also: Fix: Computer not shutting down completely
