Monthly Archive for 9월, 2008

Stack Overflow and Bugcheck 7F ( UNEXPECTED_KERNEL_MODE_TRAP )

Published
by
admin
on 9월 22, 2008
in Debugging Windows
. 0 Comments

일반적으로 Stack overflow가 발생한 Bugcheck의 크개 아래와 같은 2가지 종류가 있습니다.

1. UNEXPECTED_KERNEL_MODE_TRAP (7F), PANIC_STACK_SWITCH(2B)
2. KMODE_EXCEPTION_NOT_HANDLED(1E), SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(7E), KERNEL_MODE_EXCEPTION_NOT_HANDLED(8E)

첫 번째 경우는 개발자의 Code상의 문제로 실제 Stack Overflow가 발생한 경우 이고 두번째 경우는 Exception Trap이 발생 하면 Trap 데이터를 Stack에 저장하다가 발생하는 경우입니다. 물론 첫번째 경우도 두번째 경우와 같은 현상이 발생하기 때문에 EXCEPTION_DOUBLE_FAULT이 Parameter에 나타납니다.

Windows 커널의 Thread Stack의 경우는 각 Platform 별로 각각 일정한 제한을 가지게 됩니다. ( DPC는 예외임 DPC의 경우는 Platform에 할당된 DPC Stack을 사용하기 때문 )

1. x86 - 12K
2. x64 - 24K
3. IA64 - 32K

이러한 Platform 별 Stack의 Size는 최소한의 크기이기 때문에 위에 설명한 Exception들은 종종 많이들 발생하곤합니다. 간단한 예로 File System의 경우 Special APC가 Delivery 되어 재귀 호출이 발생하는 경우라던지 또는 NDIS Stack에 여러개의 Filter Driver가 올라와 발생하는 경우 가 대표적이지요.

이론은 이정도로 마무리하고 실전에서 발생한 예를 한가지 보도록 하죠.

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 89316130
Arg3: 00000000
Arg4: 00000000

Debugging Details:
——————

PEB is paged out (Peb.Ldr = 7ffdb00c). Type “.hh dbgerr001″ for details
PEB is paged out (Peb.Ldr = 7ffdb00c). Type “.hh dbgerr001″ for details

BUGCHECK_STR: 0×7f_8

TSS: 00000028 — (.tss 0×28)
eax=9fcbe414 ebx=00000000 ecx=9fcbe488 edx=00000000 esi=9fcbe49c edi=9fcbe49c
eip=826700d6 esp=9fcbdf9c ebp=9fcbe3f0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!_woutput_l+0×1b:
826700d6 57 push edi
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: spoolsv.exe

CURRENT_IRQL: ba

LAST_CONTROL_TRANSFER: from 82670b50 to 826700d6

