The information in this article applies to:
SUMMARYA RPC_E_WRONG_THREAD error occurs when a thread calls via an interface pointer which is for a proxy object that does not belong to the thread's apartment. MORE INFORMATION
See the REFERENCES section at the bottom of this article for more
information on the workings of the COM threading models. Briefly, an
interface pointer held by a client thread can be of one of the following
types:
-or- When a proxy object is created, it is associated with the apartment that creates it. If a pointer to a proxy object is somehow passed to a thread which does not belong to the apartment (e.g., via a shared global variable), and if this thread then calls through this pointer, the call returns a RPC_E_WRONG_THREAD error. COM returns this error because the proxy object is invalid for a thread that does not belong to the apartment that created the proxy object. The following is also an error. One apartment holds a direct pointer to the object. It then transfers the pointer to another apartment via a global variable (without marshaling). The second apartment calls through this pointer. This call is indeed in error. However, COM has no way of detecting this unlike the proxy case. The correct way of transferring an interface pointer (either a direct pointer or a proxy pointer) from one apartment to another is via COM's marshaling mechanism. The source apartment can call CoMarshalInterThreadInterfaceInStream() to marshal the interface pointer to a shared (global) stream. The destination apartment can unmarshal this interface pointer by calling CoGetInterfaceAndReleaseStream(). This action creates a proxy that is valid for the destination apartment. Note that COM's proxy objects are "smart" enough to avoid the problem of "proxy chaining." That is, if apartment A marshals an interface pointer to apartment B, and if B marshals the same to C, the proxy object that is created in C is directly connected to the stub in A. Therefore, when C calls through the proxy pointer it is calling A directly and B is not in the picture. COM also prevents the "circular" interface-passing problem. That is, if A marshals to B and B marshals to C, and C then marshals to A, then the resultant pointer in A is a direct pointer, not a proxy pointer. NOTE: The RPC_E_WRONG_THREAD error can occur even when all the COM rules are followed and no interfaces are explicitly passed between apartments without marshaling. This happens when an in-process object aggregates with the system provided Free Threaded Marshaler (FTM) by calling CoCreateFreeThreadMarshaler and also holds pointers to COM proxies. Typically in-process objects that can be marked as Threading Model "Both" use the FTM. When an interface pointer to such an object is marshaled from one apartment to another, a direct pointer to the object is passed (no proxy/stub is created). This is the benefit of using the FTM, however this also results in an RPC_E_WRONG_THREAD error if the object's implementation tries to call through the proxy pointer on a non-original-apartment thread. There is no good workaround to this problem, in general, objects that use the FTM should not themselves be clients of out-of-apartment COM servers. If they need to do this infrequently, then they should pass the call to a forwarding object that does not use the FTM. If they do this frequently, they should just mark themselves "free" or "both" and not use the FTM. When an interface pointer to such an object is marshaled to another apartment, the system creates the proxys/stub code needed as the object no longer aggregates with the FTM. REFERENCESFor additional information, please see the following article in the Microsoft Knowledge Base: Q150777 INFO: Descriptions and Workings of OLE Threading Models Additional query words:
Keywords : kberrmsg kbCOMt kbDCOM kbSDKWin32 kbGrpCom kbDSupport LeTwoArc LeTwoCom LeTwoDCom |
|
Last Reviewed: October 22, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |