Starting with version 3.7, Regmon for Windows NT includes an option under its Events menu entitled "Log Boot" that enables you to capture Registry activity from very early in a system boot. Registry activity captured in this mode is logged to a file, and the logging continues in the background until the next system boot, or until the Regmon user interface is started. Thus, you can capture Registry activity through a system's entire boot-to-boot life cycle, including startup, login, logout, and shutdown, or just through its boot sequence. You can use Registry activity logs generated by Regmon's boot-logging capability to learn how the system uses the Registry during what are normally black-out periods for system monitors, and to troubleshoot system, service or driver Registry configuration problems that would otherwise be difficult or impossible to track down.
To use Regmon's boot logging feature simply select the "Log Boot" menu entry. Regmon will indicate that starting the next time the system boots Registry activity will be monitored and recorded to a log file named REGMON.LOG in your system root directory. When you make this selection Regmon configures itself as the very first driver to initialize in the system, enabling it to capture the Registry startup activity of all other device drivers and services, including critical boot drivers such as SCSI miniport drivers and boot file system drivers.
Regmon stops recording to the log file when you start the Regmon GUI, and it will only log a single boot. Logging is therefore also stopped when the system shuts down, unless you have re-enabled boot-time logging for the subsequent boot. The format of the log file is the same tab-delineated text as a standard Regmon output file that can be viewed with any editor.
Before you use the boot-logging feature you should ensure that there is ample free space on your system drive. Capturing Registry activity from startup to shutdown on an NT 4.0 system will generate a log file with 90,000-120,000 records (7-10 MB in size), whereas an identically configured NT 5.0 system (Beta 2) will generate 140,000-160,000 records (15-25 MB's of log data). If Regmon fills the disk while writing to the log it will truncate the log file and leave a message in it indicating that the disk did not have enough free space. Regmon aborts logging and cleans up the log in such cases so that lack of disk space will not prevent a successful boot.
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.
The modifications necessary for Regmon to be able to log a boot process were relatively few. First the Regmon GUI always copies the driver to the \system32\drivers directory when starting so that it will be there in the case that it should be configured as a boot driver. If the "Log Boot" menu option is enabled when the GUI is exited, Regmon modifies the Registry key of its driver, HKLM\System\CurrentControlSet\Services\Regmon, so that the driver will be the first device driver to initialize. It ensures that its first by setting its Start value to SERVICE_BOOT_START, its Group to "System Bus Extender", and its Tag to 1. If "Log Boot" is not enabled when the GUI is exited Regmon deletes the driver image from the system32\drivers directory before terminating.
When the system reboots and the Regmon driver initializes, it reads its own Start type value from the Registry. If the Start type is SERVICE_BOOT_START Regmon knows that it should record Registry activity during the boot, but it sets the Start type to SERVICE_MANUAL_START so that if the system reboots it won't start again.
Regmon cannot simply open a file when it initializes during a boot and begin logging to it because file I/O is not permitted until after all boot drivers have initialized. Unfortunately, Regmon can't know when this will happen. So, it simply collects monitored Registry data into buffers, and periodically tries to open its log file. It uses the path "\SystemRoot\Regmon.log" as the file's name, because SystemRoot is an Object Manager symbolic link that is defined to point at the