views:

468

answers:

5

Hi there,

Since upgrading to 2008 I and many people here have noticed that randomly VS will no longer step in to code or jump over breakpoints. Its got to the stage where debugging is becoming a real chore. We are running SP1 but noticed problem on 2008 basic too.

In ref to Robert's question: We host WCF and Remoting services inside windows services. Essentially the calls from the clients (generally windows exe) will end up in a thread on the service itself and in our code (as opposed to remoting or WCF infrastructure). Once in our code the break points have this behaviour.

Much of the debugging we do here is in service code so ATTACH to process to invaluable and sometimes is impossible to get to the state needed except by attaching to processes after they have started. It happens to developers both with extensions such as resharper and to those who run a vanilla VS.

Looking on google doesn't give much help.

Anyone else experience this?

regards, Preet

+2  A: 

Yes, when I forgot to swich from RELEASE to DEBUG. ;)

Allways drives me crazy before I realise my stupidity.

Stefan
+2  A: 

Some things to check:

  • Are your PDB in the same directory as your application dlls?
  • Are they Debug builds?
  • Also is the path to the source different?
  • Do the Dlls load when you attach (check the output console)?
  • Do the break point appear as a hollow (not filled in) circle in VS? If so, hover over the breakpoint and it will tell you why it can't set the break point.

Perhaps as a work around you can start the service from within VS. If you change the application to a console app, and add a main method that calls the OnStart method (just as the windows service would). You can still install the app as a Windows service as well as run it directly from VS:

public static void Main(string[] args)
{
    if (Environment.UserInteractive)
    {
        Console.WriteLine("Starting service...");
        Service1 svc = new Service1();
        svc.OnStart(args);
        Console.WriteLine("Started");
        Console.WriteLine("");
        Console.WriteLine("Press any key to stop");
        Console.Read();
        Console.WriteLine("Stopping...");
        svc.OnStop();
        Console.WriteLine("Stopped, Press any key to exit");
        Console.Read();
    }
    else
    {
        ServiceBase.Run(new Service1());
    }
}
Robert Wagner
Yep, yep, nope, yep, no. All ok. The first breakpoint will fire ok but then step in may fail, or may work. Then another BP will not be stopped at, or may.
Preet Sangha
+1  A: 

We saw BP issues with SP1. We reported it to Conenct (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363453) and MS has since sent us a DLL to fix it (seems to work). I expect MS will release a patch soon.

Since you has issues w/o SP1, it may or may not help

GregUzelac
Thank you for this. It does look good but I'm just awaiting and answer to 64/32 bit question I posted about the patch http://blogs.msdn.com/jacdavis/archive/2008/11/14/debugger-qfe-for-vs-2008-sp1-released.aspx
Preet Sangha
+2  A: 

Here is a blog post with a link to the patch.

Thank you I will check this out.
Preet Sangha
There is some more info here : http://social.technet.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193
Preet Sangha
A: 

Spudlo's answer has worked out greatly for us. Thank you. Please download the fix from MSDN

Preet Sangha