Microsoft Enterprise Platforms Support: Windows Server Core Team
EPS Team Blogs
Product Team Blogs
When troubleshooting boot issue such as disk or file corruption, missing files, and third party drivers, Windows provides three Windows boot-problem recovery options:
This article is focused on the first recovery option: Last Known Good.
In the system’s registry, the system’s configuration settings are stored under HKLM\System\CurrentControlSet\Control along with driver and service configurations stored under HKLM\System\CurrentControlSet\Services. Any change to these locations in the registry can render the system unbootable. If you happen to be in a situation where you are unable to boot into your Windows operating system normally, your system may have encountered a damaging change to the system’s registry prior to its last shutdown or reboot. In order to troubleshoot the issue, you have the opportunity to boot into the Last Known Good option by hitting F8 during the boot process. This will bring you to the Windows Advanced options Menu screen as shown below.
Figure 1 – Windows Advanced Option Menu.
By selecting the Last Known Good Configuration, you can attempt to boot into the last known bootable state of the machine (explained in detail further down in the article). As the information is critical to system startup, the Last Known Good configuration option allows you the ability to revert back to a previous control set labeled as the Last Known Good. The result of choosing LKG is the rolling back of the system’s registry configuration to reflect that of when the system last booted successfully. The system will mark the control set that had been used to boot the machine previously (ControlSet001; value = 1 in example) as failed. This can be seen in the registry under HKLM\System\Select. ControlSet001 (value = 1) is set as the value for Failed, and the value of HKLM\System\Select\Current is changed to the value stored in HKLM\System\Select\LastKnownGood (ControlSet002; value = 2 in example) as shown below. Because the change made to the system causing it to become unbootable is not present in the Services subkey of the LastKnownGood Control Set, the system should boot successfully. Figure 2 shows the registry of a system successfully booted. Figure 3 reflects changes made by booting into the Last Known Good configuration.
Figure 2 - Successful Boot with Current in use and Last Known Good available.
Figure 3- ControlSet001 set to Failed; LKG used for Current and Default
In addition to these changes, the symbolic link HKLM\System\CurrentControlSet is updated to point to the LastKnownGood control set. ControlSet002 becomes the current control set used to boot the system. In this example, a ControlSet003 is created to become the new value for Last Known Good.
In order to have the option to boot to the Last Known Good configuration, there must be a point at which the system knows it is in a “good” state. For XP/Windows Server 2003 and Vista/Windows Server 2008 there are conditions that must be met in order for a Last Known Good configuration to be captured and stored in the registry. Each time these conditions are met, an updated version of the Last Known Good configuration replaces its predecessor. The following provides the requirements for each platform.
In XP/Windows Server 2003, a successful boot is required to occur before Last Known Good is written to. A successful boot consists of a successful logon and the successful startup of all auto-start services. To accomplish this, Winlogon performs its startup steps (creating an initial window station and desktop objects). If a dynamic-link library (DLL) is specified in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL, Winlogon uses that DLL for the graphical identification and authentication (GINA); otherwise it uses the Microsoft default GINA, Msgina (\Windows\System32\Msgina.dll), which displays the standard Windows logon dialogue box. Winlogon then creates the service control manager (SCM) process (\Windows\System32\Services.exe), which loads all the services and device drivers marked for auto-start, and the local security authentication subsystem (Lsass) process (\Windows\System32\Lsass.exe). After launching the SCM, Winlogon waits for the interactive logon notification from the GINA. Winlogon invokes the NotifyBootConfigStatus function when you log on, and NotifyBootConfigStatus sends a message to the SCM. Following the successful start of the auto-start services or the receipt of the message from NotifyBootConfigStatus (whichever occurs last), the SCM calls the system function NtInitializeRegistry to save the current registry startup configuration. If the system has never been booted successfully before, the Last Known Good won’t exist and the system will create a new control set for it. If the Last Known Good tree exists, the system simply updates it with the differences between it and the CurrentControlSet.
In Vista/Windows Server 2008, a successful boot is also required for Last Known Good to be written to with the same requirements: a successful logon and the successful startup of all auto-start services. The differences lie within the Winlogon process.
There are cases where other applications installed on the system may require additional steps to occur prior to Winlogon being defined as successful. For example, SQL Server may not consider a system successfully booted until the SQL Server is able to access and process transactions. Developers may introduce a boot-verification program that supersedes the Winlogon’s definition of a successful logon. In this special case, the key HKLM\System\CurrentControlSet\Control\BootVerficationProgram is created and the call from Winlogon to NotifyBootConfig must be disabled. To do this, HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ReportBootOk must be set to zero. In this scenario, the SCM starts the auto-start services, and then launches the boot verification program. After a successful boot has been verified, the SCM waits for the program’s call to NotifyBootConfigStatus before saving the LKG control set.
Symptoms – Problems that occur after the Windows splash screen displays, the desktop appears, or after you log in fall into this category and can appear as a blue screen crash or a hang, where the entire system is hung or the mouse cursor tracks the mouse, but the system is otherwise unresponsive.
Causes – These problems are frequently a results of a bug in a device driver, but can also be the result of corruption in a non-system registry hive.
Resolution – The first step to attempt to resolve your issue is to boot to the Last Known Good configuration. Because a control set includes the core system configuration and device driver and services registration database, using a control set version that does not reflect the changes or newly installed drivers or services might avoid the source of the problem. More advanced troubleshooting allows you to compare the failed control set to the current control set (formally LKG) using tools like WinDiff found in Support Tools.
Because non-interactive servers might never have an interactive logon, they might not get LastKnownGood updated to reflect the control set used for a successful boot.
You can override the definition of a successful boot by setting HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ReportBootOk to zero, writing a custom boot verification program that calls the NotifyBootConfigStatus Windows API when a boot is successful, and entering the path to the verification program in HKLM\System\CurrentControlSet\Control\BootVerficationProgram.
Last Known Good provides a boot troubleshooting option when disk/file corruption, missing files, and/or third party drivers result in failure to boot Windows normally. By saving the system's configuration settings in the registry from the last time the system completed a successful boot, the Last Known Good Configuration option in the Windows Advanced Options Menu can be selected when the system cannot boot normally. By selecting this option, the system will attempt to boot using the system’s configuration settings stored in the registry for the last known good configuration. If the issue causing the no-boot issue has to do with a change made to the server since the last boot, last known good will revert back to the configuration settings set prior to the change being made.
At this point, there are two options. You boot into LKG and attempt to correct issues to the previous control set or you can save the last known good configuration as the current control. By selecting the last known good configuration, certain changes to the machine occur. Depending on the operating system, certain changes are made. Separate links to Vista/Windows Server 2008 and Windows 7/Windows Server 2008 R2 will be provided below.
Shannon Gowen Support Engineer Microsoft Enterprise Platforms Support
Is there any way I can see when the LKG was created or updated?
A crude method would be to open Regedit and save ControlSet### as a text file:
File > Export > save as type: Text Files (*.txt)
Now open the file and look at the 'Last Write Time' timestamp for 'Key Name: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet###'.
What are the 2 rules for determining if the LKGF was successful?
"... a successful boot is required to occur before Last Known Good is written to. A successful boot consists of a successful logon and the successful startup of all auto-start services."