Alexandre Pepin
Alexandre Pepin

Reputation: 1836

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.

Upvotes: 7

Views: 6269

Answers (7)

sean.net
sean.net

Reputation: 759

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.

Upvotes: 0

Mnyikka
Mnyikka

Reputation: 1261

Please download the fix from this link

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

Upvotes: 0

Andrew
Andrew

Reputation: 31

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

Upvotes: 3

wal
wal

Reputation: 17719

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.

Upvotes: 0

AMissico
AMissico

Reputation: 21684

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.

Upvotes: 4

Justin
Justin

Reputation: 86729

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.

Upvotes: 1

George Johnston
George Johnston

Reputation: 32258

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.

Upvotes: 0

Related Questions