Error when using a conditional breakpoint on System.Type

Question

This is the function:

public void Init(System.Type Type) {
    this.Type = Type;
    BuildFieldAttributes();
    BuildDataColumns(FieldAttributes);
}

I've set a breakpoint on the first line (this.Type = Type) and I want to break when Type.FullName == "Malt.Organisation" so that's what I've entered in as the condition.

However the following error is displayed when the line is hit:

The condition for a breakpoint failed to execute. The condition was 'Type.FullName == "Malt.Organisation"'. The error returned was 'Inspecting the state of an object in the debuggee of type System.Type is not supported in this context.'

What (obvious) thing am I doing wrong?

PS. A workaround is to add this to the code:

if (Type.FullName == "Malt.Organisation") System.Diagnostics.Debugger.Break();

Zehe

Might not be relevant, but are you passing a RunTimeType or a Type into your method? – Incorrect

The debugger is pretty explicit about it: "we don't support that yet". Not in VS2015 either, it ought to have a better shot at it thanks to Roslyn. If it ever will is a question you can't get answered here, you'd have to ask Microsoft. They are not apt to make promises. – Humfrey

I strongly discourage you from using Type as a variable name or Property name. This will inevitably lead to conflicts because your variable is also the name of a well-known type. Does it work if you rename Type to type and/or theType? – Kinematics

Still happen in VS 2017 community edition. Managed-compatibility-mode is not really an option if you want the latest debugging features. – Ineducable

@HansPassant: "The debugger is pretty explicit about it" - I disagree, because it is unclear what "that" is. Is there anything special about System.Type as a class with members? Is there an arbitrary list of types that can't be inspected for some reason? And what is "this context", anyway? In what context is inspecting the state of an object of type System.Type supported? As such, the message just says "Something is wrong.", but it gives no hint about what that something might be. – Osculation

@stephen.vakil: Not that I would say the possibility for confusion is not there, but Microsoft does not seem to share your concerns: System.Web.UI.WebControls.BaseCompareValidator.Type, System.Linq.Expressions.Expression.Type, System.Drawing.Imaging.PropertyItem.Type. – Osculation

"We don't support that yet" is unacceptable. I've been doing that for MONTHS if not YEARS, even in VS2017, until recently, and now all of a sudden that "feature" has been disabled or intentionally broken. – Policeman

I might add, the problem here is not just one of naming conventions, but is one of the debugger supporting expressions, lambdas, etc. That support has been in there for a while now, at least until the recent breakage. – Policeman

Answer 1

⚠ Heads up, seems this is no longer available since Visual Studio 2022.

---

In my case I was using Visual Studio 2013, NUnit 2.6.4, and attaching a debugger to a unit test session, and I was getting a similar message:

The condition for a breakpoint failed to execute. The condition was 'type.Name.Contains("FooBar")'. The error returned was 'Inspecting the state of an object in the debuggee of type System.Type is not supported in this context.'. Click OK to stop at this breakpoint.

This was caused by a missing feature in the new debug engine Microsoft had introduced, apparently. Following instructions from this msdn blogpost I got things to work. The instructions boil down to:

1. From the "Tools" menu open "Options"
2. On the left hand side pick "Debugging", "General"
3. Scroll all the way down to check "Use Managed Compatibility Mode"

This should switch to the legacy debug engine, which in my case allowed for expressions on Type in break point conditions. Note that you do need to restart your app or debugging session, obviously.

Disclaimer: I have no idea what other effects checking this option had. Personally, I turned it back off when I was done with the task that required it...

Hatten

This worked for me as well. There was definitely a heavy performance hit with my breakpoint. I think your suggestion to turn the setting off afterwards is wise. – Sidonie

Had a similar problem with VS2015 Update 2: a breakpoint with condition pi.Name == "whatever" (where pi is of type System.Reflection.PropertyInfo) throws up a dialog Inspecting the state of an object in the debuggee of type System.Reflection.PropertyInfo is not supported in this context. Forcing Managed Compatibility Mode for the debugger now allows the breakpoint to be hit as expected. How long will it take for MS to get their "new" debugger to feature-completeness with the "old" one? – Cristacristabel

A little bit about the ramifications of turning this on: blogs.msdn.microsoft.com/devops/2013/10/16/… (TLDR: if you have "Use managed compatability mode" on, you can't edit code while in break mode) – Wonky

The option Use Managed Compatibility Mode helped me (+1) but this option disabled the Diagnostic Tool window. This can be a reason to turn off the mode after debugging is completed. – Benevento

This option does not appear to exist in VS2022 (at least, Professional 64-bit edition). – Cheapen

Indeed, it seems to be gone. Will add that to the answer. – Hatten

Answer 2

You say that Type.FullName == "Malt.Organisation" causes it to break, have you tried this.Type.FullName == "Malt.Organisation"?

Another possibility, does the debugger think you are trying to invoke a static method with having the variable named Type like its class name? Does renaming the Type variable to something else fix it?

Many

There is this "workaround", but you're right, it's kind of undesired and clutters the code. – Policeman

Answer 3

I ran into this but when testing for IsInterface in a Web Application. Instead of enabling extra features in the debugger, I simply cheated.

bool blnIsInterface = tType.IsInterface;

//Insert breakpoint here...
if(blnIsInterface)
{
    ...
}

So in your case your could do something like

public void Init(System.Type Type) {
    bool blnBreak = Type.FullName == "Malt.Organisation";
    //insert breakpoint of blnBreak == true
    this.Type = Type;
    BuildFieldAttributes();
    BuildDataColumns(FieldAttributes);
}

It's a bit cumbersome but at least you won't have to worry about performance hits and enabling Native code debugging doesn't seem to be an option in Web Applications.

Birefringence

Answer 4

I'm not sure about "Use Managed Compatibility Mode" solution described here - did not help me, but in my own case Project > Properties > Debug > Enable Native code debugging - must be unchecked.

Why - no clue currently.

Was using .net 4.5, vs2015, console application.

Rhabdomancy

How about for a netcore assembly circa VS2017? – Policeman

Answer 5

That worked for me, give a shot:

var name = Type.FullName;
if (name == "Malt.Organisation") System.Diagnostics.Debugger.Break();

Alloway