gflags.exe

Heap Corruption에 대한 gflags의 설정

Heap은 Code에서 사용하는 Memory Block으로 Application에서 메모리 할당이나 해제 시 잘못된 사용으로 인하여 Corruption이 발생할 수 있다. 일반적인 Heap corruption이 발생하는 경우는 다음과 같다.

²  Buffer overrun

²  Buffer underrun

²  Double Free

²  Free block에 대한 access

²  메모리 재사용에 대한 문제, (예를 들어, 메모리를 free하고 동일한 size를 재사용할 때, 동일한 address가 잡힐 것이라는 기대감에서 발생할 수 있는 문제. 등등

 

Heap Corruption 은 임의의 Heap block이 깨진 이후 다른 시점에 Allocation이나 Memory 사용시 예기치 않게 Access Violation이 발생할 수 있기 때문에 AV 순간 Crash dump를 수집한다고 해도 해당 Callstack이 문제 근원이 되는 Callstack이 아닐 가능성이 매우 크다. 이를 위해서 Gflags 는 allocation을 Check하도록 설정하여 잘못된 사용시 이를 Debugger를 통해 알려줄 수 있도록 도와준다.

 

-       Normal Pageheap

²  free될 때만 allocation check

²  gflags –p /enable CrashApp.exe

²  High Memory usage의 process를 위해서는 “gflags.exe –p /enable lsass.exe /decommit /random 20” 를 이용할 수 있다. random 20은 20% 만 pageheap이 enable 된다는 의미.

 

-       Full Pageheap

²   No access pages를 사용하여 Allocation block에 padding

²  gflags –p /enable CrashApp.exe /full

²  만일, /decommit option을 이용하면, Memory를 1/2 로 줄일 수 있다.

n  gflags –p /enable CrashApp.exe /full /decommit

n  decommit 은 No access pages 대신에 reserved virtual memory zone을 이용함.

 

Heap이 깨졌다는 것은 어떻게 알까? 먼저, AV crash dump를 확인하고, Heap corruption 여부를 확인하여 다시 Crash dump를 수집하게 된다. 간혹, 다음과 같은 Function stack에서 AV가 발생하는 것을 볼 수 있다.

ntdll!RtlpCoalesceFreeBlocks+0x10c
ntdll!RtlFreeHeap+0x142
. . .

또는

ntdll!RtlpCoalesceFreeBlocks+0x10c
ntdll!RtlpExtendHeap+0x1c1
ntdll!RtlAllocateHeap+0x3b6
. . .

그리고, 문제가 발생한 Address의 heap을 Check해봤을 때 (“!heap –x <address>” command를 수행) Heap block size가 이상하거나 bad pointer(garbage allocation data 또는 알 수 없는 영역)로 의심이 간다면, Heap corruption을 조심스레 의심해 볼 수 있다.

 

Pageheap에 따른 Heap block의 구조는 아래의 문서를 참조한다. 중요한 것은 Block header나 suffix bytes 인데, 이는 Heap block이 Allocated된 것인지 Free된 것인지를 확인할 수 있는 정보가 된다.

//// http://msdn.microsoft.com/en-us/library/cc266933.aspx발췌...