Search

Debugger randomly treats "step-into" and "step-over" as "run to completion" by Ravi Bhavnani

Resolved
as Fixed Help for as Fixed

162
3
Sign in
 to vote
Type: Bug
ID: 556756
Opened: 5/3/2010 6:46:09 PM
Access Restriction: Public
0
Workaround(s)
88
User(s) can reproduce this bug
The VS2010 (Premium) debugger randomly treats "step-into" and "step-over" commands as "run to completion" when debugging a .NET 3.5 assembly.
Details (expand)

Product Language

English

Visual Studio Version

Visual Studio 2010

Operating System

Windows XP

Operating System Language

English

Steps to Reproduce

(1) Create a .NET 3.5 assembly containing a class Foo with methods A, B and C, such that A calls B which calls C which happens to throw an exception because it's broken.

(2) Assume Foo.A() looks like this:

public static void A()
{
int x = 0; // set breakpoint here
int y = 1;
B();
}

(3) Set a breakpoint at the 1st statement in A() and start debugging.

(4) When the breakpoint is reached, step over the statement.

(5) Attempt to step over the next statement (int y = 1;).

Actual Results

The program runs to completion, eventually aborting due to an uncaught exception somewhere inside B(). It's as if I pressed "Continue" instead of "Step Over". This happens regardless of whether I step over using a function key, menu command or toolbar button. I've verified I'm not accidentally pressing "Continue".

Expected Results

The debugger is stopped at the 3rd statement, i.e. the call to B(), allowing me to step into B() to see what's wrong.
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey.

 

File Attachments
File Name Submitted By Submitted On File Size  
ActivityLog.xml MikeGCompass 8/10/2010 333 KB
Sign in to post a comment.
Posted by -Andre- on 4/25/2012 at 8:11 AM
Todd.Wilder, Lock at this and post it there ;)

https://connect.microsoft.com/VisualStudio/feedback/details/663614/debugger-randomly-treats-step-into-and-step-over-as-run-to-completion

There's also the e-mail (of Marc Paine) which is the Visual Studio Debugger QA Lead.

Regards
Posted by Todd.Wilder on 12/27/2011 at 3:01 PM
I have this problem occuring on vs2010 sp1 on a vm I can send to MS if they want to see it. Its really easy to reproduce
Posted by Odsh77 on 12/6/2011 at 6:34 AM
I still have this problem, even with the latest updates for VS2010, and it's extremely annoying.

We had exactly the same bug in VS2008; a hotfix had been released which worked: http://support.microsoft.com/kb/957912
Wouldn't it possible to release a similar hotfix for VS2010?
Posted by fjbd on 8/5/2011 at 7:24 AM
Is this going to be fixed? As it stands the debugger is useless for MS unit tests. It appears to be trivially easy to reproduce.
Posted by kingces95 on 8/4/2011 at 1:18 AM
Bad news for the VS debugger\CLR team. If they resolved this issue as closed than they are just trying to sweep it under the rug. This would be a good time for them to crack open the internal job website and look for openings because eventually it'll become apparent that 2010 stepping is very very broken...
Posted by DennusTheMennus on 7/22/2011 at 1:14 AM
Me too. The debugger treats an F10 like an F5. Working with MS stuff is like pulling teeth.
Posted by jmiles11 on 6/4/2011 at 3:11 PM
To clarify, this turned out to be a case of this phenomenon: http://connect.microsoft.com/VisualStudio/feedback/details/526541/multithreaded-debugging-f10-f11-thread-switch-prevention . Is there a way to limit the amount of time other threads can run when using the F10 key?
Posted by jmiles11 on 6/3/2011 at 7:46 PM
This bug still occurs in VS2010 (10.0.40219.1 SP1Rel) when debugging a simple C++ executable on a Win64 machine. When I force a break with _asm iint 3 and hit F10 (Step Over) a couple of times, the program starts running indefinitely.

