ContextSwitchDeadlock Problem

[Kalpana]

Hi,

As iam working on convertion of C#1.1 to 2.0. Iam facing a problem
(screen is flickered) while opening and closing any artifacts. When i
tried to debug it is througing ContextSwitchDeadlock MDA exception i.e.

The CLR has been unable to transition from COM context 0x1a0768 to COM
context 0x1a08d8 for 60 seconds. The thread that owns the destination
context/apartment is most likely either doing a non pumping wait or
processing a very long running operation without pumping Windows
messages. This situation generally has a negative performance impact and
may even lead to the application becoming non responsive or memory usage
accumulating continually over time. To avoid this problem, all single
threaded apartment (STA) threads should use pumping wait primitives
(such as CoWaitForMultipleHandles) and routinely pump messages during
long running operations.

please suggest...

 

[Laura T.]

Could be a false positive because of debugger.
Check if this applies:
http://blogs.msdn.com/jmstall/archive/2005/11/11/ContextSwitchDeadLock.aspx

 

[Kalpana]

It is not working.
Is there is any chance of having this problem due to the handles invoked
from WndProc()?

Previoulsy i had a problem with Utilitylibrary.Rebar --> WndProc()
recursive call (deadlock). I posted this problem but no one reply --> so
for the temporary survive i kept a condition for termination (to avoid
deadlock). condition is:
if (m.Msg == (int)Msg.WM_WINDOWPOSCHANGED)
return;
if condition reaches then control will be returned from WndProc().

Is this present problem of flickering (when we don't debug) and
ContextSwitchDeadLock exception --(when we debug -- see the exception
below) is due to WndProc() condition??
However please suggest

EXCEPTION DESCRIPTION:
The CLR has been unable to transition from COM context 0x1a0768 to COM
context 0x1a08d8 for 60 seconds. The thread that owns the destination
context/apartment is most likely either doing a non pumping wait or
processing a very long running operation without pumping Windows
messages. This situation generally has a negative performance impact and
may even lead to the application becoming non responsive or memory usage
accumulating continually over time. To avoid this problem, all single
threaded apartment (STA) threads should use pumping wait primitives
(such as CoWaitForMultipleHandles) and routinely pump messages during
long running operations.

 

[Laura T.]

WndProc should be considered as non re-entrant (and this not recursive).
If you must send messages to other controls owned by you, use PostMessage
(non blocking), not SendMessage (blocking).

 

[Willy Denoyette [MVP]]

It is not working.
Is there is any chance of having this problem due to the handles invoked
from WndProc()?

Previoulsy i had a problem with Utilitylibrary.Rebar --> WndProc()
recursive call (deadlock). I posted this problem but no one reply --> so
for the temporary survive i kept a condition for termination (to avoid
deadlock). condition is:
if (m.Msg == (int)Msg.WM_WINDOWPOSCHANGED)
return;
if condition reaches then control will be returned from WndProc().

We realy can't help you if you are only posting some lines of code, what else are you doing
after this..
if (m.Msg == (int)Msg.WM_WINDOWPOSCHANGED)
return;
..... // ????

Willy.

 

[Kalpana Naraboina]

protected override void WndProc(ref Message m) {
if (m.Msg == (int)Msg.WM_WINDOWPOSCHANGED)
return;
base.WndProc(ref m);

switch (m.Msg)
{
case (int)Msg.WM_PAINT:
PaintBackground();
break;
case (int)Msg.WM_NOTIFY:
case (int)((int)Msg.WM_NOTIFY + (int)Msg.WM_REFLECT):
{
NMHDR note = (NMHDR)m.GetLParam(typeof(NMHDR));
switch (note.code)
{
case
(int)RebarNotifications.RBN_HEIGHTCHANGE:
UpdateSize();
break;

case
(int)RebarNotifications.RBN_CHEVRONPUSHED:
NotifyChevronPushed(ref m);
break;

case (int)RebarNotifications.RBN_CHILDSIZE:
NotifyChildSize();
break;
case (int)NotificationMessages.NM_NCHITTEST:
break;
}
}
break;
}
}

 

[Kalpana Naraboina]

Hi,

I used PostMessage() instead SenMessage() this avoided blocking i.e.
infinite loop but giving unhandled Exception:

AccessViolationException: Attempted to read or write protected memory.
This is often an indication that other memory is corrupt

I searched the cause of this exception but that solutions are not
helping the need (like debugger setting from tools --> options)

My application Rebar --> toolbar is not visible and Navigations are not
working fine

NOTE: POSTMESSAGE() is used only for user coded wndproc() methods still
SENDMESSAGE()exists.

IMPORTANT NOTE is all these problems are due to the Utility Library
Rebar --> WndProc() handles issue. if we use the new toolstrip from VS
2005 these problems doesnot exists.

There is a necessity with Utility library Rebar --> WndProc() --> i want
to solve this issue

Please suggest...

 

[Laura T.]

Can you get the stack trace of the exception?