Before a thread can call into a COM object it has to define its apartment by declaring whether it will enter a single-threaded apartment (STA) or a multi-threaded apartment (MTA). STA client threads call CoInitialize(NULL) or CoInitializeEx(0, COINIT_APARTMENTTHREADED) to enter an STA apartment and MTA threads call CoInitializeEx(0, COINIT_MULTITHREADED) to enter an MTA.
When calling a COM component, it is important to ensure that the threading models of the component and the client are compatible. For instance VB6 components insist on using the STA threading model. With an STA component, a message queue is associated with a hidden window and requests are queued and a single thread in STA apartment processes the messages synchronously of the queue. This ensures that access to the component is synchronised. However, if the client uses an MTA threading model to instantiate this STA component, not only a thread switch between the MTA and the STA thread needs to occur but also an apartment marshalling is required which can be an expensive process. Therefore it is recommended to use compatible threading models to ensure that apartment threaded component instance is created in the client's apartment.
Similarly, in the .NET managed world, you have the option of allowing the calling thread in the managed space declare its apartment affinity. For example, it is possible to associate a thread in .NET to the single-threaded apartment. This is usually the recommended approach when calling legacy VB6 COM.
PingBack from http://msdnrss.thecoderblogs.com/2007/08/05/net-thread-apartment-and-com-interop/
I am implementing a .NET windows service which uses a vb6 com dll. I create an STA thread in my service which calls a .NET dll which uses the vb6 com dll. Everything works fine until the vb6 com dll is initialized. At this point the service hangs. However, when I stop the windows service through "computer management" the service stops but then the .NET dll finishes to completion (utlizing the vb6 components)??? Any Ideas to how to fix this, the desired behavior is to let the .NET dll finish to completion without stopping the service.
can this info might help me to solve my problem - see here http://www.developmentnow.com/g/60_2005_2_0_0_254762/0x8004E005-and-0x800040