Back to VS2008 until someone decides to get the basic stuff right.
Posted by Charles Sterling on 4/20/2011 at 11:56 AM
Hello Ray,
I am having the Debug Test team look into this but can i get you to post the answers to two questions at the new bug?

https://connect.microsoft.com/VisualStudio/feedback/details/663614/debugger-randomly-treats-step-into-and-step-over-as-run-to-completion


1. This is a 64-bit debuggee -correct?
2. The SP1 msvsmon.exe is being used -correct?

Thanks
Charles Sterling
Posted by Charles Sterling on 4/20/2011 at 9:28 AM
Filed as:
https://connect.microsoft.com/VisualStudio/feedback/details/663614/debugger-randomly-treats-step-into-and-step-over-as-run-to-completion

Will get ops to increment vote count to match existing issue.
Thanks
Charles Sterling
Microsoft
Posted by Charles Sterling on 4/20/2011 at 9:16 AM
Hello Ray,

Thanks for the update.
I am going to create a new bug (and have ops increment the vote back to 146 ) so we can track this against our current development efforts. If the team decides this is a regression in SP1 (sounds like it could be) there might be a hot fix. Otherwise this will go into a our Dev vNext Backlog. If you want to expedite the process calling support will fast track the issue http://support.microsoft.com
I will post the new Connect bug as soon as I have it.

Thanks
Charles Sterling
Microsoft
Posted by Ray Riopel on 4/19/2011 at 5:40 PM
SP1 doesn't fix it. I still have the same problem.
Posted by Microsoft on 4/19/2011 at 1:49 PM
Hello Richard,
This should have been fixed in the relase of SP1.
If it is not please email me:
chass@microsoft.com

Thanks
Charles Sterling
Micorosft
Posted by Richard Metzler on 3/29/2011 at 4:41 AM
Same problem with my system (XP, VS2010 Professional with SP1 beta). Debugging a unit test (C++/CLI, .NET 4.0) sometimes runs to completion, but usually causes VS to hang.
This is extremely annoying. I view unit tests primarily as a setup to debug my algorithm code with well-defined input and little overhead. Having a debugger that refuses to play with the test unit framework kind of defeats the purpose. Please fix this ASAP!
Posted by lostmsu on 3/25/2011 at 2:42 AM
VS 2010 SP1/Win7 x64, same problem. It seems that problem does not appear if you would do steps with some interval between them (2-3 seconds)
Posted by EcologicalModelling on 3/20/2011 at 5:29 PM
Same issue here. VS2010 Professional with SP1, Win64 Ultimate. Wasted a week of my employer's money on this issue. Can't upgrade perfectly working .Net 1.1 project. I get between 5 to 15 F8, F10 or F11 before program simply exits. Absolute waste of time and money. May ditch MS altogether. Issues like this is why I waited for this VS10 to be out for 6+ months before buying it.
Posted by Steve Hoff on 3/17/2011 at 6:26 AM
Exact same issue. VS2010 Ultimate, Win7 64 Ultimate. Debugging is impossible with unit tests. This is on a .net 4 assembly so they quote above should be changed.
Posted by komplikatedone on 3/11/2011 at 2:26 AM
debugging at moment is verging on the impossible
re-install sounds like my only real option at the moment
Posted by Richard Morrison on 3/9/2011 at 12:16 PM
Same issue running MsTest unit test with resharper on a .Net 4.0 assembly
Posted by JeZteRicp on 3/3/2011 at 2:00 PM
@codekaizen: thanks for your relpy. i don't think that's related though. mine doesn't crash, it just continues running but the IDE stays in the debugger state.
Posted by codekaizen on 3/3/2011 at 1:07 PM
@JeZteRicp: I've seen this behavior as well, even after installing SP1 Beta, even to the point of MSVSMon (Visual Studio Remote Debugging Monitor) crashing on me. I've logged a separate issue #649208 (https://connect.microsoft.com/VisualStudio/feedback/details/649208/msvsmon-frequently-crashes-running-vs-2010-sp1-beta ) to track it.
Posted by JeZteRicp on 3/3/2011 at 10:45 AM
Add to my last comment;
when i add something to the Watch window it has to think too hard and the program just runs away with itself adding the "unable to evaluate expression" error in the watch window.
Posted by JeZteRicp on 3/3/2011 at 9:50 AM
I'm pretty sure this is related...

