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.