7

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.

Improve this question
3
  • Can you make a fresh install of your OS and VS on another system and try your debugging there? I'd suspect other software/config/hardware rather than this being a direct VS problem. Commented Mar 3, 2010 at 16:05
  • I don't think so because it does the same problem on the computer of my colleagues and some of them have a different OS Commented Mar 3, 2010 at 16:33
  • do you have a lot of breakpoints ? Commented Mar 11, 2010 at 19:40

7 Answers 7

Reset to default
4

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

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

Improve this answer

1 Comment

Many comments say that the fix doesnt fix anything =(
1

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.

Improve this answer

Comments

0

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.

Improve this answer

1 Comment

No unfortunately, this doesn't seem to help
0

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.

Improve this answer

2 Comments

Many comments on the webpage says that the fix doesnt help at all =(
ensure you delete your bin/obj folders of ALL your projects after applying the hotfix
0

Please download the fix from this link

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

Improve this answer

Comments

0

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.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.