Develop Reference

Determine if Object has been destroyed (i.e no longer found anywhere) in C#

I'm sure this has been asked before and I just don't know the right terms to search for. In a C# program I am working on I have an List that keeps track of Objects. Those objects can also be displayed on the screen via references by other objects.
Sometimes after an object is removed from the list it is still temporarily available to those other objects (as it should be)... After those objects are done however I want to make sure the object is 100% gone and not staying in memory still being referenced by a forgotten object... How can I do this?
To be clear, this doesn't need to happen as part of the shipped program, only for debugging.

You normally can't. The GC is meant to take care of memory management behind the scenes, and does it's job very specifically and by means best not trifled with. In particular, other parts of your code may keep a reference to the item you want removed, which SHOULD prevent its collection. such is the nature of memory managed languages such as C#.
That being said, however, there are a few ways to check for when an object is disposed. The easiest to to create a simple destructor and breakpoint it, allowing you to "see" whenever an object is collected.
~MyClass()
{ // Breakpoint here
}
The other way is to make a static list of WeakReferences to your objects, which each object subscribes to when it's created. Make sure to keep that other list, however, as a weak reference is specifically designed to allow garbage collection, allowing you to track an object to its destruction. The other list is necessary to keep the objects alive. Also note that in .NET 4.5, there is a generic version of WeakReference. EDIT: This is definitely the solution I recommend after seeing the updates to your question. You can also quickly query which objects are still being refernced via Linq
var leftoverObjects = WeakCache
.Select(wr => wr.Target)
.OfType<MyObject>() // Only if you're not using that Generic Weak Reference
.Except(ObjectList); // filters away objects in the List
Be warned the above query creates a result which has strong references, so once run, it'll keep those objects in memory as long as the result is referenced.
If you have some sort of unmanaged memory backing your object, that's exactly what the IDisposable interface is designed for.
UPDATE: finally, if you MUST do so, you can Force the GC to Collect. This is often heavily advised against, as you start to warp the Generations that help optimize the GC in the first place.

I guess you need this for testing purpose. In such case I would recommend to use memory profiler such as ANTS Memory Profiler or JetBrains dotTrace. You can find more complete list of profilers here

There is no easy way to look for an object reference "backwards", basically you would need to use reflection to loop through all objects and structs that exist in the application and check all references. You just have to make sure that all code that uses the reference really removes it when they are done.
One way to check if there seems to be any live references (but not where they are) is to keep a list of weak references to the objects that you don't use any more. The weak references will not keep the objects from being collected, but you can use them to check if the objects have been collected or not.
As there is no guarantee that an object should be collected within any certain time, you can never know for sure if it's an actual reference that keeps an object alive, but the longer the objects survive, the more likely it is that you have a reference to it somewhere.

How to know if winform form has been garbage collected?

I'm using C# but probably the same in VB.NET. I C++ I would just set a break-point on an objects destructor to know when/if it was deleted/free'd. I understand that in winforms the base class calls SupressFinalize so that form destructors are never called, so I guess I can't do it that way. Is there another method to know if an object has been garbage collected? It seems like a catch-22 because if there was you would probably need a reference to check, but by holding that reference the garbage collected will not crush it.
I've read this What strategies and tools are useful for finding memory leaks in .NET?, and I understand there are tools and/or frameworks out there to handle this "big picture" and I'm sure in a few weeks I'll be trying out several of these methods. For now I just have a really strong feeling I might have a leak related to forms not being deleted, so just want to check this one thing (and I want to know just for the sake of knowing).
I know I can watch Dispose, but I'm pretty sure Dispose can be called but still end up with the form object still being around. To test that theory I created a known-issue where I registered for a callback event in my form, then closed the form without unregistering it. Sure enough, Dispose was called (and "disposing" was true), but later when the event was fired, it still hit my break-point inside the form that was supposedly disposed already.

There are really two issues here:
As for your original question, you can use a WeakReference to monitor an object's existence without affecting its lifetime.
Your underlying question suggests that you have a misunderstanding of what garbage collection is, and how it works. The point of garbage collection is that you should never care if an object has been collected or not. Instead, you should focus on the references to the object, and if they have been reassigned or made inaccessible from rooted references. Don't worry about the instance, worry about the references to it.

