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

Tom>1. Приведи содержание раздела реестра HKEY_CLASSES_ROOT\Interface\Твой интерфейс
Tom>2. Приведи содержание реестра по HKEY_CLASSES_ROOT\CLSID\Твой интерфейс

Tom>
Tom>ЗЫ: Ты случайно не ручками регестрируешь прокси/стаб Это конечно глупое предположение , но...

В общем проблему локализовал и убил. Спасибо всем, кто откликнулся!
Теперь расскажу суть, на тот случай, если кто с таким маразмом сталкнется.

Регистрация proxy/stub dll и интерфейса правильная, никаких ошибок... но...
Как вы знаете, когда midl компилирует proxy/stub dll (REGISTER_PROXY_DLL установлен), он выбирает CLSID для этой dll (СОМ объекта имеется в виду) как первый встретившийся IID интерфейса предоставляемый этой dll:

// rpcproxy.h

#define GET_DLL_CLSID   \
    ( aProxyFileList[0]->pStubVtblList[0] != 0 ? \
    aProxyFileList[0]->pStubVtblList[0]->header.piid : 0)

...

// dlldata.c

DLLDATA_ROUTINES( aProxyFileList, GET_DLL_CLSID )

Так вот этим самым первым интерфейсом был интерфейс (IY), который также помещался в typelib и мог быть создан через мой exe сервер. (Это и был баг, этот интерфейс не должен был попадать в proxy/stub dll) И вот какая ситуация: клиент пытается запросить интерфейс IX (см. выше), СОМ ищет IID этого интерфейса в регистри, находит, смотрит ключ ProxyStubClsid32, находит IID интерфейса IY и дальше, он видит, что этот объект создается с помощью моего сервера (не прокси dll), т.к от объявлен в typelib сервера и сервер регистрирует что он создает этот объект. Поэтому СОМ ни разу не обращался в регистри к ключу CLSID моей proxy/stub dll.
Короче грабли!