WCF Service Library: “cannot change thread mode after it is set”
Phillip Williams
Service Library and then expose the data that it returns to other .NET3.0
apps. The WCF Service Library is written in VB but the host and client are
written in C#. The Service library works fine (in instantiating the COM
object) if the calling host is a WPF (Windows Application) but it does not
work if the calling host were a console or a Windows Service.
On the console host, I get a message “cannot change thread mode after it is
set” echoed on the host console window. If I step using the debugger through
the service, I find that it catches a
System.Runtime.InteropServices.COMException at the line: myVar = New
myLib.SomeObject
After searching for similar error messages, I understood that the problem is
related to the threading model of the COM object so I added STAThread on
every method in the service, host and the client applications. But still the
same problem exists for the console and WinService host.
Any ideas?
--
Regards,
Phillip Williams (MCPD Web Developer)
http://mcts-study-practices.com/
http://www.webswapp.com
Phillip Williams
console host.
So to summarize, I have a WCF service library hosted by four different types
of application: WPF, console, Windows Service and IIS. The four endpoints
work fine from any client application when accessing methods that do not
activate the COM object.
If a client application attempts to access a method that activates the COM
object by connecting to the endpoint that is hosted in WPF it works fine.
The problem is when a client app accesses the methods that activate the COM
object at the endpoints that are hosted by console, or IIS or Windows Service
apps.
--
Regards,
Phillip Williams (MCPD Web Developer)
http://mcts-study-practices.com/
http://www.webswapp.com
Steven Cheng[MSFT]
From your description, you're encountering some error when consumning a WCF
service object in non-WPF clients(console, windows service ...), correct?
I've viewed your two messages and currently my understanding is that the
problem only occurs when you call that WCF method(or the object) which will
invoke another COM interoped object, is this the case? If so, I also think
the problem should be concentreated on the COM component. Would you please
provide some further description on that method which call the COM
objects(the RCW wrapper?) , are you directly creating the RCW wrapper
object in WCF method?
Normally, for cases that we need to call a component in STA apartment(and
the current thread context is already set as "MTA"), you can consider
creating a separate thread to invoke the COM objects calling. e.g.
============
protected void YourMethodInMTAContext{
..............
Thread thread = new Thread(delegate() {
//the code that will call the STA COM object
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
thread.Join();
}
=========================
If there is anything else I missed, please feel free to post here.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>> set�€?echoed on the host console window. If I step using the debugger
Phillip Williams
Thank you for your response. It helped me solve the problem of the host
application type. However there are consequent issues.
First, to answer your questions:
1- You are correct in understanding that only when I host the WCF in a WPF
project that the COM object works. (Notice that the client app can be any
type of application: WPF, console, or web app but the host application type
is the deciding factor).
2- You are also correct in understanding that the WCF method calls the COM
object
3- I did not create an RCW; I only used the Type Library Importer
(Tlbimp.exe). After adding the imported COMLib as a reference to my project
I use the “New” keyword to create an instance of the class that I want within
the COM object. That COM object is a black box (I did not write it nor have
much knowledge about its internal design).
I used the Thread approach that you posted; it worked but with some
consequences:
1- I get this error message while the console host application is waiting
for the next client request:
“Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a problem
in 'C:\Documents and Settings\pwilliams\My Documents\Visual Studio
2005\Projects\SolutionName1\ProjectName1\bin\Debug\ConsoleHost.vshost.exe'.
Additional Information: The CLR has been unable to transition from COM
context 0x1a1440 to COM context 0x1a1720 for 60 seconds. The thread that owns
the destination context/apartment is most likely either doing a non pumping
wait or processing a very long running operation without pumping Windows
messages. This situation generally has a negative performance impact and may
even lead to the application becoming non responsive or memory usage
accumulating continually over time. To avoid this problem, all single
threaded apartment (STA) threads should use pumping wait primitives (such as
CoWaitForMultipleHandles) and routinely pump messages during long running
operations.”
2- Is there another way to launch that STA thread such as to return a value?
The "Thread" method approach accepts a ParameterizedThreadStart but how can
I return data from the method that was launched in that thread?
--
Regards,
Phillip Williams (MCPD Web Developer)
http://mcts-study-practices.com/
http://www.webswapp.com
"Steven Cheng[MSFT]" wrote:
> >> On the console host, I get a message “cannot change thread mode after
> it is
> >> set�echoed on the host console window. If I step using the debugger
Steven Cheng[MSFT]
For the two questions you mentioned:
** The error in first message seems related to a VS managed debug
assistant. I've searched some former issue and found an existing record,
you can have a look at the following description and test it to see whether
if fits your case:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
*** Problem Description ***
The CLR has been unable to transition from COM context 0x1a3608 to COM
context
0x1a3778 for 60 seconds. The thread that owns the destination
context/apartment is
most likely either doing a non pumping wait or processing a very long
running
operation without pumping Windows messages. This situation generally has a
negative
performance impact and may even lead to the application becoming non
responsive or
memory usage accumulating continually over time. To avoid this problem, all
single
threaded apartment (STA) threads should use pumping wait primitives (such
as
CoWaitForMultipleHandles) and routinely pump messages during long running
operations.
*** Resolution *** 08/28/2006 tqchen
This sounds like the ContextSwitchDeadlock Managed Debugging Assistant
(MDA). It can be deactivated by going into Debug | Exceptions and then
uncheck ContextSwitchDeadlock underneath Managed Debugging Assistants.
It can also be deactivated via the app.config. But, I wouldn't just
blindly deactivate this MDA without at least knowing why it's
occurring.
<<<<<<<<<<<<<<<<<<<<<<<<<<
For your second question, if you want to get return value, here is one
means I usually use:
Declare a wrapper class (maybe named ThreadWorker), it has some member
variables that will be used or share data during a thread's execution and
end. And it also contains the member function which is the thread proc.
e.g.
public class ThreadWorker
{
public string Data;
//... other data
public void DoWork()
{
you can update any of the class members here.
.........
}
}
And whenever you want to start a new thread and do some work. YOu can first
create an instance of "ThreadWorker" and use its member function as
threadProc function. Then, after thread finished execution, you can get any
updated data from the class's member variable. How do you think?
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>From: =?Utf-8?B?UGhpbGxpcCBXaWxsaWFtcw==?= <WEBS...@newsgroups.nospam>
>Subject: =?Utf-8?Q?RE:_RE:_WCF_Service_Library:_=E2=80=9Cca?=
> =?Utf-8?Q?nnot_change_thread_mode_after_it?=
> =?Utf-8?Q?_i?=
>Date: Fri, 5 Oct 2007 14:47:02 -0700
>
>Hi Steve,
>
>Thank you for your response. It helped me solve the problem of the host
>application type. However there are consequent issues.
>
>First, to answer your questions:
>
>1- You are correct in understanding that only when I host the WCF in a WPF
>project that the COM object works. (Notice that the client app can be
any
>type of application: WPF, console, or web app but the host application
type
>is the deciding factor).
>
>2- You are also correct in understanding that the WCF method calls the COM
>object
>
>3- I did not create an RCW; I only used the Type Library Importer
>(Tlbimp.exe). After adding the imported COMLib as a reference to my
project
>I use the “New�€?keyword to create an instance of the class that I want
>operations.�€?
Phillip Williams
for my scenario.
I have not run again into the Managed Debugging Assistant error; I must have
accidently done something that avoided that error.
--
Regards,
"Steven Cheng[MSFT]" wrote:
> ..........
> >I use the “New�keyword to create an instance of the class that I want
> within
> >the COM object. That COM object is a black box (I did not write it nor
> have
> >much knowledge about its internal design).
> >
> >I used the Thread approach that you posted; it worked but with some
> >consequences:
> >
> >1- I get this error message while the console host application is waiting
> >for the next client request:
> >
> > “Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a
> problem
> >in 'C:\Documents and Settings\pwilliams\My Documents\Visual Studio
> >2005\Projects\SolutionName1\ProjectName1\bin\Debug\ConsoleHost.vshost.exe'.
>
> >Additional Information: The CLR has been unable to transition from COM
> >context 0x1a1440 to COM context 0x1a1720 for 60 seconds. The thread that
> owns
> >the destination context/apartment is most likely either doing a non
> pumping
> >wait or processing a very long running operation without pumping Windows
> >messages. This situation generally has a negative performance impact and
> may
> >even lead to the application becoming non responsive or memory usage
> >accumulating continually over time. To avoid this problem, all single
> >threaded apartment (STA) threads should use pumping wait primitives (such
> as
> >CoWaitForMultipleHandles) and routinely pump messages during long running
> >operations.�
> >> >> On the console host, I get a message “cannot change thread mode
> after
> >> it is
> >> >> setâ�echoed on the host console window. If I step using the
Steven Cheng[MSFT]
I'm glad to be of assistance. Yes, that manaed debug error should be
something related to IDE environment.
Have a good day!
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>Subject: =?Utf-8?Q?RE:_RE:_RE:_WCF_Service_Library:?=
> =?Utf-8?Q?_=E2=80=9Ccannot_change_thread_mode_afte?=
> =?Utf-8?Q?r?=
>Date: Tue, 9 Oct 2007 14:53:06 -0700