What causes this degugger error?

  • Thread starter Thread starter Randolph Neall
  • Start date Start date
R

Randolph Neall

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
 
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
 
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
 
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 said:
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.
Click to expand...

Yes, the message really should have been more descriptive. Anyway,
thanks for posting back with the solution.
 
Back
Top