Why does a WinForm stay in memory if the local reference var goes out
of scope?

Hello all,

After programming in C# and VB.NET for 4 years, it finally dawned upon
me that something Very Fishy is going on when you create a second
form. Why does it stay in memory when the form-variable goes out of
scope?

In FormMain I have a cmdOpenFormTest with this event handler:

cmdOpenFormTest_Click(object sender, EventArgs e)
{
   FormTest frm = new FormTest();
   frm.Show();
   //for this test we do NOT do frm.Close() or frm.Dispose()
   //you may leave next line out, doesn't make a difference
   frm = null;
}

FormTest is a form with nothing on it, not even a button. I could even
have done, with the same effect:
Form frm = new Form();

A second button on FormMain allows me to do GC.Collect();
GC.WaitForPendingFinalizers(); GC.Collect();

Now the questions:
* why does FormTest stay visible when its variable has gone out of
scope a long time ago? Even after GC.Collect()?
*  Why doesn't the garbage collector kick in?
* Why doesn't base.Finalize() run, that is, the base-base-base class's
destructor?
* Why don't we see .Dispose(false) running?

----------

There is a lot of interesting talk in the newsgroups about what's
going on after frm.Close() and frm.Dispose().
frm.Close does a this.SendMessage(WM_CLOSE), just like in a Charles
Petzold C Windows program. This comes back to the form in the
WMClose() handler. Here, if I'm not mistaken (can look it up in
Reflector), after some work .Dispose() is called, leading to
Dispose(true), leading to the cleanup of all the unmanaged resources,
underlying windows & window handles, and the like.

There is also interesting talk about mem leakes related to a static
hashtable with MenuItem's and references that don't go away.

But in my case I do NOT call Close() or Dispose(). Who is keeping a
root reference to FormTest?

In the old days, using Access 95 and 97, the behaviour was as
expected: if you created a second form with a local form-variable, the
newly created form would immediately disappear after the local var
went out of scope.

I tried to figure things out with the CLR Memory Profiler from the
msdn website, but I saw a lot of colourful lines and no clear call
stack.

Any ideas?!?!?!?!?

Ernesto

"You don't have to learn science if you don't feel
like it. So you can forget the whole business if
it is too much mental strain, which it usually is."

  Richard Feynman