views:

266

answers:

5

In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.

It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?

EDIT : I've managed to reproduce my problem with the following code :

static void Main(string[] args)
{
   XElement e = new XElement("root");
   Test(e, 0);
}

static void Test(XElement parentElement, int i)
{
   if (i < 1000)
   {
      XElement element = new XElement("element");
      parentElement.Add(element);
      Test(element, ++i);
   }
}

You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.

But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.

I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.

A: 

Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.

Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.

George
No unfortunately, this doesn't seem to help
Alexandre Pepin
+1  A: 

I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.

Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.

I have no idea how that would cause your program to continue after that point however.

Kragen
+3  A: 

Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.

If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.

AMissico
+2  A: 

I found the answer to this question on another Stackoverflow thread. There's a MS Hot fix for this issue [1].

[1] http://support.microsoft.com/kb/957912

Andrew
A: 

I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.

wal