STACK_TEXT:
9fcbe3f0 82670b50 9fcbe414 8313a924 00000000 nt!_woutput_l+0×1b
9fcbe434 82670bb0 9fcbe49c 00000063 8313a924 nt!_vsnwprintf_l+0×7b
9fcbe450 83131038 9fcbe49c 00000063 8313a924 nt!_vsnwprintf+0×18
9fcbe474 83137056 9fcbe49c 000000c8 8313a924 volmgr!StringCbPrintfW+0×3a
9fcbe568 83139c95 87269960 84eaea30 84eaea30 volmgr!VmpQueryDeviceName+0×46
9fcbe5a0 826ff053 872698a8 84eaec08 00000000 volmgr!VmDeviceControl+0×237
9fcbe5b8 8899a640 9fcbe5d8 8899a7d7 872690a0 nt!IofCallDriver+0×63
9fcbe5c0 8899a7d7 872690a0 84eaea30 84eaec08 fvevol!FveFilterSkip+0×1e
9fcbe5d8 826ff053 872690a0 84eaea30 00000000 fvevol!FveFilterDeviceControl+0×18d
9fcbe5f0 8896c81f 9fcbe654 88979d58 8741b020 nt!IofCallDriver+0×63
9fcbe5f8 88979d58 8741b020 84eaea30 84eaea30 ecache!EcDispatchPassthrough+0×43
9fcbe654 826ff053 8741b020 84eaea30 84eaec2c ecache!EcDispatchDeviceControl+0×3e
9fcbe66c 88947470 00000000 8741c020 00000000 nt!IofCallDriver+0×63
9fcbe690 826ff053 84eaec08 84eaea30 9e27cdb0 volsnap!VolSnapDeviceControl+0×42
9fcbe6a8 831ab472 00000000 85cdec48 00000000 nt!IofCallDriver+0×63
9fcbe784 831ab7a4 00cdec48 9fcbe7ec 9fcbe7b8 mountmgr!QueryDeviceInformation+0×2a2
9fcbe7c4 831af2e0 85cdec48 9fcbe7ec 00000000 mountmgr!FindDeviceInfo+0×3a
9fcbe80c 831b3858 85cdec48 b0ac4b70 00000103 mountmgr!MountMgrQueryDosVolumePath+0×6c
9fcbe828 826ff053 85cdec64 b0ac4be0 00000200 mountmgr!MountMgrDeviceControl+0×8c
9fcbe840 82803038 9fcbf0d4 0000002e 9fcbf1c4 nt!IofCallDriver+0×63
9fcbf0a4 b3ceb5e3 872698a8 9fcbf0cc b5a78048 nt!IoVolumeDeviceToDosName+0×145
WARNING: Stack unwind information not available. Following frames may be wrong.
9fcbf1a4 b3ceb7c6 9fcbf1c4 00000068 9fcbf438 NpIdsVt+0×65e3
9fcbf420 b3ceb83d 00000704 9fcbf438 0000000b NpIdsVt+0×67c6
9fcbf694 b3ce8d1e 00000704 b5a78048 9fcbf734 NpIdsVt+0×683d
9fcbf6bc 833b6409 9fcbf9a8 00000000 b0da3538 NpIdsVt+0×3d1e
9fcbf704 833b604f 00000004 9fcbf9a8 9fcbf880 NETIO!ProcessCallout+0×10e
9fcbf774 833b61e9 00000004 9fcbf9a8 9fcbf880 NETIO!ArbitrateAndEnforce+0xaa
9fcbf858 88668410 00000004 9fcbf9a8 9fcbf880 NETIO!KfdClassify+0×16f
9fcbf9c0 88664dc9 97c31094 9fcbfd2c 87ff1ba0 tcpip!ShimIpPacketOutV4+0×15b
9fcbf9f4 88668599 00000000 97c31094 9fcbfd2c tcpip!IppInspectLocalPacketsOut+0×5c
9fcbfaf8 88663c48 9fcbfc88 87ff13f8 9fcbfc88 tcpip!Ipv4pFragmentPacketHelper+0×12d
9fcbfb34 8866399b 886c8c68 00000000 00000000 tcpip!IppFragmentPackets+0xbd
9fcbfb6c 8866578b 886c8c68 97d020c0 616c7049 tcpip!IppDispatchSendPacketHelper+0×252
9fcbfc0c 88664bff 00cbfc88 00000000 8f1f5938 tcpip!IppPacketizeDatagrams+0×8fd
9fcbfd6c 8865dcab 00000000 00000004 886c8c68 tcpip!IppSendDatagramsCommon+0×5f9
9fcbfd8c 8865eb19 8624bed0 9fcbfe88 8ffa0a50 tcpip!IpNlpSendDatagrams+0×4b
9fcbffd4 8d4dfcf2 8ffb0020 8623f8c0 8ffa0a50 tcpip!UdpSendMessages+0xc07
9fcc001c 8d4e79be 92d75de0 8ffa0a00 92c90078 tdx!TdxSendDatagramTransportAddress+0×206
9fcc0038 826ff053 87dbca10 8ffa0a50 8ffa0b2c tdx!TdxTdiDispatchInternalDeviceControl+0×5c
9fcc0050 8d505723 00000000 af3c32e8 b2262d90 nt!IofCallDriver+0×63
9fcc0064 8d4f5b30 af3c32e8 b0be4e58 ffffffff SYMTDI!isManualStart+0×253
9fcc0080 8d5084fc 8ea15af8 b2262d90 000000c8 SYMTDI!DbgTrace+0×900
9fcc00a0 8d4f5de7 b0be4e58 8ffa0a50 af3c32e8 SYMTDI!DisconnectTCPSession+0×1c6c
9fcc00e4 8d505d22 af3c32e8 9fcc0108 9fcc0178 SYMTDI!DbgTrace+0xbb7
9fcc010c 8d505dba 87f59020 8ffa0a50 9fcc0134 SYMTDI!isManualStart+0×852
9fcc011c 826ff053 87f59020 8ffa0a50 b0d59480 SYMTDI!isManualStart+0×8ea
9fcc0134 8de0e8bf 87fc3d78 953b92c0 8de28e84 nt!IofCallDriver+0×63
9fcc0150 8de0e72f 00000000 87fc3e74 00000032 netbt!TdiSendDatagram+0×14e
9fcc0194 8de0e5c5 87fc3d78 c0a800ff 00000032 netbt!UdpSendDatagram+0×14c
9fcc01dc 8de12ed1 87fc3d78 b0a831e8 0057fed0 netbt!SendNameServiceRequest+0×2a1
9fcc0228 8de12adf b0b14aec 87751b48 000002ee netbt!QueryNameOnNet+0×376
9fcc026c 8de0a5bb b0b14aec 87ffe990 8de0994a netbt!FindNameOrQuery+0×463
9fcc02dc 8de0b093 00000000 00000000 87ffebb8 netbt!NbtConnectCommon+0×79c
9fcc02fc 8de0ae4b 9fcc0324 8f9ad200 a914d2cc netbt!NbtConnect+0×114
9fcc034c 8de086d2 87ffe990 92d4e1b0 a914d2b0 netbt!NTConnect+0×1a2
9fcc0368 826ff053 e0ffe990 92d4e268 00000000 netbt!NbtDispatchInternalCtrl+0×16d
9fcc0380 8de2aa64 8de28440 a914d2b0 92d4e1b0 nt!IofCallDriver+0×63
9fcc0398 8de0ae09 00000000 92d4e1b0 00000000 netbt!DelayedNbtProcessConnect+0×100
9fcc03e8 8de086d2 87ffe990 00000000 8f1fb7c0 netbt!NTConnect+0×160
9fcc0404 826ff053 e0ffe990 8f1fb878 87f48c08 netbt!NbtDispatchInternalCtrl+0×16d
9fcc041c 8f9a3081 97d4c150 97d4c164 a9a9b770 nt!IofCallDriver+0×63
9fcc0464 8f9a286f 00000103 00000003 97d4c150 mrxsmb!RxTdiInitiateAsynchronousConnect+0×1e8
9fcc047c 8f9b010f 01a9b770 1056c34d 00000000 mrxsmb!RxCeInitiateConnectRequest+0×38
9fcc04dc 8f9afc30 87eb63d8 00000000 a9a9b770 mrxsmb!RxCeBuildConnectionOverMultipleTransports+0×266
9fcc0524 8f9af557 af21b458 00000000 b0b7b05c mrxsmb!VctEstablishConnection+0×2dd
9fcc0560 8f9a3491 b0b7b010 b0b7b010 b0b7b0cc mrxsmb!SmbCeEstablishNegotiatedConnection+0×112
9fcc058c 8f9af8f2 b0b7b010 92db8398 92db83a8 mrxsmb!SmbCepEstablishServerConnection+0×54
9fcc05b4 8f9af67a 00000000 9fcc05dc 8df51a1e mrxsmb!SmbCeCreateSrvCall+0×19e
9fcc05c0 8df51a1e a9bffcc0 84f11878 8df43188 mrxsmb!MRxSmbCreateSrvCall+0×23
9fcc05dc 8df53eb6 87eb6570 b23d8718 a9bffcc0 rdbss!RxConstructSrvCall+0xe2
9fcc0650 8df54186 b2287488 b23d8718 9fcc0778 rdbss!RxFindOrCreateConnections+0×819
9fcc0698 8df46c6d b2287488 b23d8718 9fcc0778 rdbss!RxConstructVirtualNetRoot+0×68
9fcc074c 8df5345b b2287488 b23d8718 9fcc0778 rdbss!RxFindOrConstructVirtualNetRoot+0×492
9fcc0794 8df5367f b2287401 8df53521 b2287488 rdbss!RxPrefixClaim+0×18c
9fcc07b4 8df2d8e7 b2287488 0000ec23 12380e95 rdbss!RxCommonDevFCBIoCtl+0×15e
STACK_COMMAND: .tss 0×28 ; kb

