Find out which winforms controls are accessed from a background thread

Question

We have built a huge winforms project, already in progress for multiple years.

Sometimes, our users get an exception which looks like this one.

The resolution of this problem seems to be:

don't acces UI components from a background thread

.

But since our project is a very big project with a lot of different threads, we don't succeed in finding all these.

Is there a way to check (with some tool or debugging option) which components are called from a background thread?

To clarify:

I created a sample winforms project with a single Form, containing two Button

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void button1_Click(object sender, EventArgs e)
    {
        button1.Text = "Clicked!";
    }

    private void button2_Click(object sender, EventArgs e)
    {

        Task.Run(() =>
        {
            button2.BackColor = Color.Red; //this does not throw an exception
            //button2.Text = "Clicked"; //this throws an exception when uncommented
        });
    }
}

The background color of button2 is set to red when the button is clicked. This happens in a background thread (which is considered bad behavior). However, it doesn't (immediately) throw an exception. I would like a way to detect this as 'bad behavior'. Preferably by scanning my code, but if it's only possible by debugging, (so pausing as soon as a UI component is accessed from a background thread) it's also fine.

Answer 1

I've got 2 recommendations to use together, the first is a Visual Studio Plugin called DebugSingleThread.

You can freeze all the threads and work on one at a time (obviously the non-main-UI threads) and see each threads access to controls. Tedious I know but not so bad with the second method.

---

The second method is to get the steps in order to reproduce the problem. If you know the steps to reproduce it, it will be easier to see whats causing it. To do this I made this User Action Log project on Github.

It will record every action a user makes, you can read about it here on SO: User Activity Logging, Telemetry (and Variables in Global Exception Handlers).

I'd recommend you also log the Thread ID, then when you have been able to reproduce the problem, go to the end of the log and work out the exact steps. Its not as painful as it seems and its great for getting application telemetry.

You might be able to customise this project, eg trap a DataSource_Completed event or add a dummy DataSource property that sets the real Grids DataSource property and raises an INotifyPropertyChanged event - and if its a non-main thread ID then Debugger.Break();.

---

My gut feeling is you're changing a control's (eg a grid) data source in a background thread (for that non-freeze feel) and thats causing a problem with synchronisation. This is what happened to the other DevExpress customer who experienced this. Its discussed here in a different thread to the one you referenced.

Answer 2

Is your app set to ignore cross threading intentionally?

Cross-thread operations should be blowing up all the time in winforms. It checks for them like crazy in just about every method. for a starting point check out https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs.

Somewhere in your app, somebody might have put this line of code:

Control.CheckForIllegalCrossThreadCalls = False;

Comment that out and run the app, then follow the exceptions.

(Usually you can fix the problem by wrapping the update in an invoke, e.g., in a worker thread if you see textbox1.text=SomeString; change it to `textbox.invoke(()=>{textbox1.text=SomeString;});.

You may also have to add checking for InvokeRequired, use BeginInvoke to avoid deadlocks, and return values from invoke, those are all separate topics.

this is assuming even a moderate refactor is out of the question which for even a medium sized enterprise app is almost always the case.

Note: it's not possible to guarantee successful discovery of this case thru static analysis (that is, without running the app). unless you can solve the halting problem ... https://cs.stackexchange.com/questions/63403/is-the-halting-problem-decidable-for-pure-programs-on-an-ideal-computer etc...