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

Tom>Не а. Только при анмаршалинге и то не факт — надо проверять. При маршалинге по моему даже прокся не поднимается.

Анмаршалинг тоже не помогает.
Поясню еще немного ситуацию, может кто-то в этом увидит что то не ладное.

Есть COM-объект SessionManager. Ему в метод Logon приходит интерфейс IClientCallback. Здесь создается объект Session, в который засовывается замаршаленный интерфейс IClientCallback (ну раз замаршалили, то соответственно суем IStream).У Session есть метод get_ClientCallback([out] IClientCallback** ppiClientCallback), в котором интерфейс размаршаливается и возвращается выходным параметром.
Есть еще один класс CGarbageCollector, который крутится в своем потоке. Он берет Session, у него вызывает метод get_ClientCallback, а тот возвращает S_OK в любом случае, даже если клиент уже отвалился (это про то, о чем писал Tom).

Я еще пробывал такой вариант.
CGarbageCollector запускал еще один поток, в котором вызывался метод интрефейса IClientCallback. Если объект не существует, то все ок...метод возвращал ошибку и сборщик мусора убивал эту сессию. А вот если клиент повисший (преславутый while(1), то созданный поток подвисает. Сборщик мусора ждет окончание выполнения данного потока в течении таймаута, по истечении которого он терминирует этот поток....Казалось бы все ок, НО....когда поток подвисает на вызове, он отедает 3-5 хэнделов (смотрел через TaskManager). При терминировании потока эти хэнделы ест-но не освобождаются, что не допустимо....

Щас буду пробывать вариант Vi2....
Какие еще будут мысли на этот счет?!?!