Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Q on editing while debugging in new VS 2005

323 views
Skip to first unread message

Ed White

unread,
Nov 17, 2005, 3:52:04 PM11/17/05
to
I like the new feature in VS 2005 to be able to edit the code while the
program is running in debug. However, after I starting using VS 2005 (was
using VS 2003 before) I started getting "ContextSwitchDeadlock was detected"
windows pop up from time to time (this never happened before with VS 2003
while running the same program). After Googling for info on that, I found
that someone suggested you could get this error if you have COM references
and unmanaged code debugging is not enabled. So I opened "My Project" on
Solution Explorer, clicked on the Debug tab, and checked "Enable unmanaged
code debugging". After doing that, however, the edit while degugging feature
doesn't work anymore. Why is this ContextSwitchDeadlock error popping now in
VS 2005 where it didn't before, and is there a way to avoid it without losing
the edit on-the-fly feature?
--
Ed

Gary Chang[MSFT]

unread,
Nov 18, 2005, 1:42:09 AM11/18/05
to
Hi Ed,

>Why is this ContextSwitchDeadlock error popping now in
>VS 2005 where it didn't before, and is there a way to avoid
>it without losing the edit on-the-fly feature?

The ContextSwitchDeadlock is one of managed debugging assistants (MDA)
which are debugging aids that work in conjunction with the common language
runtime (CLR) to provide information on runtime state. The MDA is a new
feature in Visual Studio 2005.

The ContextSwitchDeadlock MDA is activated when a deadlock is detected
during an attempted COM context transition, its most probable cause is that
a single-threaded apartment (STA) thread is not pumping messages.

You can disable this kind of MDA by using application-specific
configuration settings, without requirement of "Enable unmanaged code
debugging". For example, add the following code to your project's
ApplicationName.mda.config file:

<mdaConfig>
<assistants>
<contextSwitchDeadlock enable="false" />
</assistants>
</mdaConfig>

Please refer to the following MSDN2 documentation for the details:

Diagnosing Errors with Managed Debugging Assistants
http://msdn2.microsoft.com/en-us/library/d21c150d(en-us,VS.80).aspx

ContextSwitchDeadlock
http://msdn2.microsoft.com/en-us/library/ms172233.aspx


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

Ed White

unread,
Nov 18, 2005, 3:35:06 PM11/18/05
to
Thanks. I have to admit that I don't know what it means when you say "a
single-threaded apartment (STA) thread is not pumping messages." If I'm
getting these ContextSwitchDeadlock messages, is there a problem with the
code that should be fixed?

I tend to use the console Output window a lot when I am debugging, and I've
noticed that the ContextSwitchDeadlock message occurs frequently when the
program is outputting a lot of text to the Output window. Also, when the
ContextSwitchDeadlock window pops up, if I just hit OK or Continue, the
program just continues as if nothing happened. I am puzzled as to what this
is all about.
--
Ed

Ed White

unread,
Nov 18, 2005, 3:49:09 PM11/18/05
to
I could not find an ApplicationName.mda.config file (I didn't see anything
like it, and I searched the solution's folder for .mda.config and nothing
appeared). As suggested in the second link you provided, I also tried adding
the code you suggested to the Main method of my program, but two problems
occurred. First, apparently all of the code needs to be on the same line
(the intellisense suggested that). Then, a squiggly line appears underneath
the word "enable", and twhen I point at it, it says " '>' expected ".
--
Ed

Gary Chang[MSFT]

unread,
Nov 18, 2005, 9:40:31 PM11/18/05
to
Hi Ed,,

>I could not find an ApplicationName.mda.config file (I didn't see
>anything like it, and I searched the solution's folder for .mda.config
>and nothingappeared).

The ApplicationName.mda.config file is not a default project file, you can
create an empty xml file and then copy the MSDN sample code to it, then
save it to the directory of your output app assembly(note: the"
ApplicationName" is just the app assembly's name.)

eg:
MyApp\bin\Debug\MyApp.exe
MyApp\bin\Debug\MyApp.mda.config (create this file)


>If I'm getting these ContextSwitchDeadlock messages,
>is there a problem with the code that should be fixed?

yes, this is a warning message, you need to check your code is there any
similar problem it implied...


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! �§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>Thread-Topic: Q on editing while debugging in new VS 2005
>thread-index: AcXsgYY8Fs7VFKMrRQqKVvrt2YV2ag==
>X-WBNR-Posting-Host: 66.65.179.211
>From: "=?Utf-8?B?RWQgV2hpdGU=?=" <ewh...@newsgroups.nospam>
>References: <C60E67A5-8002-4621...@microsoft.com>
<gSKxAtA7...@TK2MSFTNGXA02.phx.gbl>
>Subject: RE: Q on editing while debugging in new VS 2005
>Date: Fri, 18 Nov 2005 12:49:09 -0800
>Lines: 63
>Message-ID: <6462FDF3-69CE-4B1A...@microsoft.com>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="Utf-8"
>Content-Transfer-Encoding: 8bit
>X-Newsreader: Microsoft CDO for Windows 2000
>Content-Class: urn:content-classes:message
>Importance: normal
>Priority: normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups: microsoft.public.vsnet.debugging
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
>Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.vsnet.debugging:8162
>X-Tomcat-NG: microsoft.public.vsnet.debugging

Jonas Rembratt

unread,
Dec 7, 2005, 7:49:46 AM12/7/05
to
I also receive this message during debugging and I would like to add this:

I'm writing a server app and have been careful NOT to use anything unmanaged
anywhere. There is no use of COM objects anywhere and, by the time of this
error popping up on me, I still haven't initialized the remoting aspects of
the server (haven't published it). Despite all this, I still get this error
more often than not. I do get the impression it turns up if I'm idle too
long during debugging but I don't really know if this has anyting to do with
it.

If there is an underlying problem with my program, what should I look for?

Jonathan Nix

unread,
Feb 13, 2006, 3:41:30 PM2/13/06
to
I've been receiving this every time I'm debugging. It has made the debugger
pretty much unusable.

If I don't go very fast debugging, just waiting to step to the next line
invokes this MDA. Of course the UI thread is not pumping its messages: I'm
sitting at a breakpoint!

I thought (hoped) it was just a side-effect of the WinFX January CTP...

Putting this in Program.exe.mda.config has possibly avoided this MDA and
I've now been able to debug for at least a whole minute...

<?xml version="1.0" encoding="utf-8" ?>
<configuration>


<mdaConfig>
<assistants>
<contextSwitchDeadlock enable="false" />
</assistants>
</mdaConfig>

</configuration>

Thanks.. I hope it continues to work now.

Jonathan Nix

unread,
Feb 13, 2006, 8:55:21 PM2/13/06
to
Nope.. I'm still getting that MDA, even though I applied the registry key
that's supposed to suppress most MDA's, and even though I used the
configuration file to suppress that specific MDA.

The MDA still triggers. It's a little different though, sometimes I can
resume debugging by pressing F5. One time the program hung without the MDA
coming up, and another time it hit the MDA and then hung, I think.

But I can debug for a longer period of time (couple minutes) before the MDA
comes up.

Come to think of it, I am using a COM interop assembly, but I thought this
happened regardless of that.

Note: I'm also using CTP builds, so I thought that had mostly to do with it.
Is anyone encountering this on the release 2006 installation?

0 new messages