tags:

views:

276

answers:

3

I have inherited two complicated COM objects. One was derived from the other and (allegedly) the GUIDs, etc., were all changed so that they should not interfere. They do interfere and so far our debugging has not identified the culprit -- we've done registry compares and source code diffs and looked through the SCCS checkins. Obviously we're missing something, but they're big and complicated enough that I'm not surprised.

Is there a tool which can help, perhaps by checking COM objects for good behavior or detecting clashes between two COM objects or analyzing the registry?

+4  A: 

If you have Visual Studio, you could use regcap to pull out the registry entries and then just collect a list of GUIDs via a script. You could also use OLEView (also from Visual Studio) to do this.

There are also other free tools that can do this:
MMM (Make My Manifest) can be suckered into doing this if you have VB.
Heat or Tallow from Wix 3.0 and 2.0, respectively, can also do something like this.

The output format will be a little different in each case but it will be enough to collect the relevant information into a text file.

Brian
+1 for regcap. Very useful when dealing with COM registration
Orion Edwards
regcap was a very good tip
mlo
+1  A: 

Not sure about automated tools, but the first thing I'd do in this situation is run up RegEdt32.exe and look at HKEY_CLASSES_ROOT - at that point you should be able to see every COM object, and that will give you the ClassID. You can then look those CLSIDs up in HKEY_CLASSES_ROOT/CLSID to find the typelibrary GUIDs. It's a manual approach but it should tell you all you need to know about clashes.

Another thought, maybe they're both sharing a common based DLL. You can check this using Dependency Walker

MrTelly
+1  A: 

Some tools for work :
Deviare COM Spy Console

Debugging tools box list

WinAPIOverride32 - Can hook COM OLE and ActiveX interfaces

lsalamon