First Chance Exception, Second Chance Exception, WinDBG

所有Managed异常的HRESULT都是0xE0434352（无法用Error Lookup找到这个Error Code）。
通常在Event Log或者WinDBG所见到的Managed异常如下：
CLR exception - code e0434352

通常情况下First Chance Exception不是真正能导致程序Crash的异常，通常这个异常可以通过try…catch来捕获。只有当这个异常无法被捕获时才会升级为Second Chance Exception，这个异常会导致Crash。

可以用过WinDBG的命令sxe e0434352来使Debugger在First Chance Exception的时候Break。

继续Debug

可以看出Thread 4出现了一个System.Exception，还能看出这是一个First Chance Exception。

WinDBG报了Second Chance Exception，这导致了程序Crash。

慢慢玩儿，有点意思。

Managed Object Memory Layout

汇总学到的知识才是对上一年最好的总结。

CLR中的Object的Memory Layout是由一个4 byte的Syncblk，一个4 byte的TypeHandle以及之后的Instance Fields之类组成的。TypeHandle中又包含了重要的MethodTable和EEClass数据结构，这两个数据结构的实例对一个Type来说都只有一个。

通过Windbg来观察这个Object，首先找到这个Object的reference：

然后dd 0x0184274 - 0x4，ObjetRef实际上是指向TypeHandle而非Syncblck，所以需要减4。

这里可以看出Syncblk的值是08000001，TypeHandle是00233090，之后的三个是instance的值，分别是10,5,10。

TypeHandle是一个指向MethodTable的指针。

再一次通过Windbg来看这个指针的内容:

通过观察可以发现示意图似乎不准确，可能实现细节改过了。00232c5c才是一个指向EEClass的指针，002312a8是一个指向Module的指针。之后似乎又有4个连续的指针地址：594f6a90 -> 595674c0，这四个其实是4个method。看过Raw memory之后再用过sos来看看这个MethodTable

又见到了594f6a90这个地址，先看看这个的MSIL:

似乎是一个ToString()，再来看看sos:

两者一致。继续用sos来观察这个EEClass和Module两个数据结构。

这只是所有Managed Object中的一小部分，很多内容还有待挖掘。