Program의 수행에서 CPU의 연산을 위해 Stack을 사용한다는 점에서 Stack의 Size가 제한되어 있다는 것은 개발자라면 항상 염두에 두고 있을 것이다. 그러므로, 무한 재귀 호출되는 Function이나 과도하게 Stack 상에다 Allocation한 후(일반적으로 Local variables나 parameters는 Stack에 저장된다.) Exception이나 비정상적인 operation으로 인하여 Stack이 unwind 되지 않는 다면, 예기치 않은 Stack overflow를 맞을 수 있다. 다음의 Stack overflow dump case를 예로 든다.

일단, 메모리덤프를 Open 하면, 대번 Stack Overflow임을 알 수 있다.

(24f8.f64): Stack overflow - code c00000fd (first/second chance not available)

eax=000900a0 ebx=00000000 ecx=08ac2bf0 edx=0e010026 esi=0e010024 edi=08aff134

eip=033f9577 esp=08afebe8 ebp=08afec1c iopl=0         nv up ei pl nz na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

*** WARNING: Unable to verify checksum for ttt.dll

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ttt.dll -

ttt!DllUnregisterServer+0x33a4:

033f9577 8501            test    dword ptr [ecx],eax  ds:0023:08ac2bf0=00000000

Stack Size는 다음과 같이 Check 할 수 있다.

0:066> !teb

TEB at 7fefd000

    ExceptionList:        08afec10

    StackBase:            08b00000

    StackLimit:           08ac1000

    SubSystemTib:         00000000

    FiberData:            00001e00

    ArbitraryUserPointer: 00000000

    Self:                 7fefd000

    EnvironmentPointer:   00000000

    ClientId:             000024f8 . 00000f64

    RpcHandle:            00000000

    Tls Storage:          7fefd02c

    PEB Address:          7ffd8000

    LastErrorValue:       0

    LastStatusValue:      c0150008

    Count Owned Locks:    0

    HardErrorMode:        0

0:066> ? 08b00000 - 08ac1000

Evaluate expression: 258048 = 0003f000

실제, Max Allocation할 수 있는 Stack Size를 확인해 보면, 대략 256k임을 확인할 수 있다. 이는 아래와 같은 TEB Structure의 DeallocationStack 값을 확인하면 되며, 이는 http://msdn.microsoft.com/en-us/library/cc267849.aspx 문서를 참조하거나 debugging tools for windows help에서 참조할 수 있다.

typedef struct _TEB {
    NT_TIB NtTib;
    PVOID  EnvironmentPointer;
    CLIENT_ID ClientId;
    PVOID ActiveRpcHandle;
    PVOID ThreadLocalStoragePointer;
    PPEB ProcessEnvironmentBlock;
    ULONG LastErrorValue;
    .....
    PVOID DeallocationStack;
    .....
} TEB;

0:066> dd 7fefd000+e0c L1

7fefde0c  08ac0000

0:066> ? 08b00000 - 08ac0000

Evaluate expression: 262144 = 00040000  <---- 256k Max allocation size

그러므로, 현재 사용하는 Stack은 3f000 으로 Max Stack Size, 40000 에 도달하고 있음을 확인할 수 있다.

원인을 찾기 위해선 무엇보다도 먼저 재귀 호출이 있는 지 확인이 필요한데, 이는 Callstack을 확인하는 작업이 필요할 듯 하다. 일단, 해당 case에서는 안타깝게도 해당 모듈에 대한 Symbol이 정확하지 않아서 확인이 불가능했으며, 정확한 symbol이 존재한다면 아래의 Callstack에서 확인된 Function을 Check해야 한다.

0:066> kbL

ChildEBP RetAddr  Args to Child             

WARNING: Stack unwind information not available. Following frames may be wrong.

08afec1c 033f4de9 0df4002c 08aff0fc 0000fde9 ttt!DllUnregisterServer+0x33a4 <-- Symbol이 맞지 않아서 이렇게 보이는 것임.

08aff118 033f40c8 0b056198 0b056228 00000000 ttt+0x4de9

08aff170 762e31eb 0b055f20 08aff124 08aff120 ttt+0x40c8

08aff198 7635184f 033f3e71 08aff3a0 00000005 rpcrt4!Invoke+0x2a

08aff5c4 7634fc79 09dae6f8 06afcbc8 018be228 rpcrt4!NdrStubCall2+0x27b

08aff614 760527f7 09dae6f8 018be228 06afcbc8 rpcrt4!CStdStubBuffer_Invoke+0xffffdd13

