Home Dashboard Directory Help
Search

Debugger randomly treats "step-into" and "step-over" as "run to completion" by Charles Sterling


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


21
0
Sign in
to vote
Type: Bug
ID: 663614
Opened: 4/20/2011 9:27:30 AM
Access Restriction: Public
0
Workaround(s)
view
17
User(s) can reproduce this bug

Description


The VS2010 (Premium) debugger randomly treats "step-into" and "step-over" commands as "run to completion" when debugging a .NET 3.5 assembly.

Refiling issue from old system:
https://connect.microsoft.com/VisualStudio/feedback/details/556756/debugger-randomly-treats-step-into-and-step-over-as-run-to-completion#tabs

Pioneer Issue
517446
Details
Sign in to post a comment.
Posted by Christiansei on 8/27/2012 at 8:39 AM
Hi Microsoft,
I had the hope for Visual Studio 2012 to fix this annoying bug. I installed the final version now, but the problem still exists.
Is there anyone willing to solve this bug at least in the newest version?

I read in a similiar thread concerning unit test, that there is a workaround:
(https://connect.microsoft.com/VisualStudio/feedback/details/757483/debugging-assembly-with-code-coverage-enabled-doesnt-work-as-expected)

Is there a releation to this bug, even as we do not debug unit tests?

Regards,
Christian
Posted by Christiansei on 6/20/2012 at 5:15 AM
Hi,
I've downloaded Visual Studio Premium 2012 RC and tested our projects:
The problem still happens. It seems that it occurs less often but it still occurs!

Christian
Posted by Dragon Ace on 6/12/2012 at 5:28 AM
Hi Christiansei,

We use SqlServer 2008, both on the machines that work correct as well as on the machine on which the problem is occurring.


Hi Marc,

We were debugging native code. The code was not using any unmanaged code I'm aware off, but the code we were debugging was doing WCF calls. Could this be the source of the problem, that we were getting some low level exceptions ?
Posted by Microsoft on 6/7/2012 at 6:31 PM
Hello Dragon Ace,

For exceptions, if you're doing managed debugging and you hit a native exception (exception in a native component you rely on or worse, an exception in the CLR itself), that could cause the managed code to unwind in unpredicable ways leading it to seem like a step/go bug as the managed debugger cannot catch native exceptions (and vice versa). I was also curious about ecxeptions in case there were a problem where the step was going through a managed exception and we weren't correctly ending up in a catch block somewhere else.

With exceptions, there is also the possibility that if you have JMC on, you end up on a code path that never comes back to user code and so we will run the program to exit.

Marc
Posted by Christiansei on 6/6/2012 at 1:40 AM
Hi Dragon Ace,
do you have sqlserver 2008 or sqlserver 2008r2 installed on the machine on which the problems occur?
We have serval installations of VS2010 SP1, but the problem only occurs on these machines having a SQLServer installation as well.

Christian
Posted by Dragon Ace on 6/5/2012 at 2:47 AM
Hi,

At the moment there is only one machine that is giving problems with stepping, so I don't believe that the code I'm stepping through is the problem. Also the issue is very reproducible but random and not specific to a certain point in the code.

I did not see any exceptions while stepping on the machine described below. Can there be exceptions that i cannot see when debugging, but will mess up the stepping? if so is there a way that these exceptions can be logged?

Posted by Microsoft on 6/1/2012 at 3:05 PM
Hello everyone,

If you still have a consistent repro for this, can you please try one of the following (in priority order):
1. Please try this on the Dev11 RC made available this week and let me know if the problem still persists.
http://www.microsoft.com/visualstudio/11/en-us/downloads#vs
2. Try to get a simple repro that you're willing to share and send it to marcpop@microsoft.com
3. If you don't have a simple repro you can share, contact me and/or Chuck Sterling. We can then give you a logging version of the debugger that will give us some deeper information on what your program is doing.

Note that option 3 is the worst option as we have yet to find a case where we had enough information to track down what was going on. A few of the cases we've run into of this turned out to be exceptions in the application causing unpredictable stepping behavior.

Getting us a small repro we can investigate is really the best option here as stepping issues like this one are very difficult to track down otherwise.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Dragon Ace on 5/29/2012 at 6:39 AM
Hi,

I'm seeing this behavior on:

Windows Server 2008 R2 Standard with Service Pack 1 and all updates installed
Visual Studio 2010 SP1 and all updates installed

Only catch is that it is running as a Virtual Machine in Virtual Box.

Step-over and step-into are randomly treated as continue when debugging locally on the box.
Posted by alderschwede on 4/19/2012 at 5:27 AM
Todd.Wilder said he can help reproducing the issue and that it is really easy to reproduce. Maybe you can contact him.
https://connect.microsoft.com/VisualStudio/feedback/details/556756
Posted by JackcaJ on 3/23/2012 at 11:01 AM
Still happening! All the time! When debugging Win or Web projects. I click F11 or F10, instead, it runs to completion. I cannot begin to tell how much time (and nerves) i wasted due to this problem!
Posted by Microsoft on 2/8/2012 at 5:14 PM
Since this has been inactive, we are shutting down this bug. If there is a customer out there who is able to share a live repro, please respond as we would like to see it.

Thanks,
Visual Studio Debugger Team
Posted by Microsoft on 12/19/2011 at 1:05 PM
Hello AndreAlvesLima,

As with the other two, if you're willing to try out some logging binaries, please email me directly and I'll get access to a secure share with the private binaries that will collect logs. This is a long and iterative process and we've been working with Andre so far to determine what's happening in his scenario by looking at the logs with no luck so far.

If anyone has an actual application that reproduces the problem that they are willing to share with Microsoft, that would be even better than having to work with you to log information about what the debug engine is doing.

Note that almost all of us are out until January so I may not reply again until then.

Marc Paine
Visual Studio QA Lead
Posted by AndreAlvesLima on 12/15/2011 at 2:21 AM
I am also having the exact same issue... It looks like that it only happens during unit test debugging... I already tried reinstalling SP1, disabled property evaluation, disabled Just My Code, changed all projects in my solution to build in x86... None of these (neither all of them together) solved the issue... It is really boring to debug unit tests like this...
Posted by Microsoft on 12/6/2011 at 11:46 AM
Hello Odsh77,

It sounds like your issue is likely a timing out functional evaluation. Can you try disabling "Enable property evaluation and other implicit function calls" from the tools->options->Debugger->General settings page and see if that helps? You can take a look at the two links I sent to Christiansei and Andre about possible issues with function evaluations.

The 2008 problem was very specific to complex multi-threaded applications where we would get multiple simulaneous debug events and not handle them properly at all. We are fairly confident that the 2008 SP1 issue is not in 2010 as that issue was very prevalent.

You are also welcome to contact me at marcpop@microsoft.com if you wish to try collecting debugging logs for us to try to track down what's going wrong. Of course, if it is a timing out function evaluation, the logs wouldn't help as the only solution would be to track down which complex watch you have that's the problem and removing it.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Odsh77 on 12/6/2011 at 7:04 AM
One more thing comes to my mind: we had exactly the same kind of problem in VS2008, and if I remember correctly, the following hotfix corrected the problem: http://support.microsoft.com/kb/957912
Posted by Odsh77 on 12/6/2011 at 6:55 AM
Hello,

I'm also experiencing this bug, i.e.:
1) I hit F10 (Step over)
2) VS becomes nonresponsive for a few seconds
3) When VS recovers, it's just as if I had made an F5 (Continue)

