[RESOLVED] Causes of "Cross-thread operation not valid"

Upon googling it seem to be related to using multiple threads but oddly I am not creating any thread at all and yet I am encountering the above error. This has been baffling me no end and I am running out of ideas as to how to solve this problem. Related thread is here.

I have already even tried using CheckForIllegalCrossThreadCalls = False just to try fixing it but to no avail.

Code:

---

System.Windows.Forms.Control.CheckForIllegalCrossThreadCalls = false;

---

I really hope someone could help me out on this.

I can't see any way this error would arise if you were not using multiple threads - I suspect that something you are doing is implicitly creating a new thread.

I see from your other post you are using a 3rd party control - it is possibly something this control is doing that is spawning a new thread.

Is there a stack trace when the exception is thrown?

Yes, this is the stack trace.

Quote:

---

at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Control.Invalidate(Boolean invalidateChildren)
at Janus.Windows.ExplorerBar.ExplorerBar.l()
at Janus.Windows.ExplorerBar.ExplorerBar.c(ExplorerBarGroup A_1)
at Janus.Windows.ExplorerBar.ExplorerBarGroupCollection.c(ExplorerBarGroup A_1)
at Janus.Windows.ExplorerBar.ExplorerBarGroup.set_Container(Boolean value)
at Janus.Windows.ExplorerBar.ExplorerBarContainerControl.Dispose(Boolean disposing)
at System.ComponentModel.Component.Finalize()

---

That stack trace is rooted at a Finalize method so that means it's occurring when the GC is cleaning up. You might want to make sure that you're disposing everything as you should be, which may avoid the issue. That said, while not disposing objects is a bad idea it shouldn't cause problems like that, so I'd send all the details to your third-party component vendor because it looks like their issue.

Quote:

---

Originally Posted by keystone_paul

I see from your other post you are using a 3rd party control - it is possibly something this control is doing that is spawning a new thread.

---

I am slowly leaning into that reason. If that is the case then is there something I can do without removing the 3rd party control?

Quote:

---

Originally Posted by jmcilhinney

That stack trace is rooted at a Finalize method so that means it's occurring when the GC is cleaning up. You might want to make sure that you're disposing everything as you should be, which may avoid the issue. That said, while not disposing objects is a bad idea it shouldn't cause problems like that, so I'd send all the details to your third-party component vendor because it looks like their issue.

---

Its just a normal form so I'd thought it would dispose of its objects appropriately when it is closed, is it not?

Where could I dispose those objects?

Thanks in advance!

Is it the startup form?

No, they are different forms and the error is random among them but the same control since those forms have the same control.

Quote:

---

Originally Posted by dee-u

No, they are different forms and the error is random among them but the same control since those forms have the same control.

---

I would guess that the error appears random to you because it's occurring when the GC is invoked, which is unpredictable with regards to your app. I can tell the GC is running because that's the only time the Finalize method is called. It appears that something is not being disposed properly when the form is closed and then, when the GC runs, it Finalizes the object and attempts to access a control handle. It appears that that's a problem because the GC runs on a thread other than the one that owns that handle.

I think I have already tried .Close() and .Dispose() on the form but still the problem persists, how should I be able to dispose of the problematic control? I will try later on in the Form_Closing event when I get hold of the code but I would want your guidance on how to do this properly.

It's not the form that's the problem. It's a control on the form. I would expect that the stack trace would lead you to it.

I am thinking, perhaps when I quickly click on the treeview nodes which displays and closes the forms there could be a deadlock or something wherein while the form is being loaded/shown then it is also being closed at the same time?

I will give it a shot of disposing of the control when the form is being closed just to see if it will remedy the problem.

Another crazy idea I am looking into is to just show in different threads, will that work?

Quote:

---

Originally Posted by dee-u

Another crazy idea I am looking into is to just show in different threads, will that work?

---

Will that make the GC run on those threads?

I really don't know so I said its crazy. The detail of my plan is like upon clicking of a node:

-Start a thread which will show the form
-Upon full showing of the form then stop the thread which called it
-Upon clicking the node then if the previous thread is not stopped then stop it

Or probably a backgroundworker would be more fit for this. I am just accumulating ideas which would make me solve this.

You can't display a form on a thread and then stop that thread. The original issue is that you were getting cross-thread issues so if you start displaying a form on a thread that the ceases to exist, how could you possibly access that form again without cross-thread issues?

Please take a good look at the stack trace. It is provided to help you diagnose the issue so use it. The GC is calling Finalize and the next method called is Dispose on a ExplorerBarContainerControl, so that's the point to start looking. Some more methods get called until Invalidate is called by an ExplorerBar, either on itself or some other object. What does the Invalidate method do? It tells a control what parts of itself need to be drawn on the next repaint. Why would a control need to be repainted if it's being finalized by the GC?

Are you starting to see why this information is provided and how it can be used to diagnose the issue?

Sorry, I am not adept with analyzing those stack traces.

So System.Windows.Forms.Control.Invalidate is called by ExplorerBar?

Do you know what the call stack represents? The top line is the last method called, i.e. the one that threw the exception. The second line is the method that called that last method. The third line is the method that called that second last method and so on. As you can see, the line below the Invalidate call is a method of the ExplorerBar class. The name is meaningless because the code has been obfuscated but you know for a fact that ExplorerBar.l() called Control.Invalidate().

You should be using the Call Stack window in VS as a debugging tool regularly as well. I suggest that you play with it to get more accustomed to what it contains and what it can do for you.

Thank you for taking time with me on this, I really appreciate it. Upon initial testing it seems that disposing of the faulty control on FormClosing has solved the issue.

I am still curious with your advice on post #5, could you elaborate on "disposing everything"? I make it a point to be able to dispose of my objects although I admit I may not be disposing every object I create, at times I lean on the behaviour that the objects will be disposed when they go out of scope. And in cases with forms I am just closing them without ever disposing.

Disposing a form should inherently dispose all the design-time components it contains. If that's not happening then that's a bug in your third-party control.

If you're displaying your form by calling Show then Closing it will dispose it. If you're using ShowDialog then Closing the form does not dispose it. In that case it's your responsibility to dispose it yourself, which is usually done with a Using block. That said, undisposed objects should still be cleaned up without throwing an exception when Finalized. That's what Finalizing is for. It sounds like that's not happening in your case so, again, I think there's a bug in your control.

By disposing control explicitly, even if it shouldn't technically be necessary, you are ensuring that the handle isn't accessed from a thread that doesn't own it when the GC calls the Finalize method so you avoid the exception. This is a workaround for you but you still need to notify the control author of the issue so that they can fix it.

Okay, that is a lesson learned, thank you for the information.

I will dig on stack traces next, do you have a handy link that will provide a more detailed explanation on how it can be used effectively?

http://msdn.microsoft.com/en-us/library/a3694ts5.aspx

That's about all I've read on the subject.