I don't know if "In-Memory debugger" is really what I mean, or if it's even possible to produce, but it's the best name I could come up with... Here's the tool I'm looking for:

  • Given a variable name, resolve that name to a reference
  • Given that reference, be able to watch the object referenced
  • Given the watch, be able to visualise it in a useful way, e.g.
    • browse the properties of the object as you can in Visual Studio
    • be notified when the object referenced is changed.

Here's a use case for this hypothetical tool. I have spent all of today trying to track down an ObjectDisposedException in my C# web app. The object being disposed is the WindowsIdentity of the current user, and there would appear to be a race condition causing the WindowsIdentity to be disposed before it is used. If I could watch a particular memory reference in an intelligent way, rather than a variable in some given scope, I think it would help me pin down the source of this sort of bug more easily.

Does such a tool exist for .NET?

closed as off-topic by gnat, Bart van Ingen Schenau, amon, 8bittree, MetaFight Dec 15 '17 at 15:30

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to find or recommend tools, libraries, programming languages, resources (including books, blogs, tutorials, and examples), or projects to undertake are off-topic here as they attract opinionated answers that won't have lasting value to others. You may be able to get help in The Whiteboard, our chat room." – gnat, Bart van Ingen Schenau, amon, 8bittree, MetaFight
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I think all you're asking for is already implemented in Visual Studio.... Could you explain what you couldn't achieve using VS debugger? – Jakub Konecki Nov 22 '10 at 20:16
  • Are you using MVC? If so you can not store any state in a controller, they are very short lived objects. A new instance is created for each request the system handles. – Bent Dec 12 '17 at 12:42

If I understand correctly you want to know when a reference is changed. Well, just add a break point on the lines where the reference might be changed and you will break the execution when this happens (or before, depending on where you put the breakpoint).

About seeing variables in other contexts: you can see any variable as long as it exists in one context. Use the threads drop down to select different threads and the call stack to navigate between different frames.

  • I'll give this a go, thanks for the suggestions. I'm not sure, though, whether the reference is disposed in my own code, automatically through GC (perhaps as a result of an action of my code), or just as a result of one of the spun-off threads dying. – alastairs Nov 23 '10 at 0:07

NLog, Log4Net etc... any good logging framework. Perhaps not as glamorous but just as good... with the added bonus to not interfere too much with the process you are trying to debug, especially for concurrency issues. They have the annoying tendency in turning in Eisenbugs where the mere fact of observing the code running will make it behave properly.

Never underestimate the power of low-tech !

  • 1
    I missed this before answering. my answer is similar but with additional detail. +1. – JimmyJames Dec 12 '17 at 16:48
  • 1
    "Eisenbugs where the mere fact of observing the code running will make it behave properly" Yes indeed. I've also seen the opposite where a colleague spent hours trying to fix a bizarre, inexplicable bug that disappeared when he ran the code outside of the debugger. – JimmyJames Dec 12 '17 at 16:50

Debuggers are great learning tools but they are fundamentally inferior to using debugging logs. One of the major drawbacks of debuggers is that they change the way program executes especially with regard to timing. This makes them particularly unhelpful in debugging multi-threading issues. Writing logs is generally less invasive (write to a file, writing to the console is slower in my experience.) Since you mention a potential 'race condition' I think you should skip the debugger. Looking at that exception, it appears to be thrown if you access the object after Dispose or Close has been called. If this is a custom class, have you tried adding debug statements in the Dispose or Close methods? If it's not, you could try wrapping it with a proxy so that you can 'watch' what's calling these methods in the debug log.

One technique that I have found useful is to dump a stack trace to a log when I'm not sure where the call is coming from. Once you know what is calling Dispose or Close and have verified it is too early, you should have enough info to fix the issue.


Objects in C# do not occupy a specific memory location that you can watch. They are moved around to improve the use of memory by the garbage collector.

var obj = new MyObject();

Neither obj as a reference to the newly created MyObject instance nor the MyObject instance itself has any fixed location in memory.

Long lived objects might have a stable location, but it is not fixed.

The only way to follow what happens to the MyObject instance is to watch each reference to it via breakpoints as @VictorHurdugaci explains in his answer.

Not the answer you're looking for? Browse other questions tagged or ask your own question.