53

I come from a C++ background, so apologies if this is a non-C# way of thinking, but I just need to know. :)

In C++ if I have two pointers, and I want to know if they point to the same thing, I can look in the memory/watch window and see their value - to see if they are pointing to the same memory space.

In C#, I haven't been able to find something along those lines. One reference type with exactly the same values could in fact be the exact same object, or it could be something wildly different.

Is there a way for me to see this kind of information in C#? Perhaps some kind of equivalent to the & operator for the watch window or some such?

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
Eddie Parker
  • 4,770
  • 3
  • 35
  • 43

4 Answers4

87

What you're looking for are object id's. For any referenc type in the debugger you can right click and say "Make Object ID". This will add a # suffix to the value column whenever that instance is displayed in the debugger. You can also add #1, #2, etc ... to the watch window to see them again any time later.

Step 0 - Run this code

static void Main(string[] args)
{
    var x = "a string";
    var y = x;
    System.Diagnostics.Debugger.Break();
}

Step 1 - Right Click and select "Make Object Id"

alt text

Step 2 - Instances now display with the 1# suffix. Note: I did nothing special in this step. Immediately after clicking "Make Object Id" both rows updated to display the 1# suffix since they refer to the same instance.

alt text

Step 3 - See them at any time by adding 1# to the watch window

alt text

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 9
    That's cool, I've never heard of object id's. So many little things like this that are 'hidden' in VS. – Alastair Pitts Nov 22 '10 at 23:59
  • 1
    Awesome sauce. Great explanation, and sexy visuals. +1 and a right answer. :) – Eddie Parker Nov 23 '10 at 19:57
  • 3
    It appears in VS 2015 the syntax is $1, $2, etc – Justin Caldicott Jun 21 '16 at 21:41
  • What happens when the object that you have watched does not exist any more? I am debugging some thing related to EF DbContext and it seems that these objects stay in the Locals window, even though (I hope) they were already disposed... – Bartosz Jul 12 '17 at 19:21
  • There is a 'bug' of sorts - if whatever is in the Value column is too long you wont be able to see the ID because it is somewhere out of screen. As workaround click Edit value, that will scroll you to the end. – wondra Nov 04 '21 at 16:04
  • Microsoft did it the most cumbersome way they could find... There is no obvious reason why I have to "Make Object ID". It already exists. Nothing could work without an internal reference. They should just always show it in debugger like Android Studio does... – The incredible Jan Nov 17 '21 at 12:45
  • Tried it. Doesn't work "from one breakpoint to another". As if I had a problem to remember a referenced object in a single method... I have to deal with kind of "global" objects in code that nobody can explain me (no documentation, developers don't "exist" anymore). These global objects are "sometimes" recreated and I think at some points these recreations aren't recognized everywhere and some variables refer to the old objects. Pretty easy to find with pointers in a C++ (maybe not in VS, don't know) or the reference ids in Android Studio... – The incredible Jan Nov 17 '21 at 14:56
6

In C# projects, if you right-click on a variable's name in one of the variable windows and select "create object ID", Visual Studio will assign a unique ID to that instance and display it in the Value column. The IDs look like {1#}, {2#}, etc. If two objects have the same ID then they're referentially identical.

In code or in the Immediate window, you can also check to see if two objects are identical by using Object.ReferenceEquals().

I don't believe there's a good way to get an actual memory address for an object in the debugger. I'm guessing that's by design, since an object's location in memory is likely to change during garbage collection in a managed application. Of course you could declare an unsafe block, pin the object, and grab a pointer to it using all the usual C/C++ operators. Then you'd be able to see the pointer's value in the debugger. I wouldn't recommend that as a good habit, though - pinning objects tends to muck with the garbage collector's ability to maintain an orderly heap, which can in turn lead to worse performance and memory consumption.

Sean U
  • 6,730
  • 1
  • 24
  • 43
  • 1
    To view the memory address of a variable in the watch window, precede the variable name with an ampersand (&). i.e.: &varName. – boylec1986 Nov 29 '18 at 18:27
1

You could use the Immediate Window and use Object.ReferenceEquals(obj1, obj2) to test this out!

Alastair Pitts
  • 19,423
  • 9
  • 68
  • 97
0

I think you want the System.Object.ReferenceEquals function.

Timbo
  • 4,505
  • 2
  • 26
  • 29