The entire concept of a managed language is that you don't need to care when an object is actually garbage collected. Lots and lots of time and effort go into the GC to make sure that it doesn't collect objects that it shouldn't, that it doesn't leave objects that it should collect (when it decides to do a pass over the generation that it's in) and that all of this is done reasonably efficiently. This means that if an object consumes a large amount of managed resources and also implements IDisposable (say, a DataTable or DataSet) is disposed it is still consuming a lat of memory, and disposing of it doesn't make it get garbage collected any quicker (although you should still dispose of it to ensure any managed resources go away).
The GC is built to work best when you leave it alone and let it do it's job rather than interfering with it by trying to, for example, manually cause collections to take place. This is occasionally useful for debugging purposes or learning about your program/the language, but it virtually never belongs in a production application.
Disposing has nothing to do with garbage collection or collecting an object. Disposing is the mechanism in place for dealing with a managed object that is holding onto an unmangaed resource (or another object that is holding onto an unmangaed resource). Disposing of the object is telling it to clear up that unmanaged resource, but it has nothing to do with the garbage collector freeing the managed resources of that object. The destructor is there so that you don't free the managed resources before freeing the unmanaged resources, but it's perfectly acceptable (and in fact should always happen) that the unmanaged resources are cleaned up (via dispose) before the managed resource is freed.
Now, it is still possible, given all of this, for a program to have a memory leak, but there are a few questions you really need to be asking yourself first. How large is the leak? Is it a one off, continuous over time, every time we do function X, etc? What would it take for the program to consume so much memory as to be disruptive (either run out of memory, cause other programs to run out of memory, etc) and is that likely to occur with common or legitimate uses of the program? Usually you don't need to start asking these types of questions until you start getting out of memory exceptions, or notice that you start running out of physical memory for a program that oughtn't to. If you notice these problems then you can start looking around for objects that implement IDisposable that aren't being disposed, to see if you're holding onto references to very large objects (or collections of objects) that you no longer need, etc.
Sorry for the wall of text.

C# - Preparing An Object For GC Before Calling GC.Collect

Scenario
Lets say that I've decided I really need to call GC.Collect();
What do I need to do to ensure that an object is prepared to be garbage collected appropriately before I actually call this method?
Would assigning null to all properties of the object be enough? Or just assigning null to the object itself?
If you really need to know why.....
I have a distributed application in WCF that sends a DataContract over the wire every few seconds, containing 8 Dictionaries as DataMembers.
This is a lot of data and when it comes into the Client-side interface, a whole new DataContract object is created and the memory usage of the application is growing so big that I'm getting OutOfMemory Exceptions.
Thanks
EDIT
Thanks for all the comments and answers, it seems that everyone shares the same opinion.
What I cannot understand is how I can possibly dispose correctly because the connection is open constantly.
Once I've copied the data over from the incoming object, I don't need the object anymore, so would simply implementing IDisposable on that DataContract object be enough?
My original problem is here - Distributed OutOfMemory Exceptions

As long as nothing else can see the object it is already eligible for collection; nothing more is required. The key point here is to ensure that nothing else is watching it (or at least, nothing with a longer lifetime):
is it in a field somewhere?
is it in a variable in a method that is incomplete? (an infinite loop or iterator block, perhaps)
is it in a collection somewhere?
has it subscribed to some event?
it is captured in a closure (lambda / anon-method) that is still alive?
I genuinely doubt that GC.Collect() is the answer here; if it was eligible it would have already been collected. If it isn't elgible, calling GC.Collect() certainly won't help and quite possibly will make things worse (by tying up CPU when nothing useful can be collected).

You don't generally need to do anything.
If the object is no longer referenced then it's a candidate for collection. (And, conversely, if the object is still referenced then it's not a candidate for collection, however you "prepare" it.)

You need to clean up any unmanaged resources like database connections etc.
Typically by implementing IDisposable and call Dispose.
If you have a finalizer you should call GC.SuppressFinilize.
The rest is cleaned up by the garbage collector.
Edit:
And, oh, naturally you need to release all references to your object.
But, and here is this big but. Unless you have a very very special case you don't need to call GC.Collect. You probably forgets to release some resources or references, and GC.Collect won't help you with that. Make sure you call Dispose on everything Disposable (preferably with the using-pattern).
You should probably pick up a memory profiler like Ants memory profiler and look where all your memory has gone.

