Function evaluation disabled because a previous function evaluation timed out. You must cont

Hi Azeem,

I'm having no end of problems with this situation (debugging threads only) and I've already read the other blogs you cited prior to encountering your post here. No matter what I do however, I can't completely stabilize the situation though I can modestly improve it with some of the suggestions. What I'd really like to know is whether it's been fixed in the first VS service pack which is now in beta testing. I doubt it in which case what are developers supposed to do. You guys must surely recognize that this is a serious problem notwithstanding whatever inherent issues you have getting it to run correctly. The debugger is constantly hanging for long periods of time (frequently never returning) or otherwise producing an endless stream of evaluation timeout messages (again, in my case it only happens when debugging threads - note that my properties are also very simple, normally just getting/setting member variables). Something's obviously broken here and desperately needs to be fixed (I've read many similar complaints in this or other forums). Can you comment on the situation. Thanks.

LarrySmith999999 at 2007-8-31 >

Hi Azeem,

Thanks for the reply (sorry for not responding sooner as it just came to my attention). In all honesty however Azeem, I still maintain this situation needs correcting at some level but since the architecture is already in place, it's probably very difficult to address now (and I don't think it will be - not in a service pack anyway). In my VC6 days however, no such problems existed so I'm not sure why they do now (other than the fact that the architecture was changed, perhaps for the better in many ways, but this problem is now a residual effect) . Moreover, I don't see how we're supposed to debug certain threads given this situation. For instance, as you're already well aware, you can't look at a form or any of its controls on a worker thread since this problem manifests itself either immediately or soon after. I've tried all the tips you provided and they do help but eventually the problem occurs again. In my case my properties are fairly simple as well, either returning member variables only or otherwise running very simple functions which shouldn't cause any problems (based on my understanding of this issue). That is, while I may not fully appreciate all the details surrounding this problem, I do understand the basic situation as you've described it. While there may be inherent issues trying to evaluate certain things on other threads, from my perspective things still appear to be broken since the debugger chokes on what should be a routine situation (and it certainly shouldn't freeze up). For instance, I was just inspecting a "TreeView" control on a worker thread and the moment I tried to look at the "TreeNode.Tag" member for a given node, everything froze again. Why should this be? I'm simply looking at an existing member where I've stored a reference to a very simple object whose properties return member variables only. Even if the debugger is running through every member variable (of every member) and evaluating all their properties, they are all sufficiently simple. I don't see why I can't look at them other than the fact that the architecture can't handle it for the reasons you cited. There must be a way for the debugger to deal with this however (again, it doesn't occur in VC6) and I strongly believe that the situation needs to be re-evaluated. I can't debug my application without resorting to a lot of time-consuming trace statements and I know that many others are having the same problem (after researching the situation). In any event, thanks again for your help. It is appreciated and my comments were meant to be constructive (I do have great respect for the difficult job you guys do so well).

LarrySmith999999 at 2007-8-31 >

Ok, thanks for the feedback. I've been in the coding trenches long enough to know that the issues run deeper than end-users normally appreciate, even when they're other programmers. So I do understand your position. While a "fix" may not be in the works for the forseeable future, eliminating the freezing would certainly be a welcome first step. I'm glad it's high on MSFT's list of priorities. In the meantime, keep up the great work in general. Notwithstanding this issue, Visual Studio is perhaps the finest piece of work ever produced by MSFT (the entire team deserves great credit).

LarrySmith999999 at 2007-8-31 >

My advice for avoiding this problem is that when stepping through code where variables are bound to windows or other controls, you don't show local variables or "auto" variables. Look at such things only when you are sure your variables are all safe to look at. And note that the error doesn't necessarily appear on the unsafe variables. Use the "immediate" window on safe (i.e. non-control) variables when operating in dangerous code. If you really need to look at the windows and controls, write a safe static method using System.Windows.Forms.Control.InvokeRequired and Control.Invoke, and call it from the "immediate" window passing the window or control to it. Maybe Windows has problems with non-thread-safe data accessors in non-windows code too. If so, be equially careful there too.

One other way to avoid such problems is to do your coding in Java. It's not bug free, but I've never found problems of this magnitude in several years of using it.

GarrSL at 2007-8-31 >