Visual Studio Debugger Problem

Question

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

It is very difficult to reproduce, and this does not happen every time I want to debug something. Does anyone have a solution?

EDIT: I was able 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 run the program, wait 2-3 seconds and set a normal breakpoint on the line" parentElement.Add ( element); ". Now VisualStudio freezes and debugging is impossible. In the WinForm application, it closes all forms that are open after pressing F10.

But I found that if I turn off the debug option “Convert call string function for objects in variable windows” to “Tools → Options → Debugging”, I can debug it. It is slow, but at least VisualStudio does not freeze. Does anyone know why he is doing this? Because I do not want to disable this option, it is 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 works very quickly, comparing it with a conditional breakpoint in a recursive method.

Answer 1

Try to delete the solution user parameter file (.suo), where the information about the debug / break point is stored. You will lose all custom settings for the solution, such as breakpoints. When you have “funny” debugging cases, this is the first thing to try, because this file may get corrupted.

If this does not solve the problem, you have something else, for example, problems with threads, excessive memory fragmentation, problems with garbage collection, troubleshooting / shutdown, etc.

Answer 2

I found the answer to this question in another Stackoverflow thread. There is an MS fix for this problem.

Answer 3

I found that I have such a slowdown when I add deleted child stocks that are not in the list of symbol directories.

Try going to Tools → Options → Debugging → Symbols and make sure that all directories in this list really exist.

I do not know how this can lead to the continuation of your program after this point.

Answer 4

Not sure if I ever came across this, but if I were you, if you didn't, delete the bin folder and rebuild your project. Then run a clean solution to be safe. Sometimes funky things happen to your PDB, so you need to clean them.

Also, if you are invoking external assemblies, delete them and reconnect to make sure you have the most up-to-date assemblies.

Answer 5

I had the same problem as you described. The MS Hotfix solution fixed the problem, and now I install this patch whenever I perform a new installation of VS VS 2008.

Answer 6

Download the patch from this link.

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

Answer 7

I know this is an old thread, but it happened while debugging an Excel add-in in my case.

The problem was that my breakpoint was in the background thread and in my watch window I had an old ActiveWorkbook check in Excel. This call, like many others, should only be present in the main Excel thread.

As soon as I remove this watch, it is debugging again.