October 18, 1999

By Karen Kenworthy


The only program ever finished is one nobody uses.

Registry Pruner

Registry Corrupted. Registry Full. Do these phrases scare you? They should. The Registry contains tens of thousands of entries containing sometimes obscure, but often vital, information. It is Windows' central repository for data about itself and your Windows applications. So naturally, when you see a sign that the Registry is in trouble, you worry.

Your Registry -can- suddenly turn into an unrecognizable pile of random bits. But fortunately, that doesn't happen often (to most people). In fact, most of the messages you see reporting problems with the Registry are incorrect, or at least a little misleading.

For example, some Windows 95 users are accustomed to seeing application setup programs (including those for my Power Tools) display an ominous message about Registry corruption just before the installation procedure finishes. Usually, the Registry is fine. The installation program's attempt to add more information just failed, because of Windows 95's limit of 64KB per Registry "key" (more about that in a moment). The information already stored in the Registry is fine. But one of its keys can't hold any more.

Windows 98 and Windows NT don't limit the amount of information that can be stored in a Registry key. But Windows NT does allow you to limit the total size of your Registry, preventing new information from being added.

Now most Registry information is very important. And without some of that information, programs or Windows may fail to run, or behave erratically. But the accidental loss of other Registry information is more of a nuisance. For example, consider the Registry key "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\SharedDLLs"

It's Good to Share

No, the above mentioned Registry key isn't Microsoft's candidate for the longest word in the English language. It's the full name of the Registry key (SharedDLLs for short) where Windows keeps track of "shared" files -- files used by more than one program or application. When installing a shared file, install programs record its name in SharedDLLs. This tells other install (and uninstall) programs to leave this file alone if they might otherwise have been inclined to remove it.

This scheme works well, most of the time. But some installation programs record files in SharedDLLs that really aren't shared. I've even come across SharedDLLs entries for temporary files created during the installation process that disappeared long ago. Some uninstall programs remove shared files (when removing the last application that relies on them), but carelessly forget to remove the corresponding SharedDLLs entry.

As a result, the SharedDLLs key can contain many "orphaned" entries, entries that point to files no longer on your hard disk. Obviously, these files aren't being shared. Since they don’t exist, they can't be used be even one program, let alone two or more. But their information clutters the SharedDLLs Registry key, sometimes ballooning its size over the Windows 95 Registry key limit. Under other versions of Windows, these orphans confuse otherwise perfectly good install and uninstall programs; causing them to leave behind unnecessary files they'd otherwise remove.

The Cure

If you've been taking your blood pressure medicine, you can prune these orphaned SharedDLLs entries manually. But the process isn't recommended for the faint of heart, or the easily frustrated. You must examine each entry in the SharedDLLs Registry key one at a time, comparing the entry's name to the files on your hard disk. If there's no file with the same name as the entry, it's safe to remove the entry from the Registry.

Or, you can try out my new Registry Pruner. This newest Power Tool automatically scans your Registry's SharedDLLs key, and displays all entries it finds. Don't be surprised to see the names of several hundred, or even a thousand, files. Beside each file name is a checkbox. If the file is missing, the box is checked.

To remove the orphaned SharedDLLs entries, just click the Pruner's "Remove selected entries" button. In a flash, the entries are gone. And for safety's sake, a record of all removed Registry entries is stored in a file named SharedDLLs.REG, in your Windows directly. To restore the entries the Pruner removed, just double-click this file.

I'll have more to say about the Registry Pruner soon. But if you'd like to give it a try today, download your free copy from https://www.karenware.com/karen/ptpruner. As always, programmers and other curious folk (now there's a double entendre!) can also download the program's free Visual Basic source code.


I love reading the e-mail messages many of you are kind enough to send. I wish I had time to write a full reply to every one of them. But with hundreds of letters arriving each week, the best I can do is read everyone, and personally reply to a few.

In last week's mailbag was a nice message from James R. Choffo. In response to last week's newsletter (https://www.karenware.com/newsletters/1999/1999-10-11.asp), he points out that "If a time server is already set up on your network, you may also add a one- line command file to your startup folder:

NET TIME \\servername /SET /YES > C:\SYNC_TIME.log

He's exactly right. And if your network timeserver gets its time from one of the accurate public timeservers, and the client's are rebooted often, your whole network will be on time. Thanks Jim!

Joe Barnett wrote "Just checking: Your mail has an attachment, but there is no mention of it in the letter. Is this valid, or did something get added? With all the virus stuff going around these days, I am leery of an attachment that has no explanation of its source".

And well you should be! In this case, the attachment is just a 3- to 4-line ad, inserted at the end of my newsletter by the company that handles the mailing process. The ad contained some HTML markup codes, to make it prettier. But since my newsletter is sent as plain text, some email programs assumed the ad was a separate file.

I'll never send files as attachments to this newsletter. So if you ever see a file attached, it can safely be ignored. We're also looking at other ways to distribute the newsletter that may avoid this problem altogether, and help in other ways too. Stay tuned.