You can't cast from a pointer to a managed object in the debugger

  • Article

During native debugging, it's common to cast a raw pointer value to a given type. Eg, in the expression window, do:
    (Foo*) 0x12345;

You may have noticed that you can't do this in managed code. This is a restriction at the ICorDebug (CLR) level. Some of the motivations for this are:

  1. Appdomains: You need to specify which AppDomain "Foo" is in (and that's hard for reasons mentioned here).  
  2. Func-eval: It's dangerous with func-eval. What if you cast garbage to a Foo* and then start func-evalling on it? Managed-code scenarios have a ton more-funceval than native, which aggravates this issue.
  3. Overall Safety: The debugging service's inprocess helper-thread has to execute inspection requests in the debuggee process space, so dangerous inspection requests have the potential to corrupt the debuggee.  We wanted to keep inspection "safe". We have some checking (obviously, you could get a corrupted reference with unsafe code), but casting a bad pointer, getting the right appdomain, doing func-evals on it, etc, would really tempt fate and could cause serious corruption in the debuggee. 
  4. Priority:  Although this is useful, we didn't see this as a top feature need for the mainline C#/VB scenarios. For example, this doesn't really come up in source-level non-optimized debugging scenarios. We focused on other features instead (like these).

With the current in-process architecture, we could put enough (potentially expensive) validation in there to make it safe in some cases. For example, doing a full GC walk could validate it's a valid reference object pointer; but value-type pointers would be much harder to validate. And depending on the CLR implementation, it may not even be possible to determine appdomain.

The signature for such a feature would look something like:
   HRESULT ICorDebugProcess3::GetValueFromAddress(ICorDebugType * pType, CORDB_ADDRESS address, ICorDebugValue ** ppOutValue);

We have a few features that are close, but nothing quite like this.
Not having this is definitely not ideal, and I hope we fix it at a future point.