08aff638 76909759 09dae6f8 018be228 06afcbc8 oleaut32!CUnivStubWrapper::Invoke+0xc7

. . .

만일, Function의 무한 재귀호출에 의해서 Stack Overflow가 발생한 것이 아니라면, Stack에 allocation 패턴도 Check해야 한다.

0:066> dds esp

08afebe8  75f751ea kernel32!lstrlenW+0x56

08afebec  033f18c5 ttt+0x18c5

08afebf0  08aff134

08afebf4  0b0584a8

08afebf8  08aff148

08afebfc  01e62f00

08afec00  0b0584a8

08afec04  000cc09e

08afec08  08afec24

08afec0c  033f188b ttt+0x188b

08afec10  08aff10c

08afec14  0340c9f0 ttt!DllUnregisterServer+0x1681d

08afec18  00000000

08afec1c  08aff118

08afec20  033f4de9 ttt+0x4de9

08afec24  0df4002c

08afec28  08aff0fc

08afec2c  0000fde9

08afec30  0000007b

08afec34  0b055f20

08afec38  00000005

08afec3c  00000000

Callstack에서 문제가 발생한 시점이전의 최종 Return Address가 33f4de9 인데, 그 이후에 Stack address(상위 raw stack에서의 회색 블럭)는 local variables 또는 parameters 등으로 사용되므로, 이들 중 Allocation 패턴이 overflow를 의심하게 하는 것이 있는 지 Check가 필요하다.

0:066> dc 0b0584a8

0b0584a8  0340e448 0b0500c4 00000000 00000000  H.@.............

0b0584b8  ee7ff470 08002142 00000001 0000261c  p...B!.......&..

0b0584c8  0000261c 000a000d 006f0043 0074006e  .&......C.o.n.t.

0b0584d8  006e0065 002d0074 00790054 00650070  e.n.t.-.T.y.p.e.

0b0584e8  0020003a 006d0069 00670061 002f0065  :. .i.m.a.g.e./.

0b0584f8  00690067 003b0066 006e0020 006d0061  g.i.f.;. .n.a.m.

0b058508  003d0065 00630022 0069006c 005f0070  e.=.".c.l.i.p._.

0b058518  006d0069 00670061 00300065 00330030  i.m.a.g.e.0.0.3.

0:066> du 0b0584c8+8

0b0584d0  "Content-Type: image/gif; name="c"

0b058510  "lip_image003.gif"..Content-ID: <"

0b058550  "20090223.44575.001@tagfree.com>."

0b058590  ".Content-Transfer-Encoding: base"

0b0585d0  "64..Content-Location: file:///C:"

0b058610  "/DOCUME~1/jkim/LOCALS~1/Temp/mso"

0b058650  "html1/01/clip_image003.gif....R0"

0b058690  "lGODlhKwHTAHcAMSH+GlNvZnR3YXJlOi"

0b0586d0  "BNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAA"

0b058710  "AALBUACQAA..AcMAhgAAAAAAABoaTSYm"

0b058750  "czMzmWaAgIAzAICAAJaWlpm/v5/P/57O"

0b058790  "/53O/5zN/5vN/5rM/5nM/79N..AL/d/7"

0b0587d0  "7d/7zc/7vb/7ra/7na/73c/7jZ/7fZ/7"

0b058810  "bY/7XY/7TY/7PX/7LX/7DW/6/W/7TX/6"

0b058850  "/V/67V../63U/6vT/6rT/6nT/6jT/6zU"

0b058890  "/6vU/6fS/6bS/6bR/6XR/6TQ/6PQ/6LQ"

0b0588d0  "/6HP/6DP/8Tf/8Le/8He../8De/8Pf/8"

0b058910  "z//9/u/97t/93s/9zr/9vr/9rq/9nq/9"

0b058950  "jq/9rr/9bp/9Xo/9Tn/9fp/9Lm/9Hm/8"

0b058990  "/l../9Pn/87l/83k/9Dm/8zj/8vj/8ni"

0b0589d0  "/8ji/8fh/8bh/8Xg//9mAP//AP//zP7/"

0b058a10  "//7+//3+//z9//v9..//v8//r8//n8//"

0b058a50  "j7//f7//b6//X5//T4//P4//L4//H3//"

. . .<중략>

그러므로, 만일, 상위에서 보여주는 몇몇의 data가 과도한 Allocation이나 Allocation 패턴에 의해서 문제 상황을 가져오지는 않는 지는 최종적으로 Source Code를 통해서 확인해봐야 하며, 그러기 위해서는 정확한 Symbol의 match가 중요함을 잊지 말아야 한다.