|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
What causes this degugger error?When trying to view Locals in the debugger, there is a delay and then this
message: "Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation." Continuing does not help. Once this error occurs, the execution for that thread is dead. This program functions well except when trying to view its Locals. What causes this message? How can we tell what previous function evaluation failed? Thanks, Randy Neall Randy,
The debugger will run all property getters on the watched object. I suspect one of the getters is not returning in a timely manner. Do you have any objects in your application that contain getters with non-trivial implementations? Specifically, do those getters run a long operation, acquire locks, block on a wait handle, etc? That's the first place I'd look. Is this VS 2005? I believe in VS.NET 2003 that scenario would hang up the debugger, but I can't remember. Brian Randolph Neall wrote: Show quote > When trying to view Locals in the debugger, there is a delay and then this > message: "Function evaluation disabled because a previous function > evaluation timed out. You must continue execution to reenable function > evaluation." > > Continuing does not help. Once this error occurs, the execution for that > thread is dead. > > This program functions well except when trying to view its Locals. > > What causes this message? How can we tell what previous function evaluation > failed? > > Thanks, > > Randy Neall Yes, it's VS 2005.
So you're saying its usually a property that causes this? I'll check to see if there's a big one in there somewhere. Of course this error appears against dozens of values so it's very hard to tell which dude started the collapse. Thanks, Randy Show quote "Brian Gideon" <briangid***@yahoo.com> wrote in message news:1147711690.421016.298380@y43g2000cwc.googlegroups.com... > Randy, > > The debugger will run all property getters on the watched object. I > suspect one of the getters is not returning in a timely manner. Do you > have any objects in your application that contain getters with > non-trivial implementations? Specifically, do those getters run a long > operation, acquire locks, block on a wait handle, etc? That's the > first place I'd look. > > Is this VS 2005? I believe in VS.NET 2003 that scenario would hang up > the debugger, but I can't remember. > > Brian > > Randolph Neall wrote: > > When trying to view Locals in the debugger, there is a delay and then this > > message: "Function evaluation disabled because a previous function > > evaluation timed out. You must continue execution to reenable function > > evaluation." > > > > Continuing does not help. Once this error occurs, the execution for that > > thread is dead. > > > > This program functions well except when trying to view its Locals. > > > > What causes this message? How can we tell what previous function evaluation > > failed? > > > > Thanks, > > > > Randy Neall > Randolph Neall wrote:
> So you're saying its usually a property that causes this? I can't say for sure, but like I said that's the first place I'd look.I have exactly two get properties, one returning a bool and the other a
datatable, both initially set as class variables. Neither one is null or unavailable and even if they were, this should not have happened. The error does not happen consistently. I've tried putting breakpoints early in the code execution to see how far it has to go before the timeouts happen, but the results are inconsistent, and seem to be influenced by the debugging process itself. For instance, if you break at line X, the errors occur, but if you break at line L and creep up to line X, the error might not happen by the time you reach X. This thing is random, frustrating, infuriating. Microsoft could easily have included a specific error message telling what the initial offending item is. But no, Microsoft did not do so. This problem absolutely kills a debugging session. You have to quit debugging, exit the app, and start over from scratch, contrary to helpful suggestions just to "continue." Randy Neall Show quote "Brian Gideon" <briangid***@yahoo.com> wrote in message news:1147720328.797762.286350@u72g2000cwu.googlegroups.com... > > Randolph Neall wrote: > > So you're saying its usually a property that causes this? > > I can't say for sure, but like I said that's the first place I'd look. > Found the answer:
The following blog solved the problem: http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx This guy saved my day. In my case the problem was a child thread object referencing a parent form on the main thread. I put the following code just above the private class-level field referencing the form: [System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableSt ate.Never)] That solved it. I still say that Microsoft is remiss in not popping up a message identifying the offending variable or property. Randolph Neall wrote:
Show quote > Found the answer: Yes, the message really should have been more descriptive. Anyway,> > The following blog solved the problem: > http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx > > This guy saved my day. > > In my case the problem was a child thread object referencing a parent form > on the main thread. > > I put the following code just above the private class-level field > referencing the form: > [System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableSt > ate.Never)] > > That solved it. > > I still say that Microsoft is remiss in not popping up a message identifying > the offending variable or property. thanks for posting back with the solution.  |
|||||||||||||||||||||||
Other interesting topics