RegistryWalker is a tool designed to aid Windows users search and modify the Windows registry. The regedit.exe tool distributed with the Windows operating system allows you to inspect and modify the registry, but it is feature-poor and tedious to use for tasks involving multiple keys. RegistryWalker provides a powerful search capability based on regular expressions. It allows you to search and make multiple modifications at one time. The inspiration for RegistryWalker was to help developers recover from registry disasters that are common to COM develpment. Examples are provided that show how to use the tool to make such recovery easier.
RegistryWalker's searching operation is relatively straightforward. You provide it with a registry key where the walk will begin. RegistryWalker looks for any values and sub-keys at that node. It displays the values and the sub-keys. It then repeats the process on each sub-key in order.
This kind of traversal of a tree-like structure is called a depth-first traversal. RegistryWalker can be configured to match only keys, values, and data that match patterns. These patterns are called "regular expressions". There are several different types of regular expression syntax used in various applications. RegistryWalker uses the Python syntax.
You define a search by creating commands from the main application window. When you choose to add a new command you will see a dialog similar to the one pictured below. The command should be named in a way that you will be able to refer to it later. You can tell the command where the search begins by providing the name of a registry key in the Start Key entry. The 3 entries that follow it, Sub-key Filter, Value Filter, and Data Filter allow you to provide patterns that must match the sub-key name, value name, or data contents respectively. If the pattern does not match, the sub-key or value is not displayed. Furthermore, if a sub-key is not matched, RegistryWalker will not walk any of its child sub-keys. If no pattern is specified, RegistryWalker will match all keys, values, or data.
Once the command has been added, it will appear in RegistryWalker's command list. When you press the Run button on the main application window, all the commands in the list are processed in order, and the output is displayed in the main output window.
Not only does RegistryWalker let you search the registry, it allows you to modify it. Please note that you can destroy important operating system and application settings if you are not sure what you are doing when deleting registry keys! RegistryWalker is a tool that can help you modify the registry more quickly, but ultimately, you need to understand just what it is you are deleting!
RegistryWalker has a Dry-Run option that allows you to see what keys and values would be affected without actually modifying the registry. It is always recommended that you attempt a dry-run before modifying the registry to make sure you are not accidently deleting something unexpected!
Deleting a registry key, a value, or data is accomplished by checking the corresponding action check boxes on the command dialog. As RegistryWalker performs its walk, it will keep track of the matched keys and values. When the walk is complete, RegistryWalker will delete the matched keys, values, or data you specified. Deleting a registry key will remove that key, all its values and data, and any sub-keys that might have been contained in it. Deleting a value removes the value and any associated data from its containing key. Deleting data leaves the value intact, but the data stored under that value will be blanked out.
Pruning a registry key is similar to deleting a key. The difference is that deleting occurs at the point where a sub-key matches a pattern. Pruning occurs at a specified depth on the entire branch if there is a match at any point on the branch. For example, consider the following key:
If we were to perform a delete action with a sub-key pattern of "grue", then the grue sub-key would be removed, leaving
If we were to perform a prune action on the same pattern, with a depth of 4, the Frotz sub-key and all of its descendants would be removed leaving
Anyone who has developed COM or ActiveX components for Windows ought to be familiar with terms like DLL Hell and Binary Compatability. COM components and ActiveX DLLs are registered with the operating system in order to be usable on your computer by different applications. And the place where the registration information goes is the Windows registry. Specifically, there are 2 places in the Registry this information goes.
The first key COM information is stored under is the root key, HKEY_CLASSES_ROOT or HKCR for short. If your COM class has a programatic identifier of "Whizbang.Frobnitz;", there will be a sub-key under HKCR that has that name. This key is how the COM libraries look up information about your class when you try to create it with its programatic identifier (progID). Among other things, the actual class ID, a very long and confusing GUID is stored here. There is a reverse lookup as well, and the class ID is stored as a sub-key under HKCR\Classes.
Problems sometimes arise during development or installation when multiple versions of a component get registered. If 2 different versions of a component get registered, the COM libraries can get very confused about which DLL file on your computer contains the code for the class you want to create. The registry information may even point to a DLL that no longer exists!
Un-registering all the DLLs and re-rgistering only the new version can solve the problem, but sometimes the old DLL has been erased or overwritten. This typically meant a grueling session of using regedit.exe and hunting for all the classes registered in the DLL and erasing them by hand.
RegistryWalker can help with this situation. This task is best accomplished by creating 2 commands. The first command will remove the reverse lookups. The second command will remove the progID lookups.
The first command should search for data values that match the progID of the class(es) in question. The start key should be HKCR\Classes. Finally, the prune depth should be set to a depth of 3. This will cause all the reverse lookups for the classes to be pruned.
The second command should search HKCR for sub-keys that match the name of the progIDs and delete them. This will remove all the progID lookups.