.NET calls to COM using STA/MTA
Michael Hennessy
to call a VB 6.0 COM object from within a MSMQ app when
the threading model is set to STA.
For other COM calls invoked from my C# components, I have
set the threading model = STA, and have been able to run
multiple threads without a problem. This multithreading is
part a windows messaging service which spins up multiple
threads to process messages in a different MSMQ Queues.
Recently, I needed to add another COM call, but ran into a
situation where the COM DLL just hung when it was invoked
using the STA mode. Once I stopped the windows service, I
got a message saying "Object reference not set to an
instance of an object"
however, if I changed the threading = MTA, it worked!
I then created a simple test winForms application to spin
up threads and call the object with threading =STA, and
this worked without a problem.
So there seems to be something very specific that's
failing when attempting to get the object from the MSMQ
and then invoking the COM call in STA mode.
I need/want to run my threading in STA mode to get the
multi-threading (concurrent) usage of my other components,
but this one simply won't run in this mode..
Any ideas?
Willy Denoyette [MVP]
Inline ****
Willy.
"Michael Hennessy" <mhen...@brassring.com> wrote in message news:028d01c238e5$99f4f8f0$9be62ecf@tkmsftngxa03...
> I am running into a very perculiar problem when attempting
> to call a VB 6.0 COM object from within a MSMQ app when
> the threading model is set to STA.
>
> For other COM calls invoked from my C# components, I have
> set the threading model = STA, and have been able to run
> multiple threads without a problem. This multithreading is
> part a windows messaging service which spins up multiple
> threads to process messages in a different MSMQ Queues.
>
> Recently, I needed to add another COM call, but ran into a
> situation where the COM DLL just hung when it was invoked
> using the STA mode. Once I stopped the windows service, I
> got a message saying "Object reference not set to an
> instance of an object"
**** Make sure you catch all exceptions in your service code, don't let any slip through, or the CLR will popup a dialog box, which
remains invisible if your service doesn't run as localsystem with "interact with desktop" set. Also don't call Debug.Assert when you
don't have "interact with the desktop" set.
Michael Hennessy
Here's the strange scenario I am running into.
1. I have a Vb 6.0 DLL that I want to use in a multi-
threaded application.
2. I have a messaging service that spins up multiple
threads to process messages within a specific MSMQ. When
the service starts, it spins up say 5 threads to monitor
the queue and receives and processes messages.
In the above scenario, I put a object in the queue, which
is then received by the messaging service which fires off
the call to the VB 6.0 component. If I have my threading
model for the threads = MTA, it works ok. However, if I
have the model = STA, it "hangs" at the point where it
calls the COM object.
To debug this, I created a simple winforms app that spins
up threads and calls the COM object. In this app, with the
thread set to STA OR MTA, it works fine!
This has led me to believe there is something in how the
object calls the COM object from within the Queue???
I then converted my VB 6.0DLL to a VB.NET component, which
converted fine.
I then tried using the VB.NET component in my simple
winforms application.
When I tried calling it with the thread set to MTA, it
worked.however it was much slower.
However, when I set the thread = STA, and called the
VB.NET component.it worked the FIRST time, but when I
tried calling it again, it failed and "hung" the
application..and popped up my debugger with the following
error message:
"An unhandled exception of
type 'System.Runtime.InteropServices.InvalidComObjectExcept
ion' occurred in xeng27.dll
Additional information: COM object that has been separated
from its underlying RCW can not be used."
The behavior is obviously the same as I was seeing in the
failure in invoking the original VB 6.0DLL from within
MSMQ.
Does this make any sense??
Any ideas what's going on?
>.
>
Willy Denoyette [MVP]
Inline ****
Willy.
"Michael Hennessy" <mhen...@brassring.com> wrote in message news:49fc01c23965$8c91f110$35ef2ecf@TKMSFTNGXA11...
****
It looks like you did create a COM object on an STA thread and use the reference from another thread after the creators thread has
exited. This is not allowed to do, because when the creator thread exits, the STA is destroyed, resulting in "COM object that has
been separated from its underlying RCW can not be used."
But there is something I'm missing here, your component is a VB.NET component now, why are you setting MTA/STA apartmentstates while
VB.NET components are Apartment agnostic?
Michael Hennessy
from your comment:
>>It looks like you did create a COM object on an STA >>thread and use
the reference from another thread after >>the creators thread has
>>exited. This is not allowed to do, because when the >>creator thread
exits, the STA is destroyed, resulting >>in "COM object that has
>>been separated from its underlying RCW can not be used."
>>But there is something I'm missing here, your component >>is a VB.NET
component now, why are you setting MTA/STA >>apartmentstates while
>>VB.NET components are Apartment agnostic?
The reason is, for my messaging service, I have another COM DLL that
needs the aparmentstate=STA for it to invoke that component
concurrently. For this other COM object, if we didn't set the threading
or set it =MTA, it called the object in a serial fashion. So setting it
to STA worked there.
So, here's another object, running on the same messaging service that
has spun up those STA threads....which is why I was testing with it this
way.
Also, It looks like right now, I couldn't use the VB.NET component as it
takes about 22 seconds to run as opposed to the 3 seconds on the VB6 COM
object!!
On my test winapp form, if I remove the apartmentstate all together, the
VB.NET component runs...however, it runs at 22 seconds.
For my messaging service therefore, I need to have some way of calling
this VB component in STA mode.
Also, just curious, when it DOES fail on the VB.NET component, why does
it have that initial COM.Interop error message??? Since it's supposed to
be managed code now, why would it be using Interop?
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!