Not able to find classids and interfaces ids in registry.

Question

I am trying to debug some exe in windbg. Now its calling some thirdparty com dll which is exposing DLLGetClassObject function.

DLLGetClassObject signature is

HRESULT __stdcall DllGetClassObject(
  __in   REFCLSID rclsid,
  __in   REFIID riid,
  __out  LPVOID *ppv
);

Looking at stack trace and arguments I can find out the class id and interface id using commands

dt GUID [address]

When I try to search these guids in registry , I am not able to find anything.

Is there something wrong? I should be able to see the com classes and interfaces id in regsitry. Any ideas?

Answer 1

Probably... If you follow the callstack, is DllGetClassObject invoked by any COM runtime function (CoCreateInstance, CoGetClassObject)?

If so, your CLSID should be found under HKEY_CLASSES_ROOT/CLSID. The interfaces aren't necessarily registered.

Note that there's nothing to prevent an app from loading a DLL and calling DllGetClassObject manually, as long as it knows the threading model requirements of the object to be created.

Answer 2

I have another, unrelated, theory -- do you have symbols for the third-party DLL?

If not, the entry in the callstack for a call into said module is usually shown as the offset of the first export in the module + some large offset.

If DllGetClassObject is elected as the "base export" for the module, and the .exe calls a COM method hosted in the module, the callstack will show something like:

  DllGetClassObject + 0x112313
  UseThirdPartyCOMThing + 0x20

where 0x112313 is larger than what you'd expect the code size of DllGetClassObject to be.

So, it could be a red herring -- you might just be seeing a call into the DLL at some offset that isn't matched in your available symbols, and the debugger shows it using whatever information it has available.