VS2010 debugger in limbo

3
votes

I have a large multithreaded C# program in development that loads multiple DLLs from several VS2010 projects/solutions. Debugging it proves more difficult than I expected (who'd think).

The problem is as follows. More often than not, after a few step-over and/or break-all operations, the program (or perhaps the debugger) enters into some kind of indeterminate state which is neither running nor stopped. In the Debug menu, both Continue and Break All are grayed out, so I cannot continue to work with the program.

Sometimes, but not always, when this happens, I see a message in the watch windows that says:

Function evaluation disabled because a previous function evaluation timed out.

The program doesn't seem to be running (no output, no stopping on breakpoints...) and doesn't appear to be stopped also (the Watch window is grayed out, the Call Stack window is empty).

Stop Debugging and Restart commands are available and working.

Can I do anything in order to be able to debug the thing normally, without restarting the session over and over again?

I am new to development in the Windows environment, and could be missing something obvious.

1
c#visual-studio-2010debugging
Sounds like a dead lock or infinite loop. Have you tried taking a memory dump and examining the program state that way? – Conrad Frix
@ConradFrix: I want to be able to stop and examine my program, at the source code level, in whatever state of execution it is. I had a chance to use a few debuggers in the last 20 years, under various flavors of Unix, and every single one of them can do that, infinite loop, deadlock or whatever. And now I have to resort to memory dumps? Under Windows, of all things? Please say it ain't so. – n. 1.8e9-where's-my-share m.
@ConradFrix: In addition, the debugger often enter this state after a simple step over a very simple line of code, without any function calls that could possibly loop or deadlock. So that could not be a reason. – n. 1.8e9-where's-my-share m.
the debugger often enter this state after a simple step over a very simple line of code Perhaps its not the line of code you're debugging but something in your watch. – Conrad Frix
Hm. I'm pretty sure no expression in my watches could possibly deadlock or loop, but removing all watches seem to solve the issue, for now at least. Even if there's a bad watch expression somewhere, that's pretty sad. A debugger should not stop working if there's a bug in my program... – n. 1.8e9-where's-my-share m.

1 Answers

2
votes

As @Conrad Frix said, your best option may be to take a memory dump & examine what your threads are doing. There are a number of tools available for Windows & .Net development, each of which brings something a little different to the table:

Windbg - Text based memory inspection. Great for digging deep into the framework/OS & examining thread stacks, but there's a pretty steep learning curve. (Doesn't get more powerful than this however)

JetBrains dotTrace - integrated with Reshaper if you use that. Not the best results in my experience though.

RedGate ANTS - My favorite of the "modern" GUI based profilers. This gives you really good insights into what your threads are doing, but can be a bit difficult to work with if you have hundreds of threads in your application.

Jetbrains & RedGate are paid products, so you'll probably need to use their free trials to resolve your issue.