Inside NT Utilities

Regmon
Regmon is a Registry monitoring tool with a UI, which Screen 2 shows, that is similar to that of Filemon. When you run Regmon, the tool immediately begins monitoring and logging all Registry activity on your system. As with Filemon, Regmon's output window is divided into different fields. Regmon assigns sequence numbers to access records, and these numbers serve as navigation aids and dropped-record indicators, just as sequence numbers serve in Filemon. Regmon displays the name of each process that performs a Registry access, the full path name of the key or value the process accessed, the result code of the status, and supplemental information specific to the type of access. To save screen space, Regmon relies on the common abbreviations for root keys that Table 1 lists. Regmon includes the same filtering capabilities Filemon includes, letting you zoom in on the behavior of a particular application or on accesses to particular Registry keys or values.

In its Other column, Regmon prints the data values that programs read from and write to the Registry. If a value is a string data type, you'll see the entire string in the Other column; otherwise, you'll see up to 8 bytes of the value, presented as hexadecimal digits.

Because the Registry is the nerve center for NT and applications, Regmon provides an inside look at how NT and applications use configuration parameters. You can start an application while Regmon is watching and see precisely what settings the application obtains from the Registry and where those settings are located. This view is helpful for determining why an application might fail to start or might behave in unexpected ways, and the view can also be useful for discovering undocumented application parameters.

Regmon aids in tracking down problems in production software, and it is a powerful tool for debugging software under development. Component object model (COM) applications rely heavily on Registry COM class-id settings under HKEY_CLASSES_ROOT, in which Regmon can identify problems. Microsoft found Regmon useful as a debugging aid during the development of Word 2000.

As with file system status codes, Registry status codes that appear to be errors might instead be expected results. Status codes you'll commonly see in Regmon traces are NOTFOUND and BUFOVRFLOW. Applications, particularly NT Explorer, often check for the existence of optional configuration settings. If the settings aren't present, attempted accesses will yield an error signaling that the application didn't find the value or key, but such an error doesn't prevent the application from behaving correctly. When an application reads a Registry value, the application often dynamically allocates buffers that are just big enough to hold the value. To determine how large a buffer must be, the application passes a buffer of length zero in its first access of the value. The result of the operation (if the value exists) is an error specifying that the buffer is too small (the buffer has overflowed), and additional information will tell the application how large a buffer must be to hold the value. The application can then allocate a buffer of the necessary size and reattempt the access.

At some point, you might want to edit a value or key you see referenced in Regmon's output. Regmon makes this task easy—simply double-click on the line with the name of the value or key you're interested in. Regmon launches the regedit Registry Editor, opening it to the specific value or key. You can achieve the same result by using the Jump to Regedit toolbar button.

In addition to displaying monitored accesses in realtime in its GUI, Regmon has a mode you can configure to begin logging accesses to a file from early in the system boot. This capability lets you obtain a complete log of all Registry accesses that take place on a system during an entire boot-to-shutdown cycle. Logs that Regmon generates reveal NT and driver misconfiguration problems and undocumented Registry parameters.

Although the similarity between Regmon's and Filemon's interfaces and operations might imply that Regmon relies on a filter driver similar to Filemon's, internally, Regmon's device driver is different from that of Filemon. Regmon has a device driver component, but Regmon's driver uses an unsupported technique I developed to monitor Registry accesses. I call this technique system call hooking. Understanding system call hooking requires some background in NT's system call interface. When an application performs a Registry-related operation, the application indirectly or directly invokes Registry system calls. When an NT application invokes a system call, the application loads a CPU register with the index number of the call, then carries out a special instruction that causes the CPU to switch from user mode to supervisor mode. During the mode change, the CPU transfers control to a function in the NT kernel that reads the system call index and finds the address of the corresponding system call routine by reading the index's entry in a system call array. The kernel then carries out the system call, after which control returns to the application.

Regmon can have its functions run in lieu of the original system call functions simply by inserting pointers to its functions in NT's system call array. After Regmon examines the parameters an application passes to a system call, Regmon invokes the system call it replaced. When control returns to Regmon from the system call, Regmon can examine the return status and return control to the application. Figure 2 demonstrates this process. System call indexes can change between different releases of NT, but the method Regmon uses to determine indexes is version-independent. To learn more about system call hooking, examine Regmon's source code on the Systems Internals Web site.