If you have no more direct reference to an object, and you're running out of memory, GC should do this automatically. Do make sure you call .Dispose() on your datacontext.

Calling GC.Collect will hardly ever prevent you from getting OutOfMemory exceptions, because .NET will call GC.Collect itself when it is unable to create a new object due to OOM. There is only one scenario where I can think of and that is when you have unreferenced objects that are registered in the finalizable queue. When these objects reference many other objects it can cause a OOM. The solution to this problem is actually not to call GC.Collect but to ensure that those objects are disposed correctly (and implement the dispose pattern correctly when you created those objects).

Using GC.Collect in general
Since you are trying to get rid of a very large collection, it's totally valid to use GC.Collect(). From the Microsoft docs:
... since your application knows more about its behavior than the runtime does, you could help matters by explicitly forcing some collections. For example, it might make sense for your application to force a full collection of all generations after the user saves his data file.
"Preparing" your objects
From the excellent Performance Considerations for Run-Time Technologies in the .NET Framework (from MSDN):
If you keep a pointer to a resource around, the GC has no way of knowing if you intend to use it in the future. What this means is that all of the rules you've used in native code for explicitly freeing objects still apply, but most of the time the GC will handle everything for you.
So, to ensure it's ready for GC, Make sure that you have no references to the objects you wish to collect (e.g. in collections, events, etc...). Setting the variable to null will mean it's ready for collection before the variable goes out of scope.
Also any object which implements IDisposable should have it's Dispose() method called to clean up unmanaged resources.
Before you use GC.Collect
Since it looks like your application is a server, using the Server GC may resolve your issue. It will likely run more often and be more performant in a multi-processor scenario.
The server GC is designed for maximum throughput, and scales with very high performance.
See the Choosing Which Garbage Collector to Use within Performance Considerations for Run-Time Technologies in the .NET Framework (from MSDN):

who knows me? (Chronicles of an object)

