Debugging whilst paused and 'cannot evaluate expression'

Question

Using Visual Studio, after attaching to a Process and pressing Pause (Break-All), you switch to the desired thread and use the Quick Watch window to check out some data, say

MySingletonClass.Instance.Data

Sometimes I either get this:

Cannot evaluate expression because the current thread is in a sleep, wait, or join

or this (when trying to view certain properties of the data):

Cannot evaluate expression because a native frame is on top of the call stack.

Quite frankly, I don't care, I just want to see the data! I know there are various ways to get around this, namely:

1. Setting a breakpoint on the thread and waiting till it gets hit (cumbersome, not always possible)
2. Taking a dump of the process and loading back into VS (even then I still get the 2nd error)
3. windbg

Given you could see this data if you presumably used windbg why is it we all can't take advantage of the much easier and prettier VS to inspect objects when attaching to a process?

Answer 1

Why can’t we do this? We can’t do this because the Visual Studio watch window doesn’t just retrieve data from memory and display it. It actually executes managed code (that’s what it means by “evaluate the expression”). In particular, it almost always executes the ToString() method to display the user-readable result.

The crux is that it executes this code within the process/thread you are debugging. This ensures that the expression evaluates the same way it would if it were actually in the code you are debugging. This leaves the downside that it can only be executed in between managed instructions, but not while native code is active, and not in a blocked thread.

What can we do about it? If you are actually debugging a managed application, and you are in a native stackframe, just press F10 or Shift+F11 repeatedly until you are back in managed code. Then you can evaluate expressions. However, for fully-native processes, and for threads in a blocked state, I am not aware of any workaround.

Answer 2

Here is a link to a discussion on this issue. Apparently when function arguments are structs, and the total memory needed on the stack to call the function exceeds some magical number visual studio debugger pukes.

Additional link from OpenTK framework discussion.

Answer 3

Just hit Shift-F11 until a managed stack frame is on top of the stack and you'll be able to do what you want in VS.

It basically comes down to the fact that it's not safe safe to evaluate expressions at certain points during the process execution, or you risk corrupting the runtime. WinDbg doesn't protect the runtime from you. VS does.

Answer 4

The problem is, that is is not data you want to see, it is the result of running some code. In .Net properties are really just methods in disguise, so in order to get the value of a property, Visual Studio needs to execute application code (this feature is known as FuncEval).

This code must run on some thread and what VS does is that it uses one of the application threads for this. There is a number of situations where VS cannot run the code in order to produce the result, and that is when you seen the error messages you're talking about.