Which CLSIDs are re-registered at boot and how to prevent them?

[GrofLuigi]

Hi,

This has been mentioned somewhere, but I can't find it. What I'm looking for is a list of CLSIDs/Interfaces that Windows (mostly IE libraries) register in every session (on boot?) and a way to selectively prevent some of them from being re-registered. Even by patching/reshacking if needed.

GL

[CharlotteTheHarlot]

########### METHOD-1 ... SnapShots

- Export your complete registry ... SAVE0.reg

- Immediately RESTART. At desktop, do nothing except ...

- Export your complete registry ... SAVE1.reg

- Windiff SAVE0.reg SAVE1.reg

F8 skips to next difference, F7 is previous. Confine your scrutiny to keys containing CLSIDs, ignore the others.

Red background color denotes statements in the BEFORE file, and yellow background color for the AFTER.

Re-registered keys sometimes 'move', they will change location from the BEFORE to the AFTER. More often, just the 'case' of a few letters will shift, usually to upper, Red and Yellow colors accordingly.

NOTE: this isn't a guaranteed method because sometimes a key in a safe cozy location can be re-registered without changing its case or its position in the surrounding keys. So they won't show up in a snapshot. But this method will definitely show all changes. The only way to get those others would be realtime capture ...

########### METHOD-2 ... RealTime

There is a way to capture the changes in realtime (only XP and higher) using RegMon from System Internals (not available officially anymore, but it is around). It has a setting that inserts itself into the startup sequence. The log file will be rather large and weeding out the false positives will be aggravating! Here is the pertinent section of the REGMON.HLP file ...

Monitoring Boot-Time Registry Access (Windows NT/2K only)

To use Regmon's boot logging feature simply select the "Log Boot" menu entry. Regmon will indicate that starting the next time the system boots Registry activity will be monitored and recorded to a log file named REGMON.LOG in your system root directory. When you make this selection Regmon configures itself as the very first driver to initialize in the system, enabling it to capture the Registry startup activity of all other device drivers and services, including critical boot drivers such as SCSI miniport drivers and boot file system drivers.

Regmon stops recording to the log file when you start the Regmon GUI, and it will only log a single boot. Logging is therefore also stopped when the system shuts down, unless you have re-enabled boot-time logging for the subsequent boot. The format of the log file is the same tab-delineated text as a standard Regmon output file that can be viewed with any editor.

