Topics: Service Shutdown and Crash Handling. Prior to Windows Vista, there was no facility to provide a clean shutdown for services. If a service did not respond to the shutdown request within 20 seconds the system could hang on shutdown. By default, services had 20 seconds to cleanup and shutdown. Windows Vista introduced a feature that allowed a service to request a pre-shutdown notification. A service can register for pre-shutdown notifications by setting the SERVICE_ACCEPT_PRESHUTDOWN control code. This is useful for services that perform network-related shutdown operations or need to save large amounts of data to disk and may need additional time to shut down cleanly. The Service Control Manager (SCM) will wait indefinitely for services that request the pre-shutdown notification to shut down cleanly. There is one caveat though – the services that requested the pre-shutdown notification must be responsive. If the service stops responding to SCM queries, then they will be forcibly shut down after three minutes. Once all of the services have exited or the 3-minute timeout has expired, the SCM proceeds with services shutdown for the rest of the services.
Service Shutdown Ordering is another new feature to be aware of. Services have always been able to specify their startup dependencies that the SCM honors to start the services. However, prior to Windows Vista, there was no way to specify shutdown dependencies. Services that register for pre-shutdown notifications can also specify their shutdown order by inserting themselves into the list stored in the PreShutDownOrder string value in the HKLM\SYSTEM\CurrentControlSet\Control key. The SCM will shut down the services in this list according to their order. Before shutting down a service, the SCM attempts to shut down the dependent services. Remember that a service must be registered for pre-shutdown notifications in order to use this feature.
Let’s now take a look at Crash Handling. In previous versions of Windows, there was no support for kernel memory dump files until after the Session Manager process (SMSS.EXE) had initialized the paging file (see our post last month on Understanding Crash Dump Files for more details). If a system encountered any critical errors prior to the initialization of the page file, then the bugcheck STOP error would be displayed, but no dump file would be created. Since most device driver initializations occur before SMSS.EXE starts troubleshooting device driver crashes can be problematic. With Windows Server 2008, the page files are initialized earlier in the boot process. The page files are initialized (enabling a memory dump to be captured) after all of the drivers with a startup type of BOOT are initialized, but before the drivers with a startup type of SYSTEM are initialized. In addition, Windows Server 2008 saves dump file data in 64KB blocks as opposed to the 4KB blocks used in previous Windows operating systems. This results in large dump files being created much faster.
That brings us to the end of this post. Tomorrow’s topic – Windows Error Reporting. Until next time …
Microsoft, WS2008, Windows Server 2008, Services, Shutdown, Crash, Troubleshooting, Debugging, Architecture, Knowledgebase