I don't have to be stepping, I can just be looking at the current state of my variables and anything that makes the IDE think will cause it to run. i.e. if i look at a datatable or anything that has several properties, when i try to scroll to see more properties everything changes to "unable to evaluate expression" next thing i know my app is running but my IDE still appears to be in break mode.

it also does it when stepping though.
Posted by CyrusCurwood on 3/2/2011 at 1:43 AM
I am getting this issue when debugging a C# Unit Test (framework 4.0) against a VB.Net class (framework 2.0) in VS2010 Premium on Windows XP Pro 32-bit.

I am installing the SP1 Beta now to see if it solves.
Posted by Jose R Rodriguez - Atkins on 3/1/2011 at 6:26 AM
I have same issue with VS 2010 Premium running in Windows 7 x64 when debugging .Net 4 assembly.
Posted by codekaizen on 2/25/2011 at 3:00 PM
After 2 months of SP1 Beta, this issue appears to be resolved in my case (Win7 x64) and in one other case in my office (WinXP x32). However, now the problem is that the VS Remote Debugger quits fairly regularly (about 1 time per day). The error is: "The remote debugger has encountered a serious internal error, and must abort the remote debugging session. Please restart debugging."
Posted by Peter LaComb on 2/25/2011 at 7:34 AM
I never saw this issue until AFTER installing SP1 Beta. Wish it would go away.
Posted by Mark Cranness on 2/17/2011 at 8:15 PM
After 12 days use, I can add this:

- Applying Visual Studio 2010 SP1 Beta but NOT Build>Rebuild'ing projects did NOT initially help: very often F10/F11 skip forward unexpectedly.

- Uninstalling VS2010 completely, re-installing VS2010, installing VS2010 SP1 beta (twice, the PC crashed during) and Build>Re-build projects DID help quite a bit.
F10/F11 still do sometimes skip forwards unexpectedly, but far less frequently than it used to, maybe 1% to 4% of the time, still annoying.
Posted by LesBakerBJSS on 2/16/2011 at 2:23 AM
I'm using Visual Studio 2010 and have exactly the same problem, it appeared after I tried clicking the option to Debug the .NET binaries. This downloaded some files and has never worked the same since. I disabled the option and now when i debug a library which is a project reference of the program being debugged, it hits breakpoints but will not 'step over' or 'step into' anything from the library. instead it jumps out to the first point of the call stack in the executing application.

This would seem to be a problem caused by something downloaded by VS2010 when I originally checked the box for using the .NET source debugging.

In addition, with the box still unchecked, and having the exceptions 'when thrown' checked, i am getting notifications every time something in the .net libraries throws an exception but handles it itself, e.g. XMLDocument methods.
Posted by Georg von Kries on 2/11/2011 at 1:02 PM
Hello,

