Не удается найти идентификаторы классов и интерфейсов в реестре - PullRequest
0 голосов
/ 31 августа 2009

Я пытаюсь отладить какой-нибудь exe в windbg. Теперь он вызывает некий сторонний com, который предоставляет функцию DLLGetClassObject.

DLLGetClassObject подпись

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

Глядя на трассировку стека и аргументы, я могу узнать идентификатор класса и идентификатор интерфейса с помощью команд

dt GUID [адрес]

Когда я пытаюсь найти эти руководства в реестре, я ничего не могу найти.

Что-то не так? Я должен быть в состоянии видеть com классы и идентификаторы интерфейсов в regsitry. Есть идеи?

Ответы [ 2 ]

1 голос
/ 06 сентября 2009

У меня есть другая, не связанная теория, у вас есть символы для сторонней DLL?

Если нет, запись в стеке вызовов для вызова в указанный модуль обычно отображается как смещение первого экспорта в модуле + некоторое большое смещение.

Если DllGetClassObject выбран в качестве «базового экспорта» для модуля, а .exe вызывает COM-метод, размещенный в модуле, стэк вызовов покажет что-то вроде:

  DllGetClassObject + 0x112313
  UseThirdPartyCOMThing + 0x20

где 0x112313 больше, чем вы ожидаете, размер кода DllGetClassObject будет.

Итак, это может быть красная сельдь - возможно, вы просто видите вызов в DLL с некоторым смещением, которое не соответствует вашим доступным символам, и отладчик показывает его, используя любую доступную информацию.

1 голос
/ 01 сентября 2009

Возможно ... Если вы следите за стеком вызовов, вызывается ли DllGetClassObject какой-либо функцией времени выполнения COM (CoCreateInstance, CoGetClassObject)?

Если это так, ваш CLSID должен быть найден в HKEY_CLASSES_ROOT / CLSID. Интерфейсы не обязательно зарегистрированы.

Обратите внимание: ничто не мешает приложению загружать DLL и вызывать DllGetClassObject вручную, если оно знает требования к модели потоков для создаваемого объекта.

...