Monitoring and Troubleshooting the Registry

Windows IT Pro

- Advertise

Monitoring and Troubleshooting the Registry

Author:	Darren Mar-Elia
Published:	October 2000
Copyright:	2000
Publisher:	Windows IT Library

After creating a new key or adding/changing a value, you may also see a FlushKey request. A FlushKey is issued when the calling process wants to write the new change to the hive file on disk immediately, to ensure that it gets committed. Otherwise, the Registry’s "lazy flusher" function performs this task periodically. FlushKey (Microsoft’s term for the function that performs the flushkey operation) is generally used when a process is programmed to make sure that a system crash doesn’t lose changes that are still in memory. Delete operations are also tracked. Deleting a value results in a DeleteValueKey request and deleting a key results in a DeleteKey request. When a process is finished manipulating a key, you see a CloseKey request.

RegMon has a number of other useful features that make it invaluable for troubleshooting Registry problems. First, you can search the contents of the currently logged entries to find a particular string. Using the filter function, you can include or exclude a specified process from being monitored. This comes in handy when you try to spy on a well-known process and you are not interested in a lot of background "noise." You can also filter on a given path, including or excluding a key in the Registry in which you are not interested. For example, certain virus-checking applications query a specific key in the Registry with annoying regularity. You can use the Path Exclude feature to prevent these operations from being logged. Note that the filter functions support wildcards. If you want to exclude monitoring of all keys underneath HKLM\Software, you could enter a path filter of HKLM\Software\* (Figure 6).

Note that when you’re filtering processes, you need to either include the whole process executable name and process ID (e.g., explorer.exe:1400) or place a wildcard after the process name (e.g., explorer*). The highlight feature within the Regmon Filter dialog box tells Regmon that you wish to highlight a given process or Registry path with a color different from the rest of the display. You can also specify that you wish to log only certain results. Figure 6 shows that you can selectively track reads, writes, successes, and errors. Another handy feature in RegMon is the ability to double-click (or type Ctrl-J) on a given line within the log and have it automatically fire up Regedit and navigate to the exact key or value about which that line is reporting. This "jump" feature comes in handy when you need to look into the Registry quickly to see what is happening on a given key. You can also save the output of a RegMon session to a text file (.rgd extension by default), which can then imported into a spreadsheet for further examination and manipulation.

If you ever wonder what goes on in the early stages of system boot on a Win2K system, RegMon has an interesting feature for you. From the Edit menu, select "Log Boot." This feature sets a flag in the Registry that tells Win2K to load the RegMon kernel-mode driver early in the system boot cycle. At that point RegMon logs all Registry activity happening on the system until the next time you log on to the system and start RegMon interactively. It writes the results of the log to a text file called regmon.log in the %systemroot% directory on your system.

Note: The regmon.log file can end up being very large — on the order of 10 MB to 15 MB, depending upon your system and its configuration. However, it can be useful for "sniffing" the behind-the-scenes Registry activity on your Win2K device.

Now that we have reviewed RegMon’s features and functions, let’s work a simple example of how you can use it to find out what is going on within the Registry. Where is this useful? You may need to create a custom Administrative Template (.adm) file for your Group Policies that enforces a special Registry key change to users or machines. To build the .adm file, you need to know where the Registry change happens for the function you want to control. RegMon is ideal for this. In this example, I want to find out where information related to my TCP/IP settings is kept in the Registry configuration. Specifically, Win2K lets me specify whether I want to enable or disable NetBIOS over TCP/IP or let DHCP decide for me. This option is shown in Figure 7.

Once I reach this dialog box, I could fire up RegMon and choose another radio button, then focus on RegMon and sift through the entries to see what happened. However, in the interests of filtering out noise, I first filter on the process I want to track.

