Why debugging in VS2010 sucks today...
-
Yes, it's all my code (with no debugger attrs); I've debugged the same code in VS2008 with no problems (also via remote desktop). I can understand keystrokes sometimes being lost in transmission, but this is happening too often, and only during debugging. I just noticed another weirdness - sometimes double-clicking in the Call Stack window (to navigate to a previous frame) mangles the contents of the window, causing me to have to manually navigate to the location where execution is paused. My VS2010 install completed without errors and my machine is otherwise very stable and has all updates applied. I have no problems with any other app or tool. Very strange. :( /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Strange indeed. I have not seen either of those issues occur, and I have been using VS2010 since Beta 2 was released (now running RTM).
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
Strange indeed. I have not seen either of those issues occur, and I have been using VS2010 since Beta 2 was released (now running RTM).
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Hmm, I'm beginning to think I may have bad RAM in my box (although I haven't encountered problems with any other software). I was paused at a breakpoint in method
A.foo()
at a call toB.bar()
. When I attempted to step intoB.Bar()
, control was transferred to the middle of a method that is 2 call frames belowB.Bar()
. I have several disabled breakpoints in existence, but none match the location to where control was transfered! Strange... /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Hmm, I'm beginning to think I may have bad RAM in my box (although I haven't encountered problems with any other software). I was paused at a breakpoint in method
A.foo()
at a call toB.bar()
. When I attempted to step intoB.Bar()
, control was transferred to the middle of a method that is 2 call frames belowB.Bar()
. I have several disabled breakpoints in existence, but none match the location to where control was transfered! Strange... /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
When I attempted to step into B.Bar(), control was transferred to the middle of a method that is 2 call frames below B.Bar()
That's just damn weird :doh: I'm guessing there are still bugs in VS2010 that need addressing. Perhaps you should report these to Microsoft?
\
_\,,
"-=\~ _
\\~___( ~
_|/---\\_
\ \
Unicorn. -
Hmm, I'm beginning to think I may have bad RAM in my box (although I haven't encountered problems with any other software). I was paused at a breakpoint in method
A.foo()
at a call toB.bar()
. When I attempted to step intoB.Bar()
, control was transferred to the middle of a method that is 2 call frames belowB.Bar()
. I have several disabled breakpoints in existence, but none match the location to where control was transfered! Strange... /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
I get some pretty weird behaviour if I have multiple files with the same name (in different projects in the same solution) Breakpoints randomly think they belong to the other file.. and weird things happen when they think that and the location at which they would be is not a breakable point Not as weird as what you describe though
-
I get some pretty weird behaviour if I have multiple files with the same name (in different projects in the same solution) Breakpoints randomly think they belong to the other file.. and weird things happen when they think that and the location at which they would be is not a breakable point Not as weird as what you describe though
Amazing - I was just about to post a reply about something similar! I find if I have only one document visible at any time (i.e. tabbed mode with only one tab group displayed), things appear to work fine. The moment I fake MDI by displaying two documents (my preferred mode of working until VS2010 nixed MDI) things tend to go haywire. It's possible that the UI is causing breakpoint associations to get munged. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Hmm, I'm beginning to think I may have bad RAM in my box (although I haven't encountered problems with any other software). I was paused at a breakpoint in method
A.foo()
at a call toB.bar()
. When I attempted to step intoB.Bar()
, control was transferred to the middle of a method that is 2 call frames belowB.Bar()
. I have several disabled breakpoints in existence, but none match the location to where control was transfered! Strange... /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Out of curiosity, have you tried the following: 1. Perform a "Clean Build" 2. Shutdown Visual Studio and physically delete all /bin/* and /obj/* folders 3. Delete the .suo file for the solution Some of the behavior you just described sounds like a mismatch between the .pdb files and the object files used for debugging. Try these steps and then try your debug session again and see if you get better results.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
I get some pretty weird behaviour if I have multiple files with the same name (in different projects in the same solution) Breakpoints randomly think they belong to the other file.. and weird things happen when they think that and the location at which they would be is not a breakable point Not as weird as what you describe though
Try the steps I mention here[^] and see if you get better behavior.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
OK, I never thought I'd write a post about why something sucks, but I'm fast losing patience with VS2010. For all its shiny chrome and (admittedly cool) "Call Hierarchy" and "Navigate To" commands (something Eclipse has had for at least 7 years :)) what good is an IDE if the debugger randomly interprets a "Step Out" and "Step Over" as a "Run"!? I'm debugging a suite of .NET smoke test projects (stuff I've done reliably and without pain in all previous VS versions since .NET 1.1) and have reached a breakpoint in a suspect method. Stepping statement by statement in the method sometimes causes the IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line. Anyone else experience this? I'm unable to find references to this madness on the web. (FWIW, I'm debugging over remote desktop, but that shouldn't matter.) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Time to buy that new keyboard :)
SG Aham Brahmasmi!
-
OK, I never thought I'd write a post about why something sucks, but I'm fast losing patience with VS2010. For all its shiny chrome and (admittedly cool) "Call Hierarchy" and "Navigate To" commands (something Eclipse has had for at least 7 years :)) what good is an IDE if the debugger randomly interprets a "Step Out" and "Step Over" as a "Run"!? I'm debugging a suite of .NET smoke test projects (stuff I've done reliably and without pain in all previous VS versions since .NET 1.1) and have reached a breakpoint in a suspect method. Stepping statement by statement in the method sometimes causes the IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line. Anyone else experience this? I'm unable to find references to this madness on the web. (FWIW, I'm debugging over remote desktop, but that shouldn't matter.) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Amazing - I was just about to post a reply about something similar! I find if I have only one document visible at any time (i.e. tabbed mode with only one tab group displayed), things appear to work fine. The moment I fake MDI by displaying two documents (my preferred mode of working until VS2010 nixed MDI) things tend to go haywire. It's possible that the UI is causing breakpoint associations to get munged. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
I haven't installed vs.net 2010 yet but you say it doesn't do MDI anymore??? I hope that's not the case. That's the only mode I like to work in. I always have multiple windows open and visible.
-
OK, I never thought I'd write a post about why something sucks, but I'm fast losing patience with VS2010. For all its shiny chrome and (admittedly cool) "Call Hierarchy" and "Navigate To" commands (something Eclipse has had for at least 7 years :)) what good is an IDE if the debugger randomly interprets a "Step Out" and "Step Over" as a "Run"!? I'm debugging a suite of .NET smoke test projects (stuff I've done reliably and without pain in all previous VS versions since .NET 1.1) and have reached a breakpoint in a suspect method. Stepping statement by statement in the method sometimes causes the IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line. Anyone else experience this? I'm unable to find references to this madness on the web. (FWIW, I'm debugging over remote desktop, but that shouldn't matter.) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
IIRC, VS2008 had a similar problem they corrected with a hotfix. Maybe they broke it again?
Software Zen:
delete this;
Fold With Us![^] -
OK, I never thought I'd write a post about why something sucks, but I'm fast losing patience with VS2010. For all its shiny chrome and (admittedly cool) "Call Hierarchy" and "Navigate To" commands (something Eclipse has had for at least 7 years :)) what good is an IDE if the debugger randomly interprets a "Step Out" and "Step Over" as a "Run"!? I'm debugging a suite of .NET smoke test projects (stuff I've done reliably and without pain in all previous VS versions since .NET 1.1) and have reached a breakpoint in a suspect method. Stepping statement by statement in the method sometimes causes the IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line. Anyone else experience this? I'm unable to find references to this madness on the web. (FWIW, I'm debugging over remote desktop, but that shouldn't matter.) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
I have had this sort of thing happen with VS2008, and not just in test code.
Fight Big Government:
http://obamacareclassaction.com/
http://obamacaretruth.org/ -
I haven't installed vs.net 2010 yet but you say it doesn't do MDI anymore??? I hope that's not the case. That's the only mode I like to work in. I always have multiple windows open and visible.
Yes, unfortunately they nixed MDI. It's also my preferred mode of working. Thankfully, you can have multiple windows open (tiled horizontally or vertically) but it requires a couple of extra mouse clicks to do this. Unfortunately, the (apparently) buggy debugging makes this feature useless. :( /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Ravi Bhavnani wrote:
IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line
Are you sure Visual Studio 2010 is out of beta? :doh:
Theoretically, it is. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Out of curiosity, have you tried the following: 1. Perform a "Clean Build" 2. Shutdown Visual Studio and physically delete all /bin/* and /obj/* folders 3. Delete the .suo file for the solution Some of the behavior you just described sounds like a mismatch between the .pdb files and the object files used for debugging. Try these steps and then try your debug session again and see if you get better results.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Yes, that was the first thing I tried. I was hoping it was a .pdb mismatch. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
IIRC, VS2008 had a similar problem they corrected with a hotfix. Maybe they broke it again?
Software Zen:
delete this;
Fold With Us![^]Interesting. I never experienced this in pre-VS2010. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
OK, I never thought I'd write a post about why something sucks, but I'm fast losing patience with VS2010. For all its shiny chrome and (admittedly cool) "Call Hierarchy" and "Navigate To" commands (something Eclipse has had for at least 7 years :)) what good is an IDE if the debugger randomly interprets a "Step Out" and "Step Over" as a "Run"!? I'm debugging a suite of .NET smoke test projects (stuff I've done reliably and without pain in all previous VS versions since .NET 1.1) and have reached a breakpoint in a suspect method. Stepping statement by statement in the method sometimes causes the IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line. Anyone else experience this? I'm unable to find references to this madness on the web. (FWIW, I'm debugging over remote desktop, but that shouldn't matter.) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Never happened to me, but that's the beauty of VS2008: personalized bugs noone else canreproduce.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server.Are you debugging .NET 3.5 assemblies? (BTW, other Connect members are also able to repro this issue). /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
OK, I never thought I'd write a post about why something sucks, but I'm fast losing patience with VS2010. For all its shiny chrome and (admittedly cool) "Call Hierarchy" and "Navigate To" commands (something Eclipse has had for at least 7 years :)) what good is an IDE if the debugger randomly interprets a "Step Out" and "Step Over" as a "Run"!? I'm debugging a suite of .NET smoke test projects (stuff I've done reliably and without pain in all previous VS versions since .NET 1.1) and have reached a breakpoint in a suspect method. Stepping statement by statement in the method sometimes causes the IDE to think I pressed "Run" (i.e. run to completion) which causes the test to continue running until it eventually fails down the line. Anyone else experience this? I'm unable to find references to this madness on the web. (FWIW, I'm debugging over remote desktop, but that shouldn't matter.) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Did you have any of the betas running on that machine?
But fortunately we have the nanny-state politicians who can step in to protect us poor stupid consumers, most of whom would not know a JVM from a frozen chicken. Bruce Pierson
Because programming is an art, not a science. Marc Clifton
I gave up when I couldn't spell "egg". Justine Allen -
Did you have any of the betas running on that machine?
But fortunately we have the nanny-state politicians who can step in to protect us poor stupid consumers, most of whom would not know a JVM from a frozen chicken. Bruce Pierson
Because programming is an art, not a science. Marc Clifton
I gave up when I couldn't spell "egg". Justine AllenNo. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com