FOLLOWUP_IP:
volmgr!StringCbPrintfW+3a
83131038 83c410 add esp,10h

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: volmgr!StringCbPrintfW+3a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: volmgr

IMAGE_NAME: volmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47918f7f

FAILURE_BUCKET_ID: 0×7f_8_volmgr!StringCbPrintfW+3a

BUCKET_ID: 0×7f_8_volmgr!StringCbPrintfW+3a

Followup: MachineOwner
———

일단 2개의 3th Part Driver를 확인 할 수 있습니다.  그리고 UNEXPECTED_KERNEL_MODE_TRAP (7f)과 EXCEPTION_DOUBLE_FAULT가 보여지는것으로 Stack Overflow의 전형적인 모습이라는것을 알 수 있죠 .

2: kd> kvnf 100
# Memory ChildEBP RetAddr Args to Child
00 00000000 826700d6 00000000 00000000 00000000 nt!KiTrap08+0x75 (FPO: TSS 28:0)
01 9fcbe3f0 9fcbe3f0 82670b50 9fcbe414 8313a924 00000000 nt!_woutput_l+0×1b (FPO: [Non-Fpo])
02 44 9fcbe434 82670bb0 9fcbe49c 00000063 8313a924 nt!_vsnwprintf_l+0×7b (FPO: [Non-Fpo])
03 1c 9fcbe450 83131038 9fcbe49c 00000063 8313a924 nt!_vsnwprintf+0×18 (FPO: [Non-Fpo])
04 24 9fcbe474 83137056 9fcbe49c 000000c8 8313a924 volmgr!StringCbPrintfW+0×3a (FPO: [Non-Fpo])
05 f4 9fcbe568 83139c95 87269960 84eaea30 84eaea30 volmgr!VmpQueryDeviceName+0×46 (FPO: [Non-Fpo])
06 38 9fcbe5a0 826ff053 872698a8 84eaec08 00000000 volmgr!VmDeviceControl+0×237 (FPO: [Non-Fpo])
07 18 9fcbe5b8 8899a640 9fcbe5d8 8899a7d7 872690a0 nt!IofCallDriver+0×63
08 8 9fcbe5c0 8899a7d7 872690a0 84eaea30 84eaec08 fvevol!FveFilterSkip+0×1e (FPO: [Non-Fpo])
09 18 9fcbe5d8 826ff053 872690a0 84eaea30 00000000 fvevol!FveFilterDeviceControl+0×18d (FPO: [Non-Fpo])
0a 18 9fcbe5f0 8896c81f 9fcbe654 88979d58 8741b020 nt!IofCallDriver+0×63
0b 8 9fcbe5f8 88979d58 8741b020 84eaea30 84eaea30 ecache!EcDispatchPassthrough+0×43 (FPO: [Non-Fpo])
0c 5c 9fcbe654 826ff053 8741b020 84eaea30 84eaec2c ecache!EcDispatchDeviceControl+0×3e (FPO: [Non-Fpo])
0d 18 9fcbe66c 88947470 00000000 8741c020 00000000 nt!IofCallDriver+0×63
0e 24 9fcbe690 826ff053 84eaec08 84eaea30 9e27cdb0 volsnap!VolSnapDeviceControl+0×42 (FPO: [Non-Fpo])
0f 18 9fcbe6a8 831ab472 00000000 85cdec48 00000000 nt!IofCallDriver+0×63
10 dc 9fcbe784 831ab7a4 00cdec48 9fcbe7ec 9fcbe7b8 mountmgr!QueryDeviceInformation+0×2a2 (FPO: [Non-Fpo])
11 40 9fcbe7c4 831af2e0 85cdec48 9fcbe7ec 00000000 mountmgr!FindDeviceInfo+0×3a (FPO: [Non-Fpo])
12 48 9fcbe80c 831b3858 85cdec48 b0ac4b70 00000103 mountmgr!MountMgrQueryDosVolumePath+0×6c (FPO: [Non-Fpo])
13 1c 9fcbe828 826ff053 85cdec64 b0ac4be0 00000200 mountmgr!MountMgrDeviceControl+0×8c (FPO: [Non-Fpo])
14 18 9fcbe840 82803038 9fcbf0d4 0000002e 9fcbf1c4 nt!IofCallDriver+0×63
15 864 9fcbf0a4 b3ceb5e3 872698a8 9fcbf0cc b5a78048 nt!IoVolumeDeviceToDosName+0×145
WARNING: Stack unwind information not available. Following frames may be wrong.
16 100 9fcbf1a4 b3ceb7c6 9fcbf1c4 00000068 9fcbf438 NpIdsVt+0×65e3
17 27c 9fcbf420 b3ceb83d 00000704 9fcbf438 0000000b NpIdsVt+0×67c6
18 274 9fcbf694 b3ce8d1e 00000704 b5a78048 9fcbf734 NpIdsVt+0×683d
19 28 9fcbf6bc 833b6409 9fcbf9a8 00000000 b0da3538 NpIdsVt+0×3d1e
1a 48 9fcbf704 833b604f 00000004 9fcbf9a8 9fcbf880 NETIO!ProcessCallout+0×10e (FPO: [Non-Fpo])
1b 70 9fcbf774 833b61e9 00000004 9fcbf9a8 9fcbf880 NETIO!ArbitrateAndEnforce+0xaa (FPO: [Non-Fpo])
1c e4 9fcbf858 88668410 00000004 9fcbf9a8 9fcbf880 NETIO!KfdClassify+0×16f (FPO: [Non-Fpo])
1d 168 9fcbf9c0 88664dc9 97c31094 9fcbfd2c 87ff1ba0 tcpip!ShimIpPacketOutV4+0×15b (FPO: [Non-Fpo])
1e 34 9fcbf9f4 88668599 00000000 97c31094 9fcbfd2c tcpip!IppInspectLocalPacketsOut+0×5c (FPO: [Non-Fpo])
1f 104 9fcbfaf8 88663c48 9fcbfc88 87ff13f8 9fcbfc88 tcpip!Ipv4pFragmentPacketHelper+0×12d (FPO: [Non-Fpo])
20 3c 9fcbfb34 8866399b 886c8c68 00000000 00000000 tcpip!IppFragmentPackets+0xbd (FPO: [Non-Fpo])
21 38 9fcbfb6c 8866578b 886c8c68 97d020c0 616c7049 tcpip!IppDispatchSendPacketHelper+0×252 (FPO: [Non-Fpo])
22 a0 9fcbfc0c 88664bff 00cbfc88 00000000 8f1f5938 tcpip!IppPacketizeDatagrams+0×8fd (FPO: [Non-Fpo])
23 160 9fcbfd6c 8865dcab 00000000 00000004 886c8c68 tcpip!IppSendDatagramsCommon+0×5f9 (FPO: [Non-Fpo])
24 20 9fcbfd8c 8865eb19 8624bed0 9fcbfe88 8ffa0a50 tcpip!IpNlpSendDatagrams+0×4b (FPO: [Non-Fpo])
25 248 9fcbffd4 8d4dfcf2 8ffb0020 8623f8c0 8ffa0a50 tcpip!UdpSendMessages+0xc07 (FPO: [Non-Fpo])
26 48 9fcc001c 8d4e79be 92d75de0 8ffa0a00 92c90078 tdx!TdxSendDatagramTransportAddress+0×206 (FPO: [Non-Fpo])
27 1c 9fcc0038 826ff053 87dbca10 8ffa0a50 8ffa0b2c tdx!TdxTdiDispatchInternalDeviceControl+0×5c (FPO: [Non-Fpo])
28 18 9fcc0050 8d505723 00000000 af3c32e8 b2262d90 nt!IofCallDriver+0×63
29 14 9fcc0064 8d4f5b30 af3c32e8 b0be4e58 ffffffff SYMTDI!isManualStart+0×253
2a 1c 9fcc0080 8d5084fc 8ea15af8 b2262d90 000000c8 SYMTDI!DbgTrace+0×900
2b 20 9fcc00a0 8d4f5de7 b0be4e58 8ffa0a50 af3c32e8 SYMTDI!DisconnectTCPSession+0×1c6c
2c 44 9fcc00e4 8d505d22 af3c32e8 9fcc0108 9fcc0178 SYMTDI!DbgTrace+0xbb7
2d 28 9fcc010c 8d505dba 87f59020 8ffa0a50 9fcc0134 SYMTDI!isManualStart+0×852
2e 10 9fcc011c 826ff053 87f59020 8ffa0a50 b0d59480 SYMTDI!isManualStart+0×8ea
2f 18 9fcc0134 8de0e8bf 87fc3d78 953b92c0 8de28e84 nt!IofCallDriver+0×63
30 1c 9fcc0150 8de0e72f 00000000 87fc3e74 00000032 netbt!TdiSendDatagram+0×14e (FPO: [Non-Fpo])
31 44 9fcc0194 8de0e5c5 87fc3d78 c0a800ff 00000032 netbt!UdpSendDatagram+0×14c (FPO: [Non-Fpo])
32 48 9fcc01dc 8de12ed1 87fc3d78 b0a831e8 0057fed0 netbt!SendNameServiceRequest+0×2a1 (FPO: [Non-Fpo])
33 4c 9fcc0228 8de12adf b0b14aec 87751b48 000002ee netbt!QueryNameOnNet+0×376 (FPO: [Non-Fpo])
34 44 9fcc026c 8de0a5bb b0b14aec 87ffe990 8de0994a netbt!FindNameOrQuery+0×463 (FPO: [Non-Fpo])
35 70 9fcc02dc 8de0b093 00000000 00000000 87ffebb8 netbt!NbtConnectCommon+0×79c (FPO: [Non-Fpo])
…생략