Maybe this will help: in my case, it seems to happen more often when I have complex watches, for example when watching a specific element in nested arrays. I can also trigger the bug simply by inspecting such an object through mouse-over (in which case I don't even need to hit F10).
Posted by Microsoft on 12/2/2011 at 6:22 PM
Hello Chirstiansei and Andre,

Thanks for the detailed replies. If either of you is willing to try out some debugger binaries that will help us log information about what's going on in the debugger while running your application, please send me your contact info to marcpop@microsoft.com. I can then give you access to a secure share with the private binaries and the instructions on how to collect the logs.

Andre, for your particular issue with stepping, you're hitting F10 on one thread, get switched to another thread, and then switched back? Do you know if there is a breakpoint or exception on the second thread? There can sometimes be confusing behavior where you're stepping on one thread and hit a stop event on another thread (breakpoint, exception, etc). In this case, the first thread is still waiting to complete the step so as soon as you continue on the second thread, we bring you back to the first. This is intentional behavior assuming you hit a correctly expected event on the second thread.

Christian, do you only hit the step/go bug after you see the VS hang during the mouse-over? If that's the case, it's very possible you're hitting a func eval time-out issue that's putting the debuggee in a bad state. Take a look at more details on func eval issues on the below blogs:
http://blogs.msdn.com/b/jmstall/archive/2005/03/23/400794.aspx
http://blogs.msdn.com/b/greggm/archive/2004/02/04/67766.aspx

Either way, if you two get me your contact info, we can get the logs for the debugging sessions when you hit this and try to confirm the situation you're running into. Thanks again.

Marc Paine
Visual Studio Debugger QA Lead
Posted by -Andre- on 11/26/2011 at 3:02 AM
Hi Microsoft Folks,

Some additional informations from Christian's team:

The developer with the desktop PC have a Quad-Core CPU from Intel, all others a Intel Core 2 Duo.

As Christian said, that the problem often occures while debugging multithreads, I have the following problem:
If I'm switching the thread while debugging for a few times without pressing F10 or something like that, it seem's that the debugger don't know on which thread I am, because if I'm stepping through the code with F10, it steps to next row and after the next push it switch the thread and steps there to the next row. This goes as long as I'm debugging for this time, after Running and debugging again it goes right. And yes the "ron to completion" occures there too.

Regards,
Andre
Posted by Christiansei on 11/24/2011 at 1:44 AM
Hi Marc,
this is the situation in our team:

-Does it happen every time for you?
Not every time, but very often if we're stepping long running functions and often when there are other threads running.

-Does the Just My Code being on or off affect whether you hit this?
No, it doesn't affect the problem.

-Are you doing mixed managed + native debugging or just managed debugging (and does switching affect the behavior)?
We are just debugging managed code and also switching doesn't affect the problem

-Do you see any exceptions being fired (check the output window for the exception)?
No, there is no exception in the output window after the problem is occurred.

-Do you see this only when debugging unit tests or all the time (the original issue would almost entirely happen while debugging a unit test)?
It happened in both, but when debugging unit test the problem occurs more often.

-Is your application running as x64 or x86?
The application is running in both, but we are only debugging in x86.

-Are any of you able to try the Developer Preview from September to determine if the issue still shows up in that release?
No.

Some additional Information:
One developer of our team is working with a desktop pc (intel), the others are working with laptops (all intel cpu).
An interesting fact is that the one with the desktop pc don't have the debugging problem as strong as the others, only about on time in on month.
But we are all working with the same version of Visual Studio (2010 Premium) and Windows 7 64bit

Sometimes while debugging and watching some properties etc. with the "mouse over tool", VS is hanging and after that, the debugger start running without pressing F5 or some Buttons and ignore all breakpoints.

Regards,
Christian
Posted by Microsoft on 11/11/2011 at 5:53 PM
Hello All,

Sorry for the slow reply as the connect tool internally was failing to notify me of additional comments to this bug. We have been working with a couple of premier customers the last few months through our support team to try to track this down. Unfortunately, none of those investigations have panned out into a real issue. One customer didn't get back to us, another was hitting an exception like Marcus H, and a third was doing mixed mode debugging which we're still trying to track down details from.

I have a few additional questions for those of you still hitting this. Does it happen every time for you? Does the Just My Code being on or off affect whether you hit this? Are you doing mixed managed + native debugging or just managed debugging (and does switching affect the behavior)? Do you see any exceptions being fired (check the output window for the exception)? Do you see this only when debugging unit tests or all the time (the original issue would almost entirely happen while debugging a unit test)? Is your application running as x64 or x86? Are any of you able to try the Developer Preview from September to determine if the issue still shows up in that release?

I'm currently working with our support team to find out if we can provide binaries to collect logs more broadly that just official support requests. If any of you are already premier customers and willing to work with us collecting log files, please start a premier support request.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Marcus H on 11/1/2011 at 9:12 AM
...the error below was of course that an exception was thrown and Visual Studio did not catch it as I expected. To make Visual Studio break on exceptions see this article: http://msdn.microsoft.com/en-us/library/d14azbfh.aspx
Posted by Marcus H on 10/29/2011 at 7:04 AM
I found a solution for this issue in my code. I had an unassigned "List<MyClass> List" member variable that I called List.Add(new MyClass) on. Correcting this error in my code solved the problem.

Note: Reinstalling VS did not help, nor upgrading to VS 11.
Posted by PatEnns on 9/2/2011 at 12:27 AM
The issue is still active...
Posted by joshcohen on 8/24/2011 at 8:30 AM
Any update on this issue? It is a significant hassle.
Posted by EcologicalModelling on 8/2/2011 at 12:47 AM
My boss wants his AUD$1,175.00 back as we haven't been able to use this software since we bought it. DOA bug still not fixed
Posted by EcologicalModelling on 7/19/2011 at 9:55 PM
Hello Microsoft, anyone home? 14 months after posting this DOA bug, it's still not fixed!!
Posted by giopebero on 6/30/2011 at 7:18 AM
Hi,

I have the same issue when debugging a C# .NET 2.0 assembly. It randomly behaves correctly , while it normally treats "step-into" and "step-over" as "run to completion". I hope that you'll fix this problem urgently.

Regards,
Giovanni
Posted by Christiansei on 6/29/2011 at 1:20 AM
Hi,
are there any news regarding this problem here? This problem was reported in May 2010 and since we're waiting for a solution.
I can't believe that this bug was fixed in SP1. All of our developers facing this problem on different machines and all of them do have SP1 installed.
Does anybody pay attention on this at Microsoft? We consider more and more to take steps for reinstalling VS2008.

Regards,
Christian
Posted by EcologicalModelling on 6/7/2011 at 7:13 PM
Still geting this problem even though Microsoft's solution is to just repost the bug. 3 months after purhasing VS10 I still can't use it and am relying on VS2003! No wonder Microsoft's share price is in the toilet!

cpde.dll 10.0.40219.1
x86\msvsmon.exe - 10.0.40219.1
x64\msvsmon.exe - 10.0.40219.1

Windows 7 64 Ultimate Service pack 1
Posted by Bsmithza on 5/17/2011 at 6:07 AM
I was also getting this issue while debugging locally with VS 2010 Ultimate SP1 on XP SP3. Here are my file versions
cpde.dll - 10.0.31118.1
msvsmon.exe - 10.0.31118.1
But I found that after re-installing SP1 the problem did not occur again. I checked and the file versions didn't change either. So its a possible workaround, but I will see if it occurs again. Previously restarting visual studio didn't help.

Posted by BitterMinion on 5/6/2011 at 11:27 AM
I'm experiencing the same issue while debugging locally with VS 2010 Professional SP1 on 64-bit Windows 7 Professional.

cpde.dll - 10.0.40219.1
x86\msvsmon.exe - 10.0.40219.1
x64\msvsmon.exe - 10.0.40219.1
Posted by Ray Riopel on 4/28/2011 at 6:10 AM
1. I am debugging on 64-bit - Windows Server 2008 R2.
2. I'm debugging locally using devenv.exe.

cpde.dll - 10.0.40219.1
x86\msvsmon.exe - 10.0.40219.1
x64\msvsmon.exe - 10.0.40219.1
ia64\msvsmon.exe - 10.0.40219.1
Posted by Christiansei on 4/26/2011 at 12:05 AM
Hi,
I've applied VS 2010 SP1 and the issue still occurs.
File Versions:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\cpde.dll - 10.0.40219.1

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe - 10.0.40219.1
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64 - 10.0.40219.1
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\ia64 - 10.0.40219.1

Christian
Posted by Microsoft on 4/22/2011 at 4:07 PM
Hi Folks,

For those running into this issue please provide the file versions of cpde.dll and msvsmon.exe (for both x86 and x64 versions). cpde.dll is located at %programfiles%\microsoft visual stuiod 10.0\common7\packages\debugger.

Thanks.
Azeem Khan
Posted by Microsoft on 4/20/2011 at 6:14 PM
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)
Posted by Charles Sterling on 4/20/2011 at 11:57 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?



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

Thanks
Charles Sterling
Sign in to post a workaround.