I’m experiencing this problem too while debugging a complex multithreaded project. Installing SP1 has made thing way better, but it is still occasionally happening. This is really annoying… :-(

Regards,
Georg
Posted by Mark Cranness on 2/6/2011 at 5:34 PM
I have this also.

F10 or F11 work about 80-90% of the time, but the other 10-20%, act as F5 or sometimes <n> or so F10s or F11s (it will stop eventually, either on a breakpoint, or some code that does not have a breakpoint).

The app is a simple WPF form calling a custom class method that uses Entity Framework and NHibernate.

Visual Studio 2010 on Windows Server 2008 R2.

Applying Visual Studio 2010 SP1 Beta did NOT help.

Microsoft Visual Studio 2010 10.0.31118.1 SP1Rel
Microsoft .NET Framework Version 4.0.30319 SP1Rel
Microsoft Visual C# 2010 01018-532-2002102-70656
Posted by codekaizen on 12/16/2010 at 5:58 PM
It does appear to be fixed in VS 2010 SP1 Beta. Unfortunately, the Visual Studio Debugging Monitor crashes from time to time, but this is better than the previous unbearable situation.
Posted by Christiansei on 12/14/2010 at 9:16 AM
Hi,
I've tried it on an second machine and there it seems to be working. I compared the detailed version strings of VS2010 after successfully applying the service pack on both machines:

Microsoft Visual C# 2010 01021-532-2002102-70680 on the machine, where the fix isn't working
Microsoft Visual C# 2010 01021-532-2002102-70985 on the maching, where it's working

Both have got Microsoft Visual Studio 2010 Premium - ENU Service Pack 1 (KB983509) KB983509 installed with the "main" version string "Version 10.0.31118.1 SP1Rel" and the same Framework Version.

Any ideas why the two have got different Visual C# versions?

Regards,
Christian
Posted by Christiansei on 12/9/2010 at 11:41 PM
hi,
I've installed the service pack yesterday and tested my cases, where the problem occured most of the time. Unfortunately the debbuger still ignores "step over" or "step into" and runs to the next breakpoint or to the end instead.

I'm debbuging a windows form project, Framework 3.5, Windows 7 x64 OS, VS 2010 Premium - Version 10.0.31118.1 SP1Rel
Do I have to install anything else for the fix?

Christian
Posted by Microsoft on 12/8/2010 at 3:54 PM
Hi All,

Thanks for your patience with this issue. Jason Zander recently announced the release of the beta for Visual Studio 2010 SP1. In this service pack, we have fixed the issue where the debugger was suddenly running to completion when debugging .NET 4.0 applications with the bug most commonly surfacing when debugging unit tests. (Please note that unit tests were using .NET 4.0 even when set to use 3.5)

The beta will be available to the general public tomorrow.
http://blogs.msdn.com/b/jasonz/archive/2010/12/07/announcing-visual-studio-2010-service-pack-1-beta.aspx
I encourage you all to install it.

Thanks,
Visual Studio Debugger Team
Posted by BetterToday on 11/26/2010 at 5:01 AM
Whenever I try to set a conditional breakpoint anywhere in the code to test, Visual Studio throws an error when that breakpoint is reached. The error message reads (translated):

'Breakpoint can not be set:

At ... (...), if "myArray[i]==3000" is "True".

All threads must be running to enable expression evaluation.'

Perhaps this behaviour has something to do with it?

I'm starting a test debugging session by hitting CTRL+R, CTRL+T

Axel Dahmen
Posted by BetterToday on 11/20/2010 at 7:22 AM
No... after debugging some more I can say now that debugging VS does *not* stop this problem from occuring... *sigh*

Axel Dahmen
Posted by BetterToday on 11/19/2010 at 4:19 PM
I'm also experiencing this problem. It also happens to me each time I'm debugging a unit test (CTRL+R, CTRL+T).

I suspected an internal Visual Studio exception to be the reason for that, so I started a second Visual Studio session and attached that debugger to my first Visual Studio session. But when I did this, the error never occured. So you might call this (a) a workaround, and (b) the reason why MS cannot reproduce this issue.

Regards,
Axel Dahmen
www.axeldahmen.de
Posted by David Lowndes on 11/19/2010 at 3:12 PM
I'm experiencing what appears to be the same issue - when debugging a MMC snapin written (and debugged) in C# .Net V2 with VS2008 SP1. The machine also has VS2010 installed on it.
Posted by David VanSickle on 11/17/2010 at 11:27 AM
VS 2010 after it catches an error no longer catches breakpoints until shutdown and restart of VS. Tried a repair of VS 2010, same behavior. Next step is to uninstall and re-install, any suggestions before I try that?
Posted by TheCloudlessSky on 11/16/2010 at 4:17 PM
I thought I had this issue before as well but noticed that it was because the compiler was optimizing the code and was "skipping" lines that it optimized (or removed). This *seems* like it would be the case for Ken Han below. Just my thoughts.
Posted by PatEnns on 11/11/2010 at 7:13 AM
We (me and 8 co-workers) have the same issue.
The bug occurs reproduceable on different machines with a lot of different C# projects (no unit tests).
In one project the bug is reproduceable in a special loop in aprox. 1 of 8 test cases.

Environment:
Visual Studio 2010 Premium
Windows XP Professional
OS and VS Language is german
Projects: C# .net 4 as Windows Forms Project (most converted from .net 2.0)

@Microsoft: We loose time in debugging every day, if we have to put a breakpoint in every single line.
What's about the fix (posting from 2010-10-01)?
When we can expect the fix?
Posted by ricflams on 11/5/2010 at 6:28 PM
I've had the same problem, but in a completely reproducable manner. It's on VS2008, though:

When single-stepping through my app the debugger would always switch to "run" after another thread had thrown an exception. I used to disable that part when single-stepping until I changed the architecture and avoided the particular construction for other reasons, which was quite a relief. But before that I investigated it thoroughly and there's no doubt: that other thread's exception was the sole reason the debugger switched from single-step to run-mode.

The particular code was a background-thread with some socket code that would throw a benign exception upon timeout, which was somewhat annoying as the exception couldn't be avoided and the timeout was 60 seconds.
Posted by jc1455 on 11/3/2010 at 11:06 AM
I hope we can look forward to a fix for this soon! It makes it pretty hard to fix bugs without doing something to reproduce an issue outside of the unit tests.
Posted by Riaan Stander on 11/1/2010 at 11:06 PM
Not just premium though. I'm getting this with Professional.
Posted by cjlotz on 11/1/2010 at 7:49 AM
Also stuck with this. Any further feedback as to when we can expect a fix?
Posted by The Cool Rob on 10/29/2010 at 6:58 AM
It actually makes the debugger unusable when working through unit tests. The most annoying issue ever. I've also started getting 'Source Not Found' errors - not sure if anyone else here gets something similar (i.e. if the issues are somehow related)?
Posted by codekaizen on 10/28/2010 at 12:39 PM
@Azeem Khan - Excellent work!

As to distribution, I'd be happy to walk, no, crawl the 240 miles up to Redmond to pick up the hotfix...
Posted by Gil.Y on 10/28/2010 at 3:04 AM
I'm not sure on this and I can't reproduce it even though it happens all the time.
I did notice it happens more within methods which make calls to factory patterns.
Posted by Ken Han on 10/3/2010 at 7:36 PM
I can reproduce in the following unit test extract:

[TestMethod]
        public void ChangeMember()
        {
            try
            {
                using (ISession session = NHibernateHelper.OpenSession())
                {
                    IMemberDAO memberDAO = daoFactory.GetMemberDAO();
                    string newName = "New Name";

                    using (session.BeginTransaction())
                    {
                        CurrentSessionContext.Bind(session);

                        session.Lock(addedMember, LockMode.None);
                        addedMember.LastName = newName;
                        session.Transaction.Commit();
                    }
                    Member aMember = memberDAO.FindById(addedMember.ID);
                    Assert.AreEqual(newName, aMember.LastName);

                }
            }
            catch (StaleObjectStateException ex)
            {
                logger.Error("Stale Ex, Ken: " + ex);
                int i = 0;
                throw new InfrastructureException(
                "Rethrow Stale Object Exception", ex);
            }
            catch (HibernateException ex)
            {
                throw new InfrastructureException(
                "Error while accessing the database", ex);
            }
            finally
            {
                CurrentSessionContext.Unbind(NHibernateHelper.SessionFactory);
            }
        }

The above is a NHibernate unit test, put a break point on                
        logger.Error("Stale Ex, Ken: " + ex);
Then you will find the next line
                int i = 0;
get skipped most of the time.

Posted by HawkFan23 on 10/1/2010 at 10:38 AM
Disregard last comment.... upside down message board
Posted by HawkFan23 on 10/1/2010 at 10:37 AM
No recent comments, but I'm still having the issue. Please fix this soon!
Posted by Microsoft on 10/1/2010 at 8:23 AM
Hi All,

We got a repro of the issue internally and were able to track down the issue. We are currently verifying the fix and then will work out how best to make it available to everyone.

-Azeem Khan
VS Debugger
Posted by Le Morre on 9/14/2010 at 1:02 PM
If any one has some code that can reproduce this behavior, plz upload it,. I cant cuz I only get this problem in a program that is extremly huge.
Posted by Juan Calero on 9/9/2010 at 4:36 AM
I experience this issue frequently (like 3-4 times in a day) debugging a .NET 4.0 WCF service with VS2010 in a Windfows 7 x64 machine
Posted by wisey_1 on 9/8/2010 at 3:10 AM
I am also experiencing this issue while debugging a .net 4 project, please also note this is not a Unit Test project. As I am stepping through the code it will randomly treat my click of step into or over as a continue, additionally when using break all to attempt to catch it and continue debugging this will simply result in my application hanging and debug to generally fall over.
Posted by codekaizen on 8/20/2010 at 3:09 PM
I experience the same problem as described by Christian V. I have experienced it, especially during unit test debugging, since VS 2010 Beta 2.

It's extremely hard to repro this issue, since it appears to happen randomly, although it seems to occur eventually, so time could be a component. It also seems to happen more frequently when using expressions in the Immediate window or viewing Watch variables. I have not been able to isolate a single set of circumstances which gives me a consistent case.

I've experienced it only on Win x64, both Ultimate and Pro SKUs.
Posted by JD_1234 on 8/19/2010 at 12:40 PM
I have been suffering from this problem ever since I installed VS2010 on a brand new Windows 7 installation. It seems to happen fairlty randomly - Sometimes consistently jumping, sometimes behaving itself for a while. It seems to happen a lot when debugging unit tests. I am using VS2010 Pro under Win 7/64bit. A colleague working on the same project is experiencing the same problem using a new install under Win 7 32bit.
Come on Microsoft - This problem puts us back 15 years as I have to put breakpoints on every line - Get it sorted!
Posted by MikeGCompass on 8/10/2010 at 5:26 AM
Just added an attachment of my VS 2010 ActivityLog.xml the most recent entries should be exactly at the time the issue occured. Not sure whether this is relevant:
442 Unexpected system error mode before loading package [Microsoft.VisualStudio.Debugger.PdtDebug]


Also in regard to previous post:
The last bit after "Here's some more info that could be relevant..." I don't see happening every time, this seems a more rare case, most of the time if I hit a breakpouint I can continue debugging afterwards.
Posted by MikeGCompass on 8/10/2010 at 4:17 AM
Hi,

We have the same issue here with VS 2010 Premium.

We have a .NET 4.0 unit test project, that is used to test a few .NET 2.0 assemblies in the same solution.

I have Win 7 64 but a co-worker has XP 32 bits and has the same issue.
I have powertools and coderush express installed but my co-worker doesn't.

It is VERY frustrating.

Shall I upload our entire solution for you and explain how to repro?

It doesn't happen every time, I would say that in 5 debugging sessions debugging the same code it happens once. The more involved the debugging the more likely it seems to happen!

So I'm guessing you'll struggle to repro this, I bet the code you already have will repro but only in certain circumstances.
I'm yet to figure out any common pattern as to when this breaks.

Here's some more info that could be relevant...

Once VS gets itself into this state of running code instead of stepping, if you have a breakpoint later on down the line it will be hit but then all further attempts to single step (f10) after this point do not single step, it's almost as if the code I'm debugging has changed from being "My Code" to "not my code" (Like when you try and step into some designer code marked with the <System.Diagnostics.DebuggerStepThrough()> attribute.

Posted by JF Filion on 7/22/2010 at 11:17 AM
I have the exact same problem as the one describe by Christian V. In my case, I ve tried on 2 different environments: On a VM and on my laptop. Exact same problem on both. This is very annoying and not productive.
This issue have been raised in may and still not workaround... All 7 members of my dev team have the same issue.
Posted by Christian V.1 on 7/22/2010 at 8:50 AM
I also am experiencing this issue from 2 different installation of VS2010.
The problem occurs when debugging (stepping over code) from a Unit Test project using the 4.0 framework.
In my case, stepping over code (F10) randomly gets interpreted as run to completion (F5).
This makes debugging a very unpleasant experience.
Posted by Le Morre on 7/21/2010 at 3:06 AM
Yes the same for me. Ive only experienced this problem while debugging unitests.
Posted by Microsoft on 7/6/2010 at 3:05 PM
Mathew,

Dbugging a unit test seems to be common from the folks we have heard from. However since we do not yet know the reason behind this, we cannot say for sure if it affects only debugging of unit tests. So far we have been unable to repro this issue on our end and haven't gotten a live repro from a customer.

If you can provide a repro that would be immensely helpful. Thanks.
Azeem Khan
VS Debugger Team.
Posted by Matthew Watson on 6/25/2010 at 3:40 AM
I've only been able to reproduce this while debugging code in a unit test. Could that be relevant?
Posted by Microsoft on 5/25/2010 at 9:16 AM
Hi Bob,

We have been trying to repro the issue without luck so far. Is it possible for you to provide a reduced repro that I can look at? Thanks.

Azeem Khan
VS Debugger Team.
Posted by bob_r1970 on 5/25/2010 at 8:55 AM
Clicking "Step Over" randomly appears to "Run" and may or may not stop at a break point. When this happens inside a for loop with a break set inside the loop it is not immediately apparent that the program stopped at a later iteration of the loop.
Posted by Microsoft on 5/19/2010 at 11:00 AM
Hi All,

The repro provided does not repro the stepinto/stepover becoming a Go/RuntoCompletion. If anyone has a repro that they can provide please provide it so that we can track down what is happening here.

Ravi - could you provide more details about watching variable issue. It sounds like there is a property that requires other threads to run or takes too long to complete results in a timeout. We will try and terminate the evaluation after the timeout and this can result in thread termination. You can read more about it at http://blogs.msdn.com/jmstall/archive/2005/03/23/400794.aspx.

Thanks for all your help folks.

Azeem Khan
VS Debugger Team.
Posted by Matthew Watson on 5/11/2010 at 9:23 AM
This also happens to several of our programmers, but it happens with .Net 4.x projects rather than 3.5
Posted by Ravi Bhavnani on 5/11/2010 at 7:24 AM
I did some more testing and found that if an additional breakpoint is set further down the line, execution sometimes (but not always) proceeds as expected. It's as if the debugger misbehaves if it has passed the last breakpoint. FYI, this issue occurs when debugging a large solution (55 projects); hence I'm unable to attach any sample code with this bug report.

Another problem I've noticed (which didn't exist in VS2008 and earlier) is when I'm paused at a breakpoint (e.g. examining some variables), the debugger thread eventually detatches itself from my session, rendering my watch window useless - the watched variable seems to no longer be bound to the debugger. This makes it difficult to debug non-trivial bugs where one may need to inspect variables for an extended period of time.
Posted by Microsoft on 5/10/2010 at 11:14 PM
Thanks for your feedback. We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 5/4/2010 at 11:37 PM

Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Could you please attach a zipped project file to this feedback through our site to help us reproduce the issue?

Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Posted by Microsoft on 5/4/2010 at 4:05 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement