Find owner thread of GUI control

Question

Working on a .NET app, I've run in a 'cross-thread operation not valid' exception, only it seems to happen in the correct thread. Is there a way to find out which thread is the one where a specific control has been created?

What I've found so far:

The 'InvokeRequired' operation only tells IF the current thread is the "owner thread"... A bit of fun time with Reflector on the Control.Invoke(...) method got me to a P/Invoke method in user32.dll that gets the thread Id from a window handle:

[DllImport("user32.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
public static extern int GetWindowThreadProcessId(HandleRef hWnd, out int lpdwProcessId);

Answer 1

Can you capture the thread ID when the event is created in a handler and compare that to when you are getting the exception. That will at least tell you if you are on the same thread.

Answer 2

Control.BeginInvoke() is always worked fine for me. Try it.

Answer 3

Try using Spy++ application, it comes with VS and shows you a list of windows (most controls are separate subwindows) and some information about them.

Answer 4

I've encountered the same issue. I get that exception even when using the control from the UI thread. In my case, I was using InvokeRequired (or Invoke) on a background thread before the Handle of the control was created. It was a context menu of a tray icon, and some background thread had to change the value of a menu item. If the user never opened the context menu, the handle was never created, the control was never bound to the UI thread, and havoc ensued. When this happened, the InvokeRequired always returned false and Invoke just ran the method on the current thread (which was not the UI thread), and so the Handle was created on the background thread and the control was forever bound to that thread, as if the background thread was its UI thread. And when trying to use the control form the UI thread, a cross-thread exception was thrown. On the other hand, if the user opened the context menu before running any background threads, everything would work fine.

The solution was to call the CreateControl() method from the UI thread at startup, before any background thread has chance to 'steal' the control and to corrupt thread ownership.