Monitoring Registry Activity During the Boot Process

The first 5,000 to 10,000 records in a Regmon log file will be the result of boot and system driver initialization. An interesting observation that can be made by comparing a NT 4.0 log to an NT 5.0 log is that its very clear that Microsoft has been thinking about adding plug-and-play capability to NT for several years. The Registry activity for non-plug-and-play device drivers (which are classified as legacy) is virtually identical on the two operating systems. The differences are subtle, but both record the initialization of legacy devices under the Registry key HKLM\System\CurrentControlSet\Enum\Root. NT 5’s plug-and-play documentation indicates that this key records the recognition of legacy devices by the system legacy device enumerator: Root.

The major difference you’ll see between NT 4 and NT 5’s device initialization activity is the presence in NT 5 of devices that are not legacy, and that have been identified by bus enumerators. For example, on a sample IDE system the key that the ATAPI device information was placed under by NT 4.0’s legacy enumerator is HKLM\System\CurrentControlSet\Enum\Root\LEGACY_ATAPI. On the same system running NT 5 the ATAPI’s enumeration key is HKLM\System\CurrentControlSet\Enum\PCIIDE\IDEChannel\1&0, indicating that the PCI IDE bus enumerator recognized the IDE drives.

There are a number of Interesting things to look for in Regmon log files. One is evidence of drivers checking for their configuration parameters. For instance, search for NtfsDisable8dot3NameCreation and you’ll have found NTFS checking its compitability flags, all of which are documented in the Windows NT Resource Kit. In some cases you might uncover undocumented parameters, especially for third-party drivers and services.

After you pass the point in the log where boot and system driver initialization is complete you’ll begin to see records created by the smss.exe process, which is called the Session Manager. Session Manager is the first user-mode process launched during a boot. You’ll see it immediately check to see if there are any rename operations it should perform before the system is up and running by looking at the value HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations. Next you’ll see it determine what DOS device mappings it should create (e.g. COM1, LPT1), what environment variables are defined, what DLL’s it “knows about” (standard DLLs in the system32 directory), and which protected subsystems it should start (e.g. OS/2, POSIX).

Session Manager typically launches Chkdsk (autocheck.exe), which is specified in the Session Manager’s BootExecute value along with direction to run other boot-time native applications. After Autocheck finishes Session Manager starts Winlogon and the Win32 subsystem (CSRSS.EXE). Both of these generate interleaved Registry accesses as they start up concurrently. Winlogon can be seen querying the .Default key’s display settings, including colors and mouse settings under HKU\.Default\Control Panel. The .Default key’s contents are user preferences that are active when no one is logged in, and Winlogon uses them for the screen on which it displays the logon dialog box.

Winlogon also starts the Local Security Authority Subsystem (LSASS), which it’s directed to by the Registry value HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\System. Search for “Security Packages” and you’ll see LSASS checking for what security DLLs it should load. Search for HKLM\Security to see how LSASS reads policy, account, group and password information from the SAM and SECURITY Registry hives. To see where Winlogon determines where to load your user profile from as you login search for “Profilelist”.

A particularly interesting part of a log is where the Service Control Manager (services.exe) begins to access the Registry. The Service Control Manager (SCM) is started by Winlogon, and SCM is responsible for starting all auto-start drivers and services. The SCM can be seen querying every key under HKLM\System\CurrentControlSet\Services looking for such drivers and services (they have Start values of 2). After they have all been started, SCM begins creating a new control set and copying the settings under HKLM\System\Clone to the new set. The Clone key (search for “\clone”), which is inaccessible from Registry editors, is a copy of the control set (CurrentControlSet) that was made very early in the boot. Search for the first occurrence of “Select\LastKnownGood” to view the record of the SCM setting the LastKnownGood to point at the copy of the Clone key when it has finished copying it. This is the point when the boot is considered successful – up to that point any boot failures due to a mis-configured control set might be avoided by choosing “last known good” during a reboot. Contrary to some articles on the Registry the “last known good” copy of the Registry only contains the control set, and not the entire Registry – this is confirmed by a Regmon log.

If you have Explorer as your shell you can examine the Registry accesses it performs as it starts up when you log in. The system tray process, systray.exe, also makes an appearance in the logs, as do a number of other support processes, including userinit.exe, the print spooler (spoolss.exe), the RPC subsystem (rpcss.exe – you can see it query RPC interfaces under HKCR\Interface), and any other applications or services that your configuration launches.

A trace that goes through shutdown will show that the last Registry activity performed is by Winlogon, which performs relatively few operations while closing down.

I’ve only provided a tour of the major high-lights you’ll find when you peruse a Regmon log file, but I hope to have provided you enough of a road map to guide your own trek through the Registry tracks made during a system boot.