How do I find out what process to filter on? The easiest way I know is to fire up RegMon and simulate the steps you would take to get to the dialog box for the task that you want to track. You can then go back to RegMon and see which process owns the task. In some cases, it is fairly evident. If you are working in Microsoft Word, the winword.exe is likely to be the process owner. However, in our example of TCP/IP settings, it may not be so evident.

With NT 4.0, I might guess that a process such as rundll32.exe owned this change because that has been true in the past. However, in Win2K, many configuration changes are spawned directly from Explorer.exe — the shell. This is the case with TCP/IP settings. Therefore, I filter on Explorer.exe, start RegMon, and make my changes to disable NetBIOS over TCP/IP. After I make the change and commit it, I stop logging in RegMon. The next challenge is finding my change.

In this particular case, it is tricky because Explorer.exe makes a lot of Registry calls to perform this function. However, because I am changing a value in the Registry somewhere, I know that I am performing a SetValue operation — and I can search on SetValue to help find the right key.

In this case, again Win2K throws a curve because it rewrites many of the keys related to network bindings whenever I make any change to my network configurations. As a result, I find many SetValue operations. I need to take another tack. I know that the change I am making adjusts some NetBIOS properties, so I search on the string "NetBIOS." Again, I find many entries, but not all are SetValue requests. I search through each until I find an interesting candidate. Because it is likely that the change I made flips a bit to 1 or 0 in a value, I use that information to narrow my search. When I find the correct value, I can confirm it by rerunning RegMon, this time filtered on the path I found, and change the value back to its original data to see whether RegMon again records the SetValue. Figure 8 shows the results of my initial logging with the affected value highlighted.

If I double-click on this entry in the log, RegMon jumps me to Regedit and the exact spot where this value is located (Figure 9). Of course, not all Registry changes require this much work to track down. But now that you see how to find the hard ones, you can find the easier ones quickly!

Tip: RegMon is a great way to find out whether you have Registry permission problems. If you monitor an operation that does not have sufficient privileges to view or change the key or value it needs to change, RegMon reports an "Access Denied" message in the Results column on that Registry call.

Tip: RegMon can help monitor Registry activities, especially if you start RegMon using the AT scheduler. If you issue the command at HH:MM /interactive "regmon.exe," where HH:MM is the time of day to start in hours and minutes, RegMon starts up under the Scheduler service account. The advantage of this is that it keeps running through the logoff/logon sequence. You can easily monitor Registry activity during logoff, and then log on again to find RegMon still running. This is advantageous if you think something is going on in the Registry during this time. You can, of course, set a filter to watch a specific process or path before you log off — to limit the amount of information you capture during this busy time of Registry activity.There is now also a version of Regmon that lets you monitor Registry activity on a remote machine. This piece of software is available at www.winternals.com — the commercial side of the SysInternals site. As such, it is not freeware, but it does give you the ability to discover what a particular remote machine’s Registry is doing.

Event Log
The Win2K Event Log ends up being a poor place to track Registry activity, largely because most applications do not use the event logs to record Registry changes. Even if the event logs do record activity, level of verbosity (amount of detail) is not like that of RegMon. However, you can use the event logs to your advantage to monitor changes to the Registry.

You can enable the Registry auditing feature that is part of Registry security. In "How the Registry is Architected," the first installment in this series, I talked about how to enable auditing on the Registry. Now let’s look at what happens when you do. To illustrate this, I present something simple, such as audit changes that I make to my desktop wallpaper. This information is kept in the key HKCU\Control Panel\Desktop. The easiest way to enable Registry auditing is to start Regedt32 and select the Security menu, where you find the Auditing option. I add my user name — administrator — to the list of users to audit. Then I select a number of operations to audit for success and failure, including CreateValue, SetValue, Create Subkey, and Enumerate Subkey (Figure 10).

After enabling auditing, I change my Wallpaper to a different bitmap. This operation produces 110 events within the Win2K Event-Security Log. Figure 11 provides an example of one such event, showing that I opened the key Desktop under my User Profile hive loaded in HKU.

