Printable View
Just a thought, I notice that my PC takes quite a long time from clicking on the start>shut down, to the appearance of the drop down box of;
restart, shut down, log off, hibernate.
Prior to that it's whizzing along between apps and opening them.
Is it just me being a pernickety old man again?
docusk 'Night from Sunkissed Reading England.
The more processes that are running, the slower shutdown will be.
Open Task Manager > Processes and sort by CPU. Initiate shutdown and watch Task Manager to see what jumps up to the top.
http://www.johntp.com/2006/02/14/spe...s-xp-shutdown/
Try these tweaks and it might shutdown quicker. I use these on all my machines and anyone I work on.
My first reply just disappeared. It's fine (of course) and I do thank you for the help.
docusk
From my glossary (copyright protected)
This will explain the complex Windows shutdown phase
Windows Shutdown
When Windows is instructed to shutdown, Winlogon calls the ExitWindowsEx function; ExitWindowsEx sends a message to Csrss (Client/Server Run-Time Subsystem) - the Window subsystem process - to invoke Csrss’s shutdown routine.
Csrss in turn impersonates the caller and sends the Windows message to a hidden window owned by Winlogon, telling it to perform a system shutdown. Winlogon then impersonates the currently logged on user. Again, Csrss is sent a message to perform the shutdown.
Csrss, knowing that the message is from Winlogon, cycles (loops) through all the active processes in the logon session of the interactive user in reverse order of the shutdown level. A process can specify a shutdown level, which indicates to the system when it wants to exit with respect to other processes. Valid shutdown levels are in the range 0 through to 1023, and the default level is 640. For every system process that owns a top-level window, e.g., Task Manager (1), Explorer (2) etc, csrss sends the WM_QUERYENDSESSION message to each thread(s) in the process that has a Windows message loop. If the threads returns TRUE, the system shutdown can proceed. One exception is for the Service Control Manager (SCM: HKU\.Default\Control Panel\Desktop\WaitToKillAppTimeout - default is 20 seconds)). Csrss then sends the WM_ENDSESSION Windows message to the thread to request it to exit. Csrss waits (default is 5 seconds and is set at HKCU\Control Panel\Desktop\HangAppTimeout) for the thread to exit. If the thread does not exit by the timeout, Csrss displays the hung-program dialog box. (The hung-program dialog box can be disabled by changing the registry value HKCU\Control Panel\Desktop\AutoEndTasks to 1). This dialog box indicates that a program is not shutting down in a timely fashion and gives the user a choice of either killing the process or aborting the shutdown. There is no timeout on this dialog box, which means that a shutdown request could wait indefinitely at this point unless disabled with the registry value HKCU\Control Panel\Desktop\AutoEndTasks to 1.
If the thread does exit before the timeout, Csrss continues sending the WM_QUERYENDSESSION/WM_ENDSESSION message pairs to the other threads in the process that own windows. Once all of the threads that own windows in the process have exited, Csrss terminates the process and goes on to the next process in the interactive session.
If Csrss finds a console application, it invokes the console control handler by sending the CTRL_LOGOFF_EVENT event. Only service processes receive the CTRL_SHUTDOWN_EVENT shutdown message. If the handler returns FALSE, Csrss kills the process. If the handler returns TRUE or does not respond (default being 20 seconds), defined by:
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, performs, and sends the WM_QUERYENDSESSION/WM_ENDSESSION message pair to graphical user interface (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 using the RegistryServicesProcess function. 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 function ScShutdownAllServices will cycle through its services database searching for services requesting shutdown notifications and sends each one a shutdown command. For each service (a callable routine in the operating system, a device driver, or a server process. Services specifically are processes started by the SCM (although the registry defines Windows device drivers as services also)) 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, either the SCM waits 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 (the WaitToKillServiceTimeout time expires), Csrss moves on, continuing the shutdown process. Therefore, services that fail to shut down in a timely fashion are left running, along with SCM. In fact, while the system shuts down, many processes are running, e.g., Smss, Winlogon and Lsass.
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 (IRPs) to device drivers. It coordinates these power events when several devices send a request to be turned off it determines the best way of doing this. 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 collection 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 (allows devices to communicate with user-mode subsystems. It translates user-mode read and write commands in read or write IRPs, which it passes to device drivers. It accepts file system I/O requests and translates them into device specific calls, and can incorporate low-level device drivers that directly manipulate hardware to either read input or write output. It also includes a Cache Manager to improve disk performance by caching read requests and write to the disk in the background) sends shutdown I/O packets to all device drivers that have requested a shutdown notification. This gives device driver’s 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 file system drivers that the system is shutting down.
Note: The Windows startup phases have significantly changed for Windows Vista.
See: Windows Services, Windows Processes & Thread.
)-|
:p