A strange problem that happens when garbage collection occurs

A few days ago in the forum saw a post garbage collection problem--is not a bug the problem is as follows:

static tc gto;
public class tc
{
public int a=99;
~tc()
{
a=-1; //set breakpoint 1
gto=this;
}
}
private void button1_Click(object sender,EventArgs e)
{
tc to=new tc();
GC.Collect();
GC.WaitForPendingFinalizers();
return; // set breakpoint 2
}
two problems:
click button once,it seem the ~tc() not execute at all.and it will excute at the second time clicking.why?
the second clicking,breakpoint 2, "gto" and "to", gto.a=-1,while to.a=99,why?

It's a good question. The first time forced recovery can not be recycled local variables to, only the next click on the last generated TC objects will be recycled so ~TC () did not immediately execute. The second problem is because the object's a is set to 1 in the destructor and the reference is assigned to a global object so gto.a=-1, and the new out of the TC object a nature of 99. I had confidence in the answer to the first question, but when I was about to answer the question I saw Gomoku's reply, He said:

1, when debugging, Visual Studio provides the ability to display the value of the time, such as allowing your breakpoint 2 to check the values of the TC.

To check the value of the TC, which requires that the TC cannot be garbage collected, the Visual Studio debugger inserts special code to ensure that the TC is not reclaimed until it leaves Button1_Click ().

The 2,release version is different. When you run the example with release, you will find that, contrary to debug, ~TC () was invoked the first time gc.collect.

I immediately carried out the experiment and found that, as Gomoku said, I had doubts about my understanding. Because I'm sure it's not about the breakpoint on Vs, and msdn,.net books, domestic and foreign technical articles in explaining the garbage collection principle is so explained. "At the beginning the GC treats objects on the managed heap as recyclable, then looks for the unreachable object from the application's set of roots, and the inaccessible object is reclaimed. The JIT compiler and CLR runtime maintain a list of root pointers, mainly including global variables, static variables, local variables, and register pointers. So I think even if the release under the same and debug performance, unless the release under the optimization operation will not save this local variable. So I'm looking at the debug and release two versions of Il right away.

Debug

IL_0000: nop
IL_0001: newobj tc::.ctor
IL_0006: stloc.0
IL_0007: call System.GC::Collect
IL_000c: nop
IL_000d: call System.GC::WaitForPendingFinalizers
IL_0012: nop
IL_0013: br.s IL_0015
IL_0015: ret

Release

ilAddr = 01394590
IL_0000: newobj tc::.ctor
IL_0005: pop
IL_0006: call System.GC::Collect
IL_000b: call System.GC::WaitForPendingFinalizers
IL_0010: ret