As you can see, the event log reports only information related to accessing a key or value. It doesn’t tell you what the change was or which value changed. But if you need to monitor who is doing what to which key, auditing serves your needs.

Warning: Just this little bit of auditing created 110 events. It is easy to fill up your Security log by auditing Registry access. In this case, I monitored access by the administrator account only. If I had included everyone on my network, the result would be constant logging.

Another way you can use the event log is to record the activities of the Windows Installer when you install an application. The Installer service writes a certain number of events to the Application log in a default Win2K installation. However, you can adjust the verbosity of this reporting by using some Registry keys — specifically, if you create a new key, called Diagnostics, under

HKLM\Software\Microsoft\Windows NT\CurrentVersion

This key contains values to enable logging on a number of Win2K features, including IntelliMirror and Group Policy application. In this case, we want to enable Software Installation logging.

From either Regedit or Regedt32, add a new value of type REG_DWORD under the Diagnostics key you created above. The value name is RunDiagnosticLoggingAppDeploy. Set the value to 1 for verbose logging of Software Installation. Figure 12 shows an install based on a deployed application; the event registers a warning about a request for a feature.

You can use this verbose logging feature to aid in troubleshooting application installations that affect the Registry on your Win2K systems. If you enable Group Policy Logging (add a value called RunDiagnosticLoggingGroupPolicy under the Diagnostics key and set it to 1), you can verbosely log application of GPOs as your machine starts up or users log on.

Monitoring Application Installation Under the Windows Installer
In "The Registry and the Active Directory," the second installment in this series, I discussed the Windows Installer service and MSI packages. In general, it is the Installer service’s job to install assigned or published applications, roll back application installations that fail, and fault-in components when some part of an application breaks.

However, if you want to find out what a particular MSI package is doing to your system, there are few options. In "The Registry and the Active Directory," I talked about the Installer service’s command-line options. MSIexec can be run from the command line in an interactive mode and can be used with the right switches to log detailed information about what an MSI installation package is doing to your system. To initiate a Windows Installer installation from the command line, you simply call msiexec with the name of the MSI package to be installed. You can use any number of options to modify the standard installation. For purposes of our discussion here, I’ll just work with the logging function. The following msiexec command shows how you can use the logging function:

msiexec /I app.msi /L c:\logs\app.log

This command tells the MSIexec program to install the application package app.msi and to log the results to c:\log\app.log. Figure 13 shows a snippet from logging an installation of Microsoft’s FrontPage application. The logging feature includes a number of suboptions that you can specify to narrow what you log (Table 1).

Note that using the /l*v option logs absolutely everything that the Installer and the MSI package is doing to your system. For example, on an average-sized application (e.g., FrontPage) this option generated a 1 MB log file. However, if you want to discover everything that an MSI package is doing to your system, this is the option for you. Interactive logging is a good way to find out what an MSI package is doing to your system and user.

Registry Recovery: Last Known Good and Safe Mode
In previous versions of Windows NT, "Last Known Good" configurations offered a way to recover your system at boot time if you had made a configuration change that prevented your system from loading. What Last Known Good really was — and still is in Win2K — is a copy of the Registry key HKLM\System\CurrentControlSet. In Win2K, in addition to the Last Known Good, we have the concept of Safe Mode booting, similar to what is available in the Win95/98 product. In this section, I present the CurrentControlSet in Win2K and explain how it works. I then describe Safe Mode and what some of the different Safe Mode options do for you.

In Win2K, access to Last Known Good is available twice during the boot process. First, if you press F8 when presented with the Win2K boot loader menu, you are taken to the Safe Mode Menu. One of the options there is to access the Last Known Good configuration. If you don’t press F8, then Win2K continues to load and at the next screen prompts you to press the space bar to select Last Known Good or load an alternate Hardware Profile.

Page: 1, 2, 3

ADS BY GOOGLE