Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IRunningObjectTable::GetObject returns RPC_E_DISCONNECTED

12 views
Skip to first unread message

Alexander Lamaison

unread,
Dec 13, 2009, 9:12:24 PM12/13/09
to
I'm using the RunningObjectTable to store an object (in a seperate in-proc
server) that is used by several threads. The first thread creates and
registers the object in the ROT. When the other threads try to retrieve
the object via GetObject() it returns RPC_E_DISCONNECTED.

Does anyone have any idea why this might happen?

Many thanks.
Alex Lamaison

Vista 32-bit/MSVC8

Igor Tandetnik

unread,
Dec 13, 2009, 9:41:17 PM12/13/09
to
Alexander Lamaison wrote:
> I'm using the RunningObjectTable to store an object (in a seperate in-proc
> server) that is used by several threads. The first thread creates and
> registers the object in the ROT. When the other threads try to retrieve
> the object via GetObject() it returns RPC_E_DISCONNECTED.

My guess is, you start a thread, create the object on it, then allow that thread to terminate. This kills the apartment, and forces COM to release the object prematurely. Any proxies to it would then return RPC_E_DISCONNECTED on any call.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

Alexander Lamaison

unread,
Dec 14, 2009, 4:31:40 AM12/14/09
to
On Sun, 13 Dec 2009 21:41:17 -0500, Igor Tandetnik wrote:

> Alexander Lamaison wrote:
>> I'm using the RunningObjectTable to store an object (in a seperate in-proc
>> server) that is used by several threads. The first thread creates and
>> registers the object in the ROT. When the other threads try to retrieve
>> the object via GetObject() it returns RPC_E_DISCONNECTED.
>
> My guess is, you start a thread, create the object on it, then allow that thread to terminate. This kills the apartment, and forces COM to release the object prematurely. Any proxies to it would then return RPC_E_DISCONNECTED on any call.

Ouch. Yes, that's exactly what I'm doing.

Is there a way to make an object survive the destruction of the thread that
created it? At the moment this is just a mockup for my unit tests but the
real situation I'm trying to model is where Windows Explorer calls my code
from several seperate threads and I cache an object in the ROT between
calls (this was failing).

Many thanks.
Alex Lamaison

Igor Tandetnik

unread,
Dec 14, 2009, 8:06:14 AM12/14/09
to
Alexander Lamaison wrote:
> Is there a way to make an object survive the destruction of the thread that
> created it?

Thread: yes; apartment: no. For STA apartments, the two are one and the same, so the thread that created the object must remain alive (and run a message pump). For MTA apartments, threads may come and go, but at least one thread must be running in the MTA apartment at all times to keep it alive.

> At the moment this is just a mockup for my unit tests but the
> real situation I'm trying to model is where Windows Explorer calls my code
> from several seperate threads and I cache an object in the ROT between
> calls (this was failing).

See if SHLoadInProc helps. You may also want to ask in microsoft.public.platformsdk.shell.

Alexander Lamaison

unread,
Dec 14, 2009, 1:27:40 PM12/14/09
to
On Mon, 14 Dec 2009 08:06:14 -0500, Igor Tandetnik wrote:

> Alexander Lamaison wrote:
>
>> At the moment this is just a mockup for my unit tests but the
>> real situation I'm trying to model is where Windows Explorer calls my code
>> from several seperate threads and I cache an object in the ROT between
>> calls (this was failing).
>
> See if SHLoadInProc helps.

Unfortunately this function is disabled in Vista which, coincidentally, is
the first version of Windows that my code broke on.

> You may also want to ask in microsoft.public.platformsdk.shell.

Will do. Thanks Igor :)

0 new messages