How to find out where a thread block occurred?

Question

One of our Windows Forms applications has had a strange problem for several months. The application worked very reliably for most of our customers, but on some PCs (mainly with wireless LAN), the application sometimes just didn’t respond anymore. (You click on the user interface, and windows require you to wait or kill the application).

For a long time I could not track the problem, but now I understood what had happened. The application had this line of code

// don't blame me for this. Wasn't my code :D Control.CheckForIllegalCrossThreadCalls = false 

and used some background threads to change the controls.

Not. I found a way to play the application stopping the response error on my dev machine and tracked it down to the line where I actually used Invoke () to run the task in the main thread.

 Me.Invoke(MyDelegate, arg1, arg2) 

Obviously there is a thread block somewhere. After uninstall

 Control.CheckForIllegalCrossThreadCalls = false 

and refactoring the entire program to use Invoke () when changing a control from a background thread, the problem (hopefully) is gone.

However, I am wondering if there is a way to find such errors without debugging every line of code (even if I broke into the debugger after the application stops responding, I can’t say what happened last because the IDE doesn’t go to the expression Invoke ())

In other words:

If my applications freeze, how can I figure out which line of code was last executed?

Perhaps even on PC clients.

I know that VS2010 offers some debugging feature back, maybe this will be a solution, but I am currently using VS2008.

Answer 1

You most likely correctly identified the culprit by setting CheckForIllegalCrossThreadCalls to false - a great way to create a random deadlock. The only reason the property exists is to enable debugging of borked .NET 1.x programs.

To fix the deadlock, you need to use the Debug + Windows + Threads window to switch between different threads and view their call stacks. But, given the likely nature of the source, this will be difficult, since it is more than likely unmanaged code that does something with the message queue or SendMessage (). Code that you did not write, and do not have source code and do not debug characters. They also tend to be random, and next time they will look completely different.

Windows are fundamentally unsafe objects. They have a very large number of conditions associated with them. Not only in the shells of Windows Forms classes, but also within Windows itself. Hope you fixed the problem.

Answer 2

Maybe this can help you: http://www.debuginspector.com/index.htm

This is a Visual Studio extension that allows you to track deadlocks, and it has many other great features for debugging threads (for example, viewing a still image from multiple threads without going to the threads window).

Answer 3

There is an algorithm for finding deadlocks. Have a look at these google results: http://www.google.be/search?hl=en&client=safari&rls=en&q=deadlock+detection+algorithm&revid=1345706645&sa=X&ei=zqsSTPbmJ4qy0gTvtOWFCg&ved=0CD4Q1QIQIAAIA