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...

*** Sent via Developersdex http://www.developersdex.com ***

Could be a false positive because of debugger.
Check if this applies:
http://blogs.msdn.com/jmstall/archiv...hDeadLock.aspx

"Kalpana" <(E-Mail Removed)> ha scritto nel messaggio
news:(E-Mail Removed)...
>
>
> 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...
>
> *** Sent via Developersdex http://www.developersdex.com ***

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.

*** Sent via Developersdex http://www.developersdex.com ***

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).

"Kalpana" <(E-Mail Removed)> ha scritto nel messaggio
news:%(E-Mail Removed)...
>
> 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.
>
> *** Sent via Developersdex http://www.developersdex.com ***

"Kalpana" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>
> 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.

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;
}
}



*** Sent via Developersdex http://www.developersdex.com ***

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...

*** Sent via Developersdex http://www.developersdex.com ***

Can you get the stack trace of the exception?

"Kalpana Naraboina" <(E-Mail Removed)> ha scritto nel
messaggio news:(E-Mail Removed)...
>
> 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...
>
> *** Sent via Developersdex http://www.developersdex.com ***