Статья:
Перехват методов COM интерфейсов

Автор(ы): Ivan Andreyev
Дата: 25.09.2004
В статье продолжается обсуждение темы перехвата вызовов методов COM-интерфейсов. Рассматривается использование API-функций, позволяющих упростить эту задачу.

Авторы:
Ivan Andreyev

Аннотация:
В статье продолжается обсуждение темы перехвата вызовов методов COM-интерфейсов. Рассматривается использование API-функций, позволяющих упростить эту задачу.

Автор в примере забыл вызвать ICallFrame::Free. Иначе происходит утечка памяти.

Следует отметить так же что функция CoGetInterceptorFromTypeInfo намного "хитрее" чем кажеться. Хитрость заключаеться в подсчёте ссылок. Дело в том, что если мы делаем QI от результата работы этой функции то фактически мы получаем указатель на другой обьект, со своим счётчиком ссылок, но время жизни этого обьекта зависит от исходного. Сооветственно после того, как мы удалили последнюю ссылку на указатель, полученный от CoGetInterceptorFromTypeInfo все указатели, полученные по QI становяться невалидными. Данное поведение проявилось при использовании агрегации. Без агрегации — не проверял.

Так же найдена проблемма при вызове ICallFrame::Free с параметром CALLFRAME_FREE_TOP... Этот флаг нужен для освобождения памяти, которая выделяеться для скажем out параметров. Скажем [out] IUnknown** pVal. При указании В ICallFrame::Free флага CALLFRAME_FREE_TOP... портиться память, если его не указывать — мемори лик. Воркэраунд в вызове ICallFrame::FreeParam. Почему то если освобождать параметры по одному, а не целиком, то всё работает как и должно...

Здравствуйте, Tom, Вы писали:

Tom>Так же найдена проблемма при вызове ICallFrame::Free с параметром CALLFRAME_FREE_TOP... Этот флаг нужен для освобождения памяти, которая выделяеться для скажем out параметров. Скажем [out] IUnknown** pVal. При указании В ICallFrame::Free флага CALLFRAME_FREE_TOP... портиться память, если его не указывать — мемори лик. Воркэраунд в вызове ICallFrame::FreeParam. Почему то если освобождать параметры по одному, а не целиком, то всё работает как и должно...

Наврал. ICallFrame::FreeParam тоже проблеммы не решает. В общем пока использовать корректно out указатели на интерфейсы — пока невозможно

Из статьи:

HRESULT CoGetInterceptor(
  REFIID iidIntercepted, // IID перехватываемого интерфейса
  IUnknown * punkOuter,  // IUnknown для агрегации
  REFIID iid,            // IID интерфейса, запрашиваемого у перехватчика
  void ** ppv            // указатель на интерфейс перехватчика
);

Перехватчики COM+ используют информацию из библиотеки типов, чтобы определить сигнатуру метода и количество/типы параметров, а также выполнить маршалинг. Поэтому, если быть более точным, в качестве первого параметра (iidInterceptor) годятся не произвольные интерфейсы, а только те из них, которые совместимы с oleautomation и описаны в библиотеке типов.

У меня есть REFIID. Как мне узнать подходит ли он на роль первого параметра?

K> У меня есть REFIID. Как мне узнать подходит ли он на роль первого параметра?
CoGetInterceptor возвращает не S_OK. Как узнать почему?

Здравствуйте, Keith, Вы писали:

K>> У меня есть REFIID. Как мне узнать подходит ли он на роль первого параметра?

на роль первого параметра подходят интерфейсы, информация о которых есть в typelib. Чтобы проверить это, нужно в реестре в разделе HKCR\Interfaces найти ключ с именем IID интерфейса и убедиться, что есть подключ typelib, который указывает на существующую библиотеку типов (ее нужно искать в разделе HKCR\TypeLib

K> CoGetInterceptor возвращает не S_OK. Как узнать почему?
наиболее вероятная причина — интерфейс не описан в библиотеке типов. Какой код HRESULT ?

I>на роль первого параметра подходят интерфейсы, информация о которых есть в typelib. Чтобы проверить это, нужно в реестре в разделе HKCR\Interfaces найти ключ с именем IID интерфейса и убедиться, что есть подключ typelib, который указывает на существующую библиотеку типов (ее нужно искать в разделе HKCR\TypeLib
Большое спасибо!

K>> CoGetInterceptor возвращает не S_OK. Как узнать почему?
I>наиболее вероятная причина — интерфейс не описан в библиотеке типов. Какой код HRESULT ?
В HEX'е: "80070002". А где вы смотрите чему соответсвует HRESULT?

Здравствуйте, Keith, Вы писали:

K>>> CoGetInterceptor возвращает не S_OK. Как узнать почему?
I>>наиболее вероятная причина — интерфейс не описан в библиотеке типов. Какой код HRESULT ?
K>В HEX'е: "80070002". А где вы смотрите чему соответсвует HRESULT?

здесь:
http://blogs.msdn.com/ericlippert/archive/2003/10/22/53267.aspx

утилитка hrplus здесь:
http://www.winwonk.com/utils/HRPlus.zip

I>здесь:
I>http://blogs.msdn.com/ericlippert/archive/2003/10/22/53267.aspx

I>утилитка hrplus здесь:
I>http://www.winwonk.com/utils/HRPlus.zip

Зачем так сложно то. В студии добавляешь hr в watch, а потом там же в watch
добавляешь запятую и "hr".
Типа такЖ hr, hr и студия сама будет показывать описание ошибки. Вместо первого hr
может быть любая переменная.

Здравствуйте, Tom, Вы писали:

I>>утилитка hrplus здесь:
I>>http://www.winwonk.com/utils/HRPlus.zip

Tom>Зачем так сложно то. В студии добавляешь hr в watch, а потом там же в watch
Tom>добавляешь запятую и "hr".
Tom>Типа такЖ hr, hr и студия сама будет показывать описание ошибки. Вместо первого hr
Tom>может быть любая переменная.

это работает только для очень небольшого количества HRESULT'ов, утилитка hrplus AFAIK знает о гораздо большем количестве кодов ошибок

Здравствуйте, Ivan Andreyev

Подскажите, а есть ли какая-либо утилита, с помощью которой я смог бы "приатачиться" к приложению и посмотреть какие именно вызовы СОМ методов из данной TLB оно делает?

Евгений.

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Подскажите, а есть ли какая-либо утилита, с помощью которой я смог бы "приатачиться" к приложению и посмотреть какие именно вызовы СОМ методов из данной TLB оно делает?

есть com spy (он давно не обновлялся)
http://staff.develop.com/jasonw/comspy/default.htm