Abstract
In this chapter, the author explores tools and techniques for troubleshooting Registry problems. He also discusses the best way to recover the Registry when you encounter problems and concludes with a set of common problems and solutions to use as a starting point for troubleshooting the Registry.
Overview
Because Registry problems are not always easy to spot (e.g., a security permission issue on one key in the Registry can cause seemingly unrelated problems on an application), I begin with a discussion of tools and techniques for monitoring Registry activity — including WinDiff, Reg.exe’s compare option, RegMon, Event Log, and Sysdiff. With the advent of the Security Configuration tools with Group Policy and the ability to centrally distribute Registry security changes to hundreds or thousands of workstations, security issues are likely to become more commonplace as organizations seek to enhance system security at all levels. I review how the Windows Installer logs Registry activity and discuss the best way to recover the Registry when you have problems.
The best defense against Registry problems is to keep a backup of as current a copy of your Registry as is feasible. As I discussed in "Viewing and Manipulating the Registry," the third installment in this series, you have several ways to back up Registry hives on your Windows 2000 system. However, for those cases in which you don’t have a recent backup or need a faster solution, this chapter offers some techniques for identifying and addressing Registry corruption.
Finally, I present some common Registry troubles and the solutions you need to get your system back up and running quickly. In "Registry Scripting," the final installment in this series, I discuss how to combine segments of information that you learned about in the preceding chapters into scripted solutions for use either on your workstation or across an enterprise.
Tools for Monitoring the Registry
Numerous tools exist for determining how an application or system component is affecting your system and, importantly, how it is affecting the Registry. Once you know how the Registry is affected, you can often get closer to pinpointing problems. In this section, I review the most useful tools that I have found and talk about how you can use them to see what’s going on in the Registry. To begin with, I consider some common Resource Kit utilities that can be useful for monitoring Registry activity. Then, I review RegMon — a great freeware tool for monitoring Registry activity in real time. Finally, I evaluate the usefulness of Win2K’s native event logging tool for monitoring Registry activity.
WinDiff
WinDiff is a Resource Kit utility that compares files and directories before and after changes. How is this tool useful for Registry monitoring? You can use WinDiff with Regedt32 or Regedit to compare before and after results from Registry settings. Both Regedt32 and Regedit have ways of dumping the contents of keys or values to text files. In Regedt32, it is done using the Save Subtree As feature. In Regedit, you can use the Export Registry File feature to create a text .reg file. (From the command line, you can also use Regdmp from the Resource Kit, and the Regedit /e option to do basically the same thing as Regedt32 and Regedit.)
The process is pretty straightforward. Create a text file dump of the keys you want to monitor before you make a system change, using one of the methods above. Then make your system change. You may be installing a new application or adding a new service. Any change that affects the Registry (which will be most things!) can be tracked in this way. After you make the change, rerun the dump method on the keys of interest and use WinDiff to compare the difference.
For example, I want to find out what changes are made to HKLM\Software\Microsoft\ during the installation of the Win2K Resource Kit. I could use Regedt32 to perform a Save Subtree As operation on this whole key, then perform the Resource Kit install, then save the subtree again after the install. I use WinDiff’s Compare Files feature to load both the before and after text files and WinDiff shows me what has changed. Figure 1 illustrates just such an operation and some of the differences that WinDiff revealed.
Note that in Figure 1, the !> symbol indicates that a new key or value was found in the second file (the post-Resource Kit snapshot) that wasn’t in the first file. WinDiff also points out when something has changed between the first file and the second (Figure 2).
When you use WinDiff, there are a few things that you should know. First, it is a Resource Kit utility, for which Microsoft offers limited support. Under certain circumstances, it is not the most robust of tools. For example, if you choose to create a save file that is too large (e.g., if you try to dump all of HKEY_CLASSES_ROOT), WinDiff cannot load both the before and after files; it simply hangs.
Tip: How large a save file is too large for WinDiff? I find that two 2 MB files have no problem loading. I have tried loading two 9 MB files, however, and WinDiff essentially hangs. Because the system you work with is one factor in the loading equation, you may have to experiment with your system. For doing small-scale Registry comparisons on a focused set of keys or values, WinDiff is a great way to see everything that has changed.
Reg’s Compare Option
WinDiff is great if you want to compare dumps of two Registry trees. However, if you need to compare keys or values in real time against a running system’s Registry, you should familiarize yourself with the reg utility’s compare option. I first introduced reg in "Viewing and Manipulating the Registry," the third installment in this series. Reg is the Swiss Army knife of Registry tools. The reg compare option replaces the CompReg utility that was available in NT 4.0’s Resource Kit and lets you compare the contents of keys or values on local and remote machines.
As an example of how you can use reg’s compare option to compare two keys on the same machine, I compare the contents of HKEY_CURRENT_USER\Control Panel\Desktop and HKEY_USERSÊ\.Default\Control Panel\Desktop. The command syntax for such a comparison follows:
The /s option tells CompReg to check subkeys and values that exist under each key specified. The /od option instructs reg to show only the differences between the two keys. The output of the above command follows:
As you can see, the command I typed found a number of differences under the desktop key. The greater than and less than signs at the beginning of each line indicate to which key the line belongs. The next piece of data tells you the value name and what type of value it is (e.g., REG_SZ). Finally, the number or text at the end indicates the actual data within the value for each of the compared keys.
Sysdiff
System Difference Packages (Sysdiff) is a Resource Kit utility that lets you quickly take before and after snapshots of your system’s file system and Registry. Using the difference information, Sysdiff builds a binary package that you can use to install the changes made by the snapshot. Sysdiff is typically used to install applications using a snapshot method. However, for our discussion, you can log Sysdiff changes and then view them in readable text form, which lets you view the Registry changes made by a particular application. There are other third-party utilities, such as InCtrl4 (the code for this utility can be found at http://www.zdnet.com/pcmag/pctech/content/18/02/ut1802.001.html), that let you glean this information from a friendlier, GUI-based interface.
Sysdiff can snapshot any changes you make to your system, including installing applications or adding services. However, there are a few caveats when using it. First, if you create a Sysdiff package with the intention of distributing it to other computers, the other computers must have the same installation directory for Win2K system files (e.g., c:\winnt on source and c:\winnt on destination). You need to have a sysdiff.inf file available to Sysdiff when it creates the initial snapshot. The .inf file is what Sysdiff uses to decide what parts of the system to snapshot. You can customize this file to capture only certain Registry subtrees or keys and to exclude the file system altogether. Sysdiff captures Registry changes only within HKLM or HKCU.
As a demonstration of Sysdiff’s capabilities, I change an option in a Win2K workstation’s TCP/IP configuration screen. Specifically, I change the NetBIOS over TCP/IP feature to disabled and see whether Sysdiff catches and packages the change. To start with, we make it easy on ourselves and edit the sysdiff.inf file to exclude capturing snapshots of everything but HKLM\System\CurrentControlSet\Services. The reason I chose this key is that I know that all service definitions for Win2K are stored under this key. Because TCP/IP is just a set of Win2K services, focusing on this key limits the information I have to sift through. If for some reason Sysdiff did not catch any changes in the chosen key, I can always widen my search by including all keys and then perform the snapshot again. Figure 3 shows the relevant sections that I modify to narrow the scope of the snapshot.
The boldfaced lines indicate additions that I made to the default .inf file to exclude Registry keys in which I wasn’t interested. For example, the last line of the file (HKCU,) tells Sysdiff to exclude all of HKEY_CURRENT_USER because I know that the change I want to capture is not there. The following command initiates the snapshot:
sysdiff /snap /log:snap.log prenetbios
where /log:snap.log tells Sysdiff to create a log file of the snapshot and "prenetbios" is the name of the snapshot file. After I make the change to my NetBIOS over TCP/IP option, I then create the difference file. The following command creates the difference file:
where again I create a log file in diff.log. The following two parameters — prenetbios and postnetbios — refer to the snapshot file I create in the first step and the difference file I create now, respectively. Finally, I can dump the difference file to a text file to find out what keys and values changed. The following command dumps the difference file to the text file:
sysdiff /dump postnetbios dumpfile.txt
where I give the difference file the name of the file to be dumped (postnetbios) and the name of the file into which to dump it (dumpfile.txt). The result is shown in Figure 4.
From the header of the dump file, you can also see that this one click of a radio button produced 26 Registry changes that were essentially unrelated to my actual change of NetBIOS options. This illustrates the complexity of the Registry when it comes to monitoring and troubleshooting certain kinds of changes. However, it’s important to note that not all changes result in many Registry values being modified. Network settings are a special case because there are many pieces of software bound to a network adapter that may also need to change when you change a single parameter. This is not always true, and you’ll find more cases where there is a one-to-one relationship between a configuration change and a change in Registry value.
Instaler
The Instaler (no, it is not misspelled, just another Microsoft special!) you find in the Resource Kit is another useful tool for monitoring the changes made during an application installation. This often overlooked utility can be very useful because it lets you monitor all activity around an application installation, including the API calls the setup program uses to modify the Registry. Better yet, the accompanying undoinst.exe utility lets you roll back installations completed under Instaler. As an example of how Instaler works, I use it to install the Terminal Server (TS) client program. From the command line, I call the setup program for the TS client and tell the Instaler to turn on all debugging options, as follows:
The setup program for the TS client runs. Meanwhile, as the Instaler runs, in the command shell you see all the file and Registry activity. When the setup program is finished, you find two files in the same directory in which the setup executable was located — AEC.log and AEC.iml. The .log file is a text file log of all activity that the setup program created during install. The .iml file is a special binary file that Undoinst uses when you want to uninstall the application. At the end of the log file, the successful and unsuccessful Registry and file operations are recorded.
You probably notice a lot of unsuccessful Registry operations in a given installation. This does not necessarily mean that something failed. An application setup may try to read from parts of the Registry for which the current user does not have permissions, or it may try to change Registry values that don’t exist.
The real value in using the Instaler utility is that you can easily see what an application is doing at an API level during installation and, if need be, you can roll back the installation, at least in a rudimentary way. I don’t recommend using this utility for installing and rolling back large and complex applications, such as Microsoft Office. For that kind of task, you should use the Windows Installer technology described later in this chapter.
RegMon
Once you spend some time using RegMon, you may find it to be the most useful Registry troubleshooting tool ever. This freeware utility is from Systems Internals (www.Sysinternals.com). The tool lets you spy on Registry activity that a given process creates. RegMon comprises an executable (regmon.exe) and a kernel-mode filter driver (regsys.sys) that installs by default when you first launch RegMon.
You can use RegMon to figure out what goes on in your Registry behind the scenes. But most importantly, because it tracks Registry I/O operations, RegMon reports on the status of those operations. This information comes in handy when you look for Registry problems. For example, RegMon tells you whether a particular Registry key or value is not found by a given process. You can also use it to find Registry security problems. If a process does not have sufficient rights to a particular Registry key, RegMon reports an "Access Denied" status. Figure 5 shows an example of RegMon’s output.
As you can see in this screen shot, you can monitor activities as you mouse-click through the Start Menu. First, you notice that the Process column displays the process responsible for the Registry I/O — in this case, Explorer.exe, along with the process ID (1400) for this process. You then see a series of status messages in the Result column indicating keys or values that were either found (Success) or not found (Not Found). This may or may not indicate a problem. Sometimes, when a process enumerates a key or values, it looks for all possible subkeys, because if they are there it can implement some additional functionality. If not, it simply means that that feature has not been implemented — but it may not be a problem.
Generally, if you watch the Request column, you see a process go through a series of operations that are predictable. First, it issues an OpenKey request to create a "handle" on a given key. Then it may issue either a QueryKey to determine what values are available under the just opened key or a QueryValue to get the data contained in a value under the open key. The Path column indicates where in the Registry the process is currently working. The Other column indicates the data returned by the request. In most cases, it is either a hexadecimal number indicating a handle ID or the actual data of the value in question. Another request a process may make is to "EnumerateKey," which indicates that the process wants to query all subkeys underneath the currently open key. Once the query operations are complete, the process may choose to do something to the key or value. For example, it may request the creation of a new key (CreateKey) or it may create a new or change an existing value (in both cases, SetValue).
Critical Challenges of ESI & Email Retention Are you storing too much electronic information? Get expert legal advice and better understanding of what you are required to do as an IT professional.
Rev Up Your IT Know-How with Our Recharged Magazine! The improved Windows IT Pro provides trusted IT content with an enhanced new look and functionality! Get comprehensive coverage of industry topics, expert advice, and real-world solutions—PLUS access to over 10,000 articles online. Order today!
Get It All with Windows IT Pro VIP Stock your IT toolbox with every solution ever printed in Windows IT Pro and SQL Server Magazine plus bonus Web-exclusive content on hot topics. Subscribe to receive the VIP CD and a subscription to your choice of Windows IT Pro or SQL Server Magazine!
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Windows IT Pro
Register
