1

I am starting to get really frustrated with the Visual Web Developer Express Debugging.

edit - This is mostly regarding debugging C#

It seem often I set two or three break points. And what happens is the cursor ends up going around in a loop. I will have been through all of my breakpoints but instead of exiting the debugging and showing me the result of the web page in the browser the cursor jumps back to the beginning.

Or I will be half way through my break points and the cursor will jump back to the previous breakpoint and and get stuck in a loop, again always jumping back to the previous break point.

It seems the debugger is not consistent either sometimes it will work fine and other times it will do as described above.

Sometimes I get a yellow arrow with a tiny blue dot in the margin when this is happening. Which when I hover over it says "The process or thread has changed since the last step" what is that all about?

Also I am getting inacurate Exceptions. I have a method in C# that takes an out parameter. When the cursor reaches this method call sometimes it gives me a null reference exception. But it is an out parameter they are allowed to be null. And again VWD seems to be inconsistent. Sometimes I get this problem, most of the time I don't.

Am I doing something wrong or has VWD Debugger got a lot of screws loose?

Please help me because I am starting to use my mind!

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Duncan Gravill
  • 4,552
  • 7
  • 34
  • 51
  • Are you debugging optimized code? Are you sure your source matches the binary? Is this code in Release mode? BTW, this is the same debugger used across Visual Studio. – John Saunders Oct 20 '11 at 20:58
  • ooops! Sorry, didn't see the c# tag. – Pete Wilson Oct 20 '11 at 20:59
  • 4
    Seems your debugging multi threads, or the page is getting loaded over and over, try doing some trace / logging, that might give you an idea. – Orn Kristjansson Oct 20 '11 at 21:01
  • John - Thanks for the info. The code is not optimized. I'm pretty sure my source matches the binary although I'm not completely sure what you mean by that. I have compiled the source pre debugging and the dll is included in the solution and the website project's bin folder. Also I have ` – Duncan Gravill Oct 20 '11 at 21:14
  • om - Thanks for that help. I don't know what trace logging is but I shall look it up. The code I am debugging is a custom http module that provides basic authenticaion. It subscribes to 3 events in the pipeline, BeginRequest, AuthenticateRequest and AuthoriseRequest. The delegates for both BeginRequest and AuthenticateRequest implement code that then calls to the same method in an instance of another class. I know this should make the debugger cursor go through the same code twice but it is more than that, it loops many times. – Duncan Gravill Oct 20 '11 at 21:25
  • 8
    In the future, you will probably get better results if you ask questions that are phrased as *questions* rather than as *rants*. "What can cause unexpected breakpoint and stepping behaviour in Visual Studio?" is a lot more likely to solicit a helpful reply than "Is the debugger full of bugs?" – Eric Lippert Oct 20 '11 at 21:32

2 Answers2

15

My suspicion is that you have many threads running concurrently in the same code. When you put a breakpoint down, that breakpoint applies to all the threads, not just the one that was running when you made it. If you hit "go" and another thread starts running, and it hits the breakpoint first, that's the thread that you're now debugging. It can be very confusing.

What I do when I'm in that scenario -- and I am in that scenario every single day, believe me -- I get in the habit of always freezing every thread but the one I am actually wanting to debug. That way the program is effectively single-threaded while I am debugging it. Just don't forget to thaw them out!

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • Good advice, with the caveat that this technique can get very cumbersome if the threads do a lot of locking on shared resources. Freeze n-1 threads, step until you hit a deadlock, find the thread that's holding the lock, thaw it and freeze the thread you were debugging, step until it's out of that lock, freeze it again, thaw the original thread, repeat until your eyes glaze over :) – Kennet Belenky Oct 20 '11 at 21:36
  • Thanks for you help Eric. I don't understand how there can be more than one thread running though. I am running an MVC web app. I click run just once how can I now have multiple threads? – Duncan Gravill Oct 20 '11 at 22:24
  • @FunkyFresh84: Does clicking "Run" execute code that spawns multiple threads? If so, then you've got multiple threads. I would open up the "threads" window in the debugger and look carefully at what every thread is doing. Are there multiple threads in what looks like your code? – Eric Lippert Oct 20 '11 at 22:49
  • The Parallel Stacks window in VS2010 is very helpful for this sort of scenario, because it shows you exactly what's going on (much better than the Threads window). I'm not sure the Express version has that, though. – configurator Oct 21 '11 at 14:24
  • If you know what thread you want to stop in, you can right-click the breakpoint, choose Filter, and say `ThreadId = (the thread id)`, instead of freezing all other threads. Might work better in locky scenarios. – configurator Oct 21 '11 at 14:36
