Gui threads (STA) and calling WMI

  • Thread starter Thread starter Arnie
  • Start date Start date
A

Arnie

Posting an issue for a colleague:

They are having an issue w/ making WMI calls from a gui thread. Gui threads
need to be on the STA and there is some speculation that WMI calls need to
be on the MTA, how to mix both?

....

The application is hanging on exit.

When they break into the debugger, the thread on which it is stuck is in a
'WaitOne' call. The call stack is:

mscorlib.dll!System.Threading.WaitHandle.WaitOne() + 0x57 bytes
system.management.dll!System.Management.MTAHelper.WorkerThread() + 0x25
bytes

I searched around a bit on the web, and found this article:
http://discuss.develop.com/archives/wa.exe?A2=ind0306b&L=dotnet-clr&T=0&F=&S=&P=3961

It seems to imply that threads that make WMI calls must be MTA.

And, Paul thinks that GUI threads must be STA. Many .NET controls are just
wrappers on COM controls, which would seem to imply they must be STA.

But, what about threads that are both GUI threads and make WMI calls? Or
are both GUI threads and make MTA-COM calls? They can't be both MTA and
STA...

Any thoughts?
 
Make the call on an anonymous asynchronous delegate. For example:
public delegate void MyDelegate(IList list);
// ...
MyDelegate myDelegate = (MyDelegate)delegate(IList list)

System.Diagnostics.Debug.Assert(System.Threading.Thread.CurrentThread.GetApartmentState() != System.Threading.ApartmentState.STA);
ManagementObjectSearcher query;

query = new ManagementObjectSearcher("SELECT * From Win32_Processor");
foreach (ManagementObject obj in query.Get())
{
list.Add((string)obj["Name"]);
}
};
IList stringList = new List<String>();
IAsyncResult asyncResult = myDelegate.BeginInvoke(stringList, null, null);
// block this thread until the asynchronous delegate is complete
myDelegate.EndInvoke(asyncResult);

Keep in mind, using WMI isn't normally a performant operation and may best
avoided on a GUI thread anyway (to keep it responsive). In the above
example, it blocks the GUI thread until the operation is complete. This is
just for example purposes. I suggest using a callback and letting the GUI be
"free range" while the asynchronous delegate is doing it's work.
 
Hello Arnie,

Why not either to create new thread and set MTA property or to use ThreadPool's
thread which is MTA one?

A> Posting an issue for a colleague:
A>
A> They are having an issue w/ making WMI calls from a gui thread. Gui
A> threads need to be on the STA and there is some speculation that WMI
A> calls need to be on the MTA, how to mix both?
A>
A> ...
A>
A> The application is hanging on exit.
A>
A> When they break into the debugger, the thread on which it is stuck is
A> in a 'WaitOne' call. The call stack is:
A>
A> mscorlib.dll!System.Threading.WaitHandle.WaitOne() + 0x57 bytes
A> system.management.dll!System.Management.MTAHelper.WorkerThread()
A> + 0x25
A> bytes
A> I searched around a bit on the web, and found this article:
A> http://discuss.develop.com/archives/wa.exe?A2=ind0306b&L=dotnet-clr&T
A> =0&F=&S=&P=3961
A>
A> It seems to imply that threads that make WMI calls must be MTA.
A>
A> And, Paul thinks that GUI threads must be STA. Many .NET controls
A> are just wrappers on COM controls, which would seem to imply they
A> must be STA.
A>
A> But, what about threads that are both GUI threads and make WMI calls?
A> Or are both GUI threads and make MTA-COM calls? They can't be both
A> MTA and STA...
A>
A> Any thoughts?
A>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
 
Back
Top