Best way to detect cause of lockups

[Adam Benson]

Hi,

We have a multi-threaded app, which has a windows form front end.

We think we have been pretty careful to ensure that nothing but the UI
thread alters controls on the form. But we've started experiencing lock ups.
Of course, there could be any one of a number of causes but we wonder if one
of our developers has been a little bit careless about using InvokeRequired
and BeginInvoke.

Are there any tools that can help detect this sort of thing? Some tool you
can run your app under and if a control is accessed outside of the UI thread
it pops up an error box? I guess I'm thinking along the lines of
BoundsChecker, but for C#.

Any suggestions gratefully received.

Thanks,

- Adam.

==============================
(e-mail address removed)

 

[Adam Benson]

I should add that I know that CLR 2.0 is much less tolerant and would
probably find this because we'd get an exception, but we're stuck with 1.1
for a while.

- Adam.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Hi,

Are there any tools that can help detect this sort of thing? Some tool you
can run your app under and if a control is accessed outside of the UI
thread it pops up an error box? I guess I'm thinking along the lines of
BoundsChecker, but for C#.

I know of nothing like that, and I do not recall any other post in this
newsgroup about such a tool (and I've been aroudn for a while).

Debugging multithreaded apps is a PITA in my personal opinion. Try to
localize the best you can the possible source of the problem and check the
code.

Good luck with that.

 

[Willy Denoyette [MVP]]

I should add that I know that CLR 2.0 is much less tolerant and would probably find this
because we'd get an exception, but we're stuck with 1.1 for a while.

- Adam.

All you can do is attach a debugger when it happens. Note that deadlocks due to cross-thread
calls are rare, deadlocks because of an inconsistent locking protocol are more likely the
cause.

Willy.

 

[Chris Mullins [MVP]]

We have a multi-threaded app, which has a windows form front end.

We think we have been pretty careful to ensure that nothing but the UI
thread alters controls on the form. But we've started experiencing lock
ups.

When the app is hung, attach a debugger (VS2005 works well), pull up the
Threads window, and start looking through all the threads. You can do this
with Remote Debugging as well, if that works better.

When you get to the point where you can see what threads are deadlocked,
hopefully it won't be too tough to debug from there. You other option is to
generate a MiniDump, and load your dump into WinDbg and Son of Strike.

 

[Adam Benson]

Thanks all for the replies.

Guess I've just got to tough it out. One more question, if I may - I have
taken some process dumps and loaded up the dumps in winddbg using sos.dll,
and I would have expected, if it was a UI hang to find the UI thread in the
same state. But the UI thread is in a totally different call stack every
single time. And yet the app is totally unresponsive. You can resize it, but
the app's front end itself does not repaint.

Has anyone any idea about what may do that?
(We do have some COM objects in the app - showing video - could one of those
objects be producing this?)

If it was 2 deadlocked worker threads I'd expect the UI to still be
responsive. I'm totally confused about how it is the UI is totally
deadlocked but I don't find the UI thread in the same state twice, and we've
now got about 8 snap shots of this.

If no one has anything to add, thanks again for your responses.

- Adam.
=========

 

[Willy Denoyette [MVP]]

Thanks all for the replies.

Guess I've just got to tough it out. One more question, if I may - I have taken some
process dumps and loaded up the dumps in winddbg using sos.dll, and I would have expected,
if it was a UI hang to find the UI thread in the same state. But the UI thread is in a
totally different call stack every single time. And yet the app is totally unresponsive.
You can resize it, but the app's front end itself does not repaint.

That means that the UI thread is blocked, so it's unable to handle paint messages.

Has anyone any idea about what may do that?
(We do have some COM objects in the app - showing video - could one of those objects be
producing this?)

Are you sure the COM objects are marked "Apartment Threaded" and created on the UI thread?
If this is the case, are you aware that the UI thread doesn't process messages for the
duration of a COM call?

If it was 2 deadlocked worker threads I'd expect the UI to still be responsive.

Yep, unless the UI thread also waits on an object held by the worker threads.

I'm totally confused about how it is the UI is totally

deadlocked but I don't find the UI thread in the same state twice, and we've now got about
8 snap shots of this.

And what's the UI thread's call stack saying?

Willy.

 

[Adam Benson]

Hi,

Please strike my last request.

Decided the best thing to do was open an MS support call.

Thanks again for the responses.

- Adam.
===========