5

It is most likely something peculiar to you or your code.

I've been using Visual Studio 2010's debugger frequently for the last 18 months. Before that, I consistently used Visual Studio's C# debugger all the way back to the original Visual Studio .Net release. I have never found any major bugs. Most times I thought I found a bug, there was actually a flaw in my understanding, or my code.

Take the time to understand what is happening, and what the icons and indicators mean, and how to operate the debugger and you will most likely find:

  1. VWD is working correctly.
  2. Your code isn't.
  3. A greater understanding of programming.

As a habit of mind, I would encourage you to research "select isn't broken".

Here are the specific things that make me think that your understanding is lacking:

  1. You say "when the cursor reaches this method call..." This is incorrect phrasing to describe the situation. The method is invoked when the cursor steps into or over the method call. If the cursor is only on the method call, that method hasn't executed yet.
  2. How do you know the out parameter is giving you the trouble? If you are invoking the method on an object, perhaps your reference to the object is null?
  3. Inconsistent debugger behavior can actually be consistent reporting (by the debugger) of inconsistent program code.
  4. Your phrasing and description in the second and third paragraphs is imprecise, and not helpful to anyone who hasn't seen your specific debugging setup.

In short, yes, you do feel like you're losing your mind. I sympathize. That feeling never goes away, but the discomfort means your brain is getting bigger. Keep trying, but it would behoove you to learn more about how a debugger works. Spend more time stepping through code that does work properly.

Edit: You don't mention how you step through the code. Only that the breakpoints are being hit (in an order you don't agree with). Learn about the step-in, step-over, step-out and run-to-cursor commands in VWD. Because you're running this as part of a website, those may not be enough. You may be servicing simultaneous requests without realizing it. This will cause execution to alternate between threads in a seemingly random sequence as the breakpoints are hit. Make sure you're only serving one request at a time, or at least pay attention to your thread ids.

Kennet Belenky
  • 2,755
  • 18
  • 20
  • If I could upvote this twice, I would. – Andrew Barber Oct 20 '11 at 21:36
  • Thanks for you reply Kennet! Firstly I am trying to learn the correct phrasing and terminology as I understand how important this is in communicating, however I am entirely self taught and I am still learning. Secondly I don't really get what you mean by research "select isn't broken". Your point 2 is correct by the way, the out parameter was not the problem. I thought it was because the little red underscore was next to it and when I hovered over it intellisense said it was null. But then I went back and hovered over the object I was invoking on and it sure enough was null. – Duncan Gravill Oct 20 '11 at 22:09
  • Also I understand step-into, step-over, step-out and run-to-cursor comands. I don't really see how adding in details about how I steped through the code would have helped though. As I understand it the bottom line is they all move through the code in one direction. So they don't help to explain why I end up jumping back to the beginning or getting stuck in a loop. Also where do I find the thread IDs? – Duncan Gravill Oct 20 '11 at 22:19
  • We're all still learning. I've been doing this professionally for almost 15 years and still occasionally bang my head against the wall. "Select is not broken" is a reference to the book "The Pragmatic Programmer" (http://pragprog.com/the-pragmatic-programmer). Programmers love to point fingers, but 99 times out of 100, when you find a bug, it's your own fault. – Kennet Belenky Oct 20 '11 at 22:30