SYMTDI Driver는 그렇게 많은 Stack를 사용하지 않고 있군요. 하지만 NtIDSVt의 경우 많은 Stack을 사용하고 있는것을 확인 할 수 있습니다. 특히 NtIDSVt에서 호출한 nt!IoVolumeDeviceToDosName Function이 꽤 큰 Stack 사용하고 있는것을 확인 할 수 있죠. ( 사실 Stack의 뒷부분에 호출되어 운이 없다고도 할 수 있음 )

.tss를 통해서 Last Instruction를 확인해 보도록하죠 .
2: kd> .tss 0x28
eax=9fcbe414 ebx=00000000 ecx=9fcbe488 edx=00000000 esi=9fcbe49c edi=9fcbe49c
eip=826700d6 esp=9fcbdf9c ebp=9fcbe3f0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!_woutput_l+0x1b:
826700d6 57 push edi

역시 Stack에서 작업을 하고 있군요. Stack Overflow에 대한 확신이 섭니다.
2: kd> !thread
THREAD 84ee6030 Cid 0704.1bc0 Teb: 7ffdc000 Win32Thread: 00000000 RUNNING on processor 2
IRP List:
84eaea30: (0006,01fc) Flags: 00060070 Mdl: 00000000
b0ac4b70: (0006,0094) Flags: 00060070 Mdl: 00000000
b23d8b90: (0006,01d8) Flags: 00000884 Mdl: 00000000
Impersonation token: a08a5030 (Level Impersonation)
DeviceMap 9ec2c868
Owning Process 0 Image: <Unknown>
Attached Process 8806a7c8 Image: spoolsv.exe
Wait Start TickCount 12973 Ticks: 0
Context Switch Count 14
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x76f0dbb0
Stack Init 9fcc1000 Current 9fcc03b8 Base 9fcc1000 Limit 9fcbe000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
00000000 826700d6 00000000 00000000 00000000 nt!KiTrap08+0×75 (FPO: TSS 28:0)
9fcbe3f0 82670b50 9fcbe414 8313a924 00000000 nt!_woutput_l+0×1b (FPO: [Non-Fpo])
9fcbe434 82670bb0 9fcbe49c 00000063 8313a924 nt!_vsnwprintf_l+0×7b (FPO: [Non-Fpo])
9fcbe450 83131038 9fcbe49c 00000063 8313a924 nt!_vsnwprintf+0×18 (FPO: [Non-Fpo])
… 생략