If an object has 5 references can that object find out what is referenced to him?
Because I know that Java (and hopefully C#) have a list of that for the GC.

No, there's no "list of references". The GC doesn't need to know everything that references an object - it just needs to know if anything references an object.
As a very crude model of what the GC does, it marks every object in the heap as garbage, then looks at objects which it knows to be non-garbage ("root" objects). For example, it will look at the stack of each thread and for each instance method in the thread, it will usually1 mark the target instance as non-garbage.
Then it will go through each of those roots, and see what objects those ones refer to... and mark them as non-garbage. It will recurse down, finding everything it can. Whatever hasn't been marked as non-garbage can then be collected (or finalized).
As you can see from this algorithm, the GC doesn't need to keep a full list of references for each object - just a bit to say "garbage" or "non-garbage".
Obviously in reality the GC is much more complicated than this, in both Java and .NET, with generational garbage collectors and various strategies to minimise the GC "pause" and use multiple threads for GC. Hopefully this simplified view is enough to explain why even the GC doesn't have a list of references though.
1 Not always, in the case of .NET. An object can be garbage collected while an instance method is still running "in" it, if that method doesn't refer to any fields in the object from the current point onwards.

If you fail to find language support for this, simply have each object that wants to hold a reference to the object in question call a method that tells the object in question that it is being referenced. This object would then add the referring object to a list. Whenever you give up your reference to that object, you call another method that would remove the referrer from the list.

C# .NET object disposal

Should be an easy one. Let's say I have the following code:
void Method()
{
AnotherMethod(new MyClass());
}
void AnotherMethod(MyClass obj)
{
Console.WriteLine(obj.ToString());
}
If I call "Method()", what happens to the MyClass object that was created in the process? Does it still exist in the stack after the call, even though nothing is using it? Or does it get removed immediately?
Do I have to set it to null to get GC to notice it quicker?

After the call to Method completes, your MyClass object is alive but there are no references to it from a rooted value. So it will live until the next time the GC runs where it will be collected and the memory reclaimed.
There is really nothing you can do to speed up this process other than to force a GC. However this is likely a bad idea. The GC is designed to clean up such objects and any attempt you make to make it faster will likely result in it being slower overall. You'll also find that a GC, while correctly cleaning up managed objects, may not actually reduce the memory in your system. This is because the GC keeps it around for future use. It's a very complex system that's typically best left to it's own devices.

If I call "Method()", what happens to the MyClass object that was created in the process?
It gets created on the GC heap. Then a reference to its location in the heap is placed on the stack. Then the call to AnotherMethod happens. Then the object's ToString method is called and the result is printed out. Then AnotherMethod returns.
Does it still exist in the stack after the call, even though nothing is using it?
Your question is ambiguous. By "the call" do you mean the call to Method, or AnotherMethod? It makes a difference because at this point, whether the heap memory is a candidate for garbage collection depends upon whether you compiled with optimizations turned on or off. I'm going to slightly change your program to illustrate the difference. Suppose you had:
void Method()
{
AnotherMethod(new MyClass());
Console.WriteLine("Hello world");
}
With optimizations off, we sometimes actually generate code that would be like this:
void Method()
{
var temp = new MyClass();
AnotherMethod(temp);
Console.WriteLine("Hello world");
}
In the unoptimized version, the runtime will actually choose to treat the object as not-collectable until Method returns, after the WriteLine. In the optimized version, the runtime can choose to treat the object as collectible as soon as AnotherMethod returns, before the WriteLine.
The reason for the difference is because making object lifetime more predictable during debugging sessions often helps people understand their programs.
Or does it get removed immediately?
Nothing gets collected immediately; the garbage collector runs when it feels like it ought to run. If you need some resource like a file handle to be cleaned up immediately when you're done with it then use a "using" block. If not, then let the garbage collector decide when to collect memory.
Do I have to set it to null to get GC to notice it quicker?
Do you have to set what to null? What variable did you have in mind?
Regardless, you do not have to do anything to make the garbage collector work. It runs on its own just fine without prompting from you.
I think you're overthinking this problem. Let the garbage collector do its thing and don't stress about it. If you're having a real-world problem with memory not being collected in a timely manner, then show us some code that illustrates that problem; otherwise, just relax and learn to love automatic storage reclamation.

Actually, the instance will be declared on the heap, but have a look at Eric Lipper's article, The Stack is an Implementation Detail.
In any case, because there will be no more references to the instance after the function executes, it will be (or, more accurately, can be) deleted by the garbage collector at some undefined point in the future. As to exactly when that happens, it's undefined, but you also (essentially) don't need to worry about it; the GC has complicated algorithms that help it determine what and when to collect.

Does it still exist in the stack after the call
Semantics are important here. You asked if it still exists on the stack after the method call. The answer there is "no". It was removed from the stack. But that's not the final story. The object does still exist, it's just no longer rooted. It won't be destroyed or collected until the GC runs. But at this point it's no longer your concern. The GC is much better at deciding when to collect something than you or I are.
Do I have to set it to null to get GC to notice it quicker?
There's almost never a good reason to do that, anyway. The only time that helps is if you have a very long running method and an object that you are done with early that otherwise won't go out of scope until the end of the method. Even then, setting it to null will only help in the rare case where the GC decides to run during the method. But in that case you're probably doing something else wrong as well.

In C# the new MyClass() is scoped only to live inside Method() while it is active. Once that AnotherMethod() is finished executing, it is out of scope and gets unrooted. It then remains on the heap until the GC runs its collection cycle and identifies it as an unreferenced memory block. So it is still "alive" on the heap but it is inaccessible.

The GC keeps track of what objects can possibly still be referenced later in the code. It then, at intervals, checks to see if there are any objects still alive that could not possibly be referenced later in the code, and cleans them up.
The mechanics of this are somewhat complex, and when these collections will happen depends on a variety of factors. The GC is designed to do these collections at the most optimal time (that it can establish) and so, while it is possible to force it to do a collection, it is almost always a bad idea.
Setting the variable to null will have very little overall effect on how soon the object is dealt with. While it can, in some small corner cases, be of benefit it is not worth littering your code with redundant assignments which will not affect your codes performance and only harm readability.
The GC is designed to be as effective as possible without you needing to think about it. To be honest, the only thing you really need to be mindful of is being careful when allocating really large objects that will stay alive for a long time, and that's generally quite rare in my experience.

As far as I know, the object is only valid inside your method context. After the method "Method()" is executed it is added to the dispose queue.