How to find out where a thread lock happend?

Posted by SchlaWiener on Stack Overflow See other posts from Stack Overflow or by SchlaWiener
Published on 2010-06-11T21:25:17Z Indexed on 2010/06/11 21:32 UTC
Read the original article Hit count: 223

One of our company's Windows Forms application had a strange problem for several month. The app worked very reliable for most of our customers but on some PC's (mostly with a wireless lan connection) the app sometimes just didn't respond anymore. (You click on the UI and windows ask you to wait or kill the app).

I wasn't able to track down the problem for a long time but now I figured out what happend. The app 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 modify the controls.

No I found a way to reproduce the application stopping responding bug on my dev machine and tracked it down to a line where I actually used Invoke() to run a task in the main thread.

Me.Invoke(MyDelegate, arg1, arg2)

Obviously there was a thread lock somewhere. After removing the

Control.CheckForIllegalCrossThreadCalls = false

statement and refactoring the whole programm to use Invoke() if modifying a control from a background thread, the problem is (hopefully) gone.

However, I am wondering if there is a way to find such bugs without debugging every line of code (Even if I break into debugger after the app stops responding I can't tell what happend last, because the IDE didn't jump to the Invoke() statement)

In other words:

If my apps hangs how can I figure out which line of code has been executed last?

Maybe even on the customers PC.

I know VS2010 offers some backwards debugging feature, maybe that would be a solution, but currently I am using VS2008.

© Stack Overflow or respective owner

Related posts about winforms

Related posts about thread-safety