마지막으로 !thread Command를 이용해서 Stack Limit 를 확인해 보면 Stack Overflow에 대한 추측을 현실로 바꿀 수 있습니다.  이 Kernel Thread의 경우 9fcbe3f0가 마지막 Child EBP 이므로 nt!_woutput_l의 스택 사용량을 추정하면 Stack Overflow의 발생여부를 확인 할 수 있게되죠.

2: kd> uf nt!_woutput_l
Flow analysis was incomplete, some code may be missing
nt!_woutput_l:
826700bb 8bff mov edi,edi
826700bd 55 push ebp
826700be 8bec mov ebp,esp
826700c0 81ec54040000 sub esp,454h
826700c6 a130b77382 mov eax,dword ptr [nt!__security_cookie (8273b730)]
826700cb 33c5 xor eax,ebp
826700cd 8945fc mov dword ptr [ebp-4],eax
826700d0 8b4508 mov eax,dword ptr [ebp+8]
826700d3 8b4d14 mov ecx,dword ptr [ebp+14h]
826700d6 57 push edi

nt!_woutput_l Function은 Stack을  최소 454h 많큼 사용하는군요. 여분의 Stack이 3f0 만큼 남아 있기 때문에 다음번 push Instruction에서 문제가 발생하게되겠죠.

생각보다 수집이 잘안되는 Dump 이고 간얼적으로 발생하다 보니 재현이 힘든 Dump 입니다만 운좋게 분석한 기회가 생겼내요. 

 이와 비슷한 경우가 있으신 분들은 참고 하시길…