Visual Studio debugger problem

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.

---

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.

---

I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.

---

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.

---

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.

---

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.

---

Please download the fix from this link

http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912

---

I know this is an old thread but this occurred when debugging an Excel add-in in my case.

Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.

Once I removed that watch, it debugged just fine again.