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


  • This error happens when you sit at a check-point for around 30-40 seconds. Is there a way to disable this? When I attempt to continue execution (to another break-point on the next line), it does not stop. Is this a Visual Studio setting or a runtime setting.

    Tuesday, August 01, 2006 5:48 PM


  • Everyone,


    Please read the explanations provided by John and myself earlier in this forum post. See the article which provides some workarounds. Note that we are working on mitigating some of these issues in Orcas release and working with our runtime colleagues on a proper solution. Thanks.


    Azeem Khan

    Visual Studio Debugger.


    Thursday, August 09, 2007 4:49 PM

All replies

  • Hi,

    What is happening is that break state was reached and something is being evaluated (e.g. property) in the Locals/Watch/etc window. Looks like this is timing out. You can disable property evaluation by default via the option Tools -> Options -> Debugging -> General -> Enable property evaluation and other implicit function calls. The side effect is that properties will not be evaluated by default.

    See blog entries like and for more information about function evaluation.

    Azeem Khan

    Visual Studio Debugger.

    Friday, August 04, 2006 6:33 PM
  • 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.

    Wednesday, September 20, 2006 4:34 PM
  • Hi Larry,

    Have you tried the workarounds suggested in the blog entry

    Specifically disable the option "Call ToString on objects in variable windows". If this doesn't help disable "Enable property evaluation & other implicit function calls".

    The issue here is that evaluatioin can cause code to be run in the debuggee. If code requires that others threads run then the evaluation times out and gives the appearance of a hang. The timeout happens because the debugger allows only the thread on which you broke to run. It does this so that other threads remain stopped at the same location. The debugger cannnot enforce that evaluations do not call into other threads. If the evaluations are simply getting member variables then it will not cause the timeouts.

    We are looking at ways to improve things in this area but ultimately we have no control on what users write for their property evaluation. Hope this clarifies things a bit.

    Azeem Khan

    Visual Studio Debugger.


    Tuesday, October 03, 2006 12:53 AM
  • 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).

    Wednesday, October 11, 2006 1:39 PM
  • Larry - we certainly here you. 

    This is a pretty fundamental difference between a managed runtime, that imposes a strict API on inspection of data, and the native OS and compiler, which gives us clear information about runtime layout of objects and the ability to read arbitrary locations in memory.  We've discussed this many times with our colleagues in the runtime team, but basically our hands are tied to the runtime APIs.  We are hopefull that this will be solved in future CLR releases.  Comparing VC6 behaviour to managed code behaviour isn't quite an apples to apples comparision.  There are going to be a number of things which just don't translate.

    In the meantime we have been hard at work on a mitigating feature in time for our Orcas release which detects cross thread calls in Windows forms code and stops the function evaluation.  But let's be clear - this is only a mitigation, it will stop the hang/freeze crash cases by bailing out early.  You may still not be able to look at data that requires cross thread calls.

    Sorry I don't have a better answer for you, but rest assured, this is one of our top priorities to address with the runtime team going forward.


    Friday, November 03, 2006 12:43 AM
  • 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).

    Friday, November 03, 2006 10:23 PM



    I never experienced this problem in VS2003 only in VS 2005 I am experiencing this problem. Why is that? Cant we just repeat whatever is in VS 2003?




    Tuesday, July 31, 2007 10:54 AM
  • I have just encountered this problem when looking through the System.Windows.Forms.Application.OpenForms.  The problem seems to occur because the loop variable, a Form run on another thread, is displayed in the "locals" window of Visual Studio.  Data accessors should always be thread safe.  Maybe that's not so in .NET 3.0.  I'm relatively new to Windows and .NET, but that's what it looks like to me.  On the other hand, one wouldn't expect Microsoft to make that huge a blunder, so maybe appearances in Visual Studio are deceiving.

    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.
    Wednesday, August 08, 2007 8:19 PM
  • Everyone,


    Please read the explanations provided by John and myself earlier in this forum post. See the article which provides some workarounds. Note that we are working on mitigating some of these issues in Orcas release and working with our runtime colleagues on a proper solution. Thanks.


    Azeem Khan

    Visual Studio Debugger.


    Thursday, August 09, 2007 4:49 PM

    OK - I'm late on this but I found another way around the problem.

    I took all of the work that needed to be done by one of my 2 threads and put it in a seperate class. Seperating the UI thread from the worker thread. This allowed me to debug my "worker class" without the issues mentioned above.  I added events to my class to update the UI and just subscribe to them on the UI thread. I think this solution probably falls under "avoiding the problem" (from the blog entry), but I just thought I'd add my 2 cents in case it helps someone else later. This post certainly helped me solve the problem.





    Wednesday, November 28, 2007 8:07 PM
  • After moving things around and turning off automatic "ToString()" calls during debugging, things seemed to get better but now I actually managed to get Visual Studio to tell me

    The debugger cannot continue running the process. The current thread cannot continue while an expression is being evaluated on another thread.

    which is all nice and helpful but not entirely useful since I do not spawn any extra threads in my code. I am guessing this is related to Forms magic happening in the background but I could be wrong.


    This is frustrating...


    Thursday, December 06, 2007 1:55 AM
  • Hi Larry,
                 It has been almost a year and a half or may be more when this problem was raised.Has MS come up with any solution till now,If yes then can you give me a link to the solution,and if no--then it really hampers the wonderful VS2005 team's image for showing neglegance  to such a critical issue.
    Wednesday, December 19, 2007 6:27 AM
  • Here is one situation that can cause the problem.
    Passing the user interface object into a subordinate class, in order to provide the subordinate class with access to methods on the user interface object.
    The correct solution is to raise events in the subordinate class to which the ui object can subscribe.
    Larry O'Heron

    Monday, January 28, 2008 4:21 PM
  • Hello, guys.

    I have also this problem, but I don't work with threads. I work with CrystaReports. Reports has a base class ReportClass.
    Every time I try (for first time) to see how many rows I have in the report (report.Rows.Count) with the "watch" I run in this error. If I have read already the Rows Count by code in a variable, the Rows.Cout evaluation in "watch" pass.

    But I can't already see the content of my rows... The code can read this properties, but the "watch" doesn't. After the error occurs, I should restart the application debug... this is very annoying :(

    private readonly string _Signature = "Best regards, \nserhio";
    Tuesday, June 03, 2008 8:13 PM