Before you use the boot-logging feature you should ensure that there is ample free space on your system drive. Capturing Registry activity from startup to shutdown on an NT 4.0 system will generate a log file with 90,000-120,000 records (7-10 MB in size), whereas an identically configured NT 5.0 system (Beta 2) will generate 140,000-160,000 records (15-25 MB's of log data). If Regmon fills the disk while writing to the log it will truncate the log file and leave a message in it indicating that the disk did not have enough free space. Regmon aborts logging and cleans up the log in such cases so that lack of disk space will not prevent a successful boot.

If you do not have RegMon, you have some searching ahead of you unfortunately. Both RegMon and FileMon were superceded by the uber utility: ProcMon (link to SystemInternals). It also does boot logging, but it requires more configuring since it does double duty! Disable file access logging for sure. Here is the pertinent section of the PROCMON.CHM file ...

Boot Logging

Process Monitor can log activity from a point very early in the boot process during the initialization of boot-start device drivers. Configure Process Monitor to log the next boot by selecting Enable Boot Logging from the Options menu. Process Monitor's driver will log activity at the next boot into a file in the %Windir% directory and will continue logging through the shutdown or until you run Process Monitor again. Thus, if you don't run Process Monitor during a boot session you will capture a trace of the entire boot to shutdown cycle.

On Windows Vista and higher, Process Monitor supports thread profiling capture in boot logging. When you enable boot logging on supported operating systems, Process Monitor will present a dialog that asks whether boot logging should include thread profiling, and if so, the rate of the profiling. Note that thread profiling will significantly grow the size of a boot log.

When you run Process Monitor it looks to see if a previous boot log has been generated, and if so, asks you where you want to place the processed boot log output file. Process Monitor displays the trace after it has finished translating it. To see activity from the System process, which is the only process early in a boot, select Enable Advanced Output from the Options menu.

If you configure boot logging and the system crashes early in the boot you can deactivate boot logging by choosing the Last Known Good option from the Windows boot menu (which you access by pressing F8 during the boot).

Note: network events, which are based on ETW (Event Tracing for Windows), are not available in boot logs.

[GrofLuigi]

Thank you for your reply. I am quite familiar with both methods and use them very often. Actually, I never ever start any exe that was not used previously on my system without monitoring changes (method 1). Using Total Uninstall and/or Regshot Unicode. And often I examine what the new program wants with method 2. Many interesting things to be learned there.

But this situation is different. If I were to use method 1, I should first deregister everything (probably just delete regkeys CLSID, Interface, Typelib in HKCR). And then Windows won't work on reboot. I have seen it a long time ago when a registry cleaner deleted HKCR/Interface. Windows was unusable and only reinstall helped.

Also, method 2 wouldn't help if they weren't deregistered because I think Windows (sometimes?) doesn't bother writing the values if they are present, so I couldn't be sure that, if I isolate writes, I will have complete list.

What I want to achieve is to have partial or selective registration of COM objects, and in many places I succeed. For example, I delete few functions of urlmon.dll (roughly four out of ten) which I think are non-essential for my needs, but provide some speedup because urlmon is invoked in EVERY explorer operation. At the same time, if I deregister it completely, many things don't work (IE for sure). Also everything related to Search Assistant, but I don't touch other functions of that dll (I forgot which one was it, but it was pretty essential, like browseui.dll or shell.dll). There is no way I could get away with full deregistration of that.

The above two examples are harmless because they are not re-registered on every boot, but some others are. I don't have many examples, but one of them is this (regsvr32 actxprxy.dll). Of course it's a placebo, but I've tracked the changes (Method 1 ) and after a reboot the changes are reverted by shdocvw.dll which also contains list of other potential re-registration components. I'm just asking for a way to make them humanly readable and/or prevent them. Also, I'm asking if there are other dlls and which are they.

This example is actually easy to keep under control permanently with permissions, but there are some functions that I don't want to reappear, and I can't place permissions on non-existing objects.

I'm sure this issue has been discussed before, but it might have been a long time ago, and I don't think a definitive solution was given, or I'd be using it right now. But my memory might be failing me, or I have decided against (patching?) because it would be reverted by hotfixes, but now they are not so frequent for XP, so that reason could be crossed off.

GL

Edited February 27, 2011 by GrofLuigi

[allen2]

A way to prevent them from registering at each boot and or prevent programs to read those clsid reg entries, would be to modify registry rights (deny access in this case).

[GrofLuigi]

A way to prevent them from registering at each boot and or prevent programs to read those clsid reg entries, would be to modify registry rights (deny access in this case).

I'm pretty sure if I denied SYSTEM account access to the whole CLSID branch, bad things would happen. Besides, it overrides. Example: Winlogon doesn't respect permissions to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Credentials

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceCurrent

and overwrites them whatever they are. But that's another question.

GL

[allen2]

I don't think the clsid are read with the system account when you open a session but i might be wrong.

[CharlotteTheHarlot]

I am not surprised that MSIE is involved. Personally I always install the latest MSIE on WinXP, but I never really use it. I was demonstrating this for a client who always uses it, by clicking on Start | All Programs | Windows Update, that is the closest I get to MSIE, I told him. If there is a URL to visit, I dump it into another browser. The only real reason I maintain MSIE on a computer is for Windows Update, and also for those wayward apps that manually start MSIE by themselves (probably hardcoded internally or finding some registry key that points to Iexplore.exe). Those few odd times that MSIE is running is the only reason I allow its updates. I do hope you solve this though. I personally cannot help on this exact topic, except to comment generically and wax philosophical (as always :-) ...

If I were on a mission to say, catalog the entire XP boot process on a specific machine (*), well it would certainly take a long time. To do it thoroughly I would let ProcMon log the boot to desktop (**) with its settings set wide open (i.e., capture everything). I would parse this file in multiple passes, maybe first enumerating all file access. Later I would enumerate all registering files to get a complete list and their chronology. Then I would Windiff snapshot the manual un-registering and re-registering of each of these files in isolation, building a 'total' chronological REG script as I went along. At some point I would consider the job done, having this large REG script that constitutes all the interfaces that are effected at bootup. I would also have a corresponding file that collected all the [-HKEY un-registered actions as well.

(*) Specific Machine is an important concept here because no two are alike (auto-update guaranteed this fact). Even two of identical hardware where you scrupulously installed the exact same Win setup and hardware drivers. Any single change to a minor user pref or hardware setting, especially BIOS can cause great differences in the two machines (I found a way to mitigate the BIOS differences by saving the CMOS and pushing it to the other machine, before installing Windows). System Restore and Disk Indexing greatly expand the level of differences once Windows is in play. Add in pseudo-optional complications like .NET, MSIE and Live Essentials, realtime antivirus and malware apps, firewalls, etc, and we get the current situation where a computer is more like a human being - no two are alike. In my experience it means that when porting apps from system to system by collecting the registry paraphenelia it means that I have to grab the bare minimum needed to achieve the goal, all the while making decisions whether a given REG key/value is 'safe' with respect to the myriad of differences from one PC to the next. And then we have some clever programmers who like to insert their secret registry settings hidden in plain sight, buried in Explorer keys or even among System keys. But that's another story!

(**) To the desktop, this means IMHO after all startup activity has completed, the pointer has stopped animating, disk activity is done. The Start Menu is NOT clicked, not even a right-click on the desktop or a systray icon. This means that certain icons/shortcuts need be in place already on the desktop in order to accomplish things without 'disturbing' anything. A shortcut to ProcMon/FileMon/RegMon is vital to be able to turn it off without first going through a menu. Various shortcuts to Regedit need be in place as well, for example a shortcut to export it. The shortcut to stop logging can also be placed in a startup location to automate this somewhat, however this may cause it to miss something that delay loads.

Unrelated to boot logging and the topic at hand, but very important item to note when dealing with CLSID interfaces and registry expertise in general ... I should first say that it probably gets close to touching the clean Forum rules here (mods: I promise I will keep this legal). Certain software licensing or copy protection schemes exploit the vast registry collection of CLSID classes and such by inserting clever dummy keys and values based on existing files on a HDD. At first glance from the layperson they make sense and ignore them. But 'registry cleaners for example cannot determine their validity and usually wipe them out. I am speaking primarily of Asprotect (this why sometimes a program they paid for stops working). Asprotect will find a DirectX or Windows or MsOffice file present on the HDD and construct a group of keys that reference these files all the while encoding its secrets in the naming of these keys and values. The keys themselves are fakes though. So it is possible to uninstall a program and still find references to it afterwords because of fakes constructed by Asprotect. Typically they construct in HKCR: keys under CLSID, Interface, TypeLib and others, sometimes many others. To fully understand this would require some snapshots of installing an app using Asprotect, before and after. To explore this on your own, I believe recent versions of DvdFab fall into this category, a little searching will point out many others.

[GrofLuigi]

@CharlotteTheHarlot: You're preaching to the choir, really. I am that kind of person that does ProcMon boot traces (multiple times) for no apparent reason other than to find out what's hiding inside the box.

I also know about Asprotect and its annoyances.

On the bright side, I found what I was looking for. Where else than on FDV's site (Step 17). Now all that is left for me is to organize myself and get to work.

GL

[CharlotteTheHarlot]

Cool!

And, nice link.

[GrofLuigi]

Everyone is welcome to comment about:

- eventual experiences with this on a live system;

- list of other dlls that contain REGINST, if any;

- recommended program(s) (resource hacker? Is there anything else more reccomendable?)

- how to deal with windows updates later on? (unfortunately, IE cumulative updates are the most frequent produced. My concern is that there will be a time frame when the dlls will be able to re-register themselves).

GL

[fdv]

The DLLs with REGINST's are the system ones mainly.

SHELL32, SHDOCVW, etc as you found.

A random DLL here or there happens. If I'd found any others that were very significant I would have listed them (but then again I don't list any IE ones that I don't install)

As for experiences you might discover some oddities. For example, and I seriously doubt I could ever duplicate this, I once carved out some REGINST's and had a system that could read files on the network but not copy them. The drag and drop did nothing. And I was being careful (or so I thought). So there is a possibility that you might destroy some functionality in Explorer and have to undo what you did. Obviously what I had done was screw to up my Zones.

For updates use 2000, XP, 2003. Forget this auto update nonsense.