CLR 환경하에서 수행되는 Managed Application 경우, CLR에서 제공하는 GC는 Memory를 관리해주는 Component 다. Application에서 Memory를 할당 받을 때, GC에 적절한 memory를 할당 받을 수 있는 지 확인한 후에, (보통은 할당 받을 수 있는 Memory Size 정도의 정보를 요청할지 모른다) 가능하다면, Memory를 할당 하고, 그렇지 않을 경우에, 보통은 GC가 running 하게 된다. GC는 Memory Fragmentation을 줄이기 위해 Compaction이나 Sweeping 같은 작업을 하거나 필요에 의해 추가적인 Segment 를 만들지도 모른다. 이러한 작업을 하는 동안에는 필요에 따라서 Threads 들을 suspension 한다. Thread가 suspended 된다는 것은 사용자 입장에서 보면, 작업이 멈춰진(Hang) 것으로 인식한다. 그러므로, GC가 돌면, Hang을 경험할 수 있다. Hang Dump 상에서는 다음과 같은 Callstack이 GC running에 의해서 Wait 하고 있는 Threads들이라고 보면 된다.

0:033> kL

ChildEBP RetAddr 

18e9eb04 77e7a0a2 NTDLL!NtWaitForSingleObject+0xb

18e9eb2c 77e5b40f KERNEL32!WaitForSingleObjectEx+0x71

18e9eb3c 79208383 KERNEL32!WaitForSingleObject+0xf

18e9eb48 792083d4 mscorsvr!GCHeap::WaitUntilGCComplete+0x4f

18e9eb58 791fbd68 mscorsvr!Thread::RareDisablePreemptiveGC+0xb5

18e9ebec 17723675 mscorsvr!JITutil_MonContention+0xd7

WARNING: Frame IP not in any known module. Following frames may be wrong.

18e9ebf0 01f664f4 0x17723675

18e9ebf4 17b10f28 0x1f664f4

18e9ebf8 0d7c8dc4 0x17b10f28

18e9ebfc 01f66614 0xd7c8dc4

18e9ec00 18e9f8f8 0x1f66614

18e9ec04 0283a990 0x18e9f8f8

18e9f980 791c137c 0x283a990

18e9f98c 024c5f2c mscorsvr!COMString::EqualsString+0x3f

18e9f994 010eb9b2 0x24c5f2c

18e9f998 05e3534c 0x10eb9b2

18e9f99c 05e59638 0x5e3534c

18e9f9a0 05e3520c 0x5e59638

18e9f9a4 00000000 0x5e3520c

그리고, GC가 뭔가 작업을 하고 있다면, 아래와 같은 Callstack이 보일 수도 있다 (외에 Mark, Sweep, 기타 등등 GC 관련 Func Name ... ) 

28c9f438 791b7c1a mscorsvr!gc_heap::adjust_limit_clr+0x17c

28c9f474 791b7cb4 mscorsvr!gc_heap::allocate_more_space+0x47e

28c9f69c 791bb333 mscorsvr!GCHeap::Alloc+0x7b

28c9f6b0 791b7579 mscorsvr!Alloc+0x3a

28c9f6d0 791b751a mscorsvr!FastAllocatePrimitiveArray+0x45

28c9f750 0c2d7ab6 mscorsvr!JIT_NewArr1+0xbb

WARNING: Frame IP not in any known module. Following frames may be wrong.

28c9f754 28c9f7a8 0xc2d7ab6

28c9f758 053faa7c 0x28c9f7a8

28c9f7a8 1713517d 0x53faa7c

28c9f8c8 7923cd4b 0x1713517d

28c9f93c 792403e6 mscorsvr!ComToComPlusWorker+0x1e0

28c9f97c 791cf976 mscorsvr!ComToComPlusWorker_Wrapper+0x38

28c9f9c4 7923ff03 mscorsvr!Thread::DoADCallBack+0x5c

28c9fa2c 0126a0bd mscorsvr!ComToComPlusWorker+0x65

28c9fb74 77fb2c8a 0x126a0bd

28c9fba0 77fcb7c2 NTDLL!RtlpFreeToHeapLookaside+0x4a

28c9fc44 00000000 NTDLL!RtlFreeHeap+0xf8

만일, 대부분의 Threads가 GCHeap::WaitUntilGCComplete 상태로 있다면, 이는 GC running이 끝날 때까지 대부분의 Threads가 기다리고 있다는 의미이므로, 얼마나 이 상태가 지속되고 있는 지 Check 해 볼 필요가 있다. 그리고, Hang 상태가 User가 견디기 어려울 정도라면, GC thread를 Check하여 왜 GC thread가 오랫동안 수행되고 있는 지를 확인하는 것이 좋을 것이다. GC heap이 corruption(!verifyheap check)이 되었거나, Thread가 Looping code를 갖고 있거나(!clrstack check) 또는 GEN2의 Object가 대량으로 쌓여있어서 GC가 Collection 하는 데, 시간이 걸릴(!dumpheap check) 수 밖에 없을 수도 있다.