Monthly Archive for 10월, 2008

[debuging tip] Manual Stack Trace and Hooking Module

Published
by
admin
on 10월 30, 2008
in Debugging Windows
. 2 Comments

인터넷 Banking을 하려고 하는데 무슨 이유에서인지 IE가 계속 멈춰버리 더군요. 멀까 하고 덤프를 만들었는데 재미있는 Stack을 발견했습니다. 이 Stack을 가지고 한번 분석을 해보았죠.

0:029> !ntsdexts.locks

CritSec ntdll!LdrpLoaderLock+0 at 7c9ab178
LockCount 7
RecursionCount 1
OwningThread a10
EntryCount 5b
ContentionCount 5b
*** Locked

*** ERROR: Symbol file could not be found. Defaulted to export symbols for Flash9f.ocx -
CritSec Flash9f!pcre_stack_free+48f4 at 302b7d50
LockCount 0
RecursionCount 1
OwningThread 7c0
EntryCount 0
ContentionCount 0
*** Locked

locks Command를 이용해서 CS 정보를 었었습니다. LockCount가 무려 7 !!!  7개의 Thread 가 Waiting 상태군요!!7c9ab178 CS의 OwningThread인 a10을 봐봐야 겠군요 이 녀석이 어떤 이유에서 멈춰 있는듯합니다.

  29 Id: 9e0.a10 Suspend: 1 Teb: 7ff94000 Unfrozen
# ChildEBP RetAddr Args to Child
00 08d6fac8 7c93df3c 7c8025db 00000480 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
01 08d6facc 7c8025db 00000480 00000000 08d6fb00 ntdll!NtWaitForSingleObject+0xc (FPO: [3,0,0])
02 08d6fb30 7c802542 00000480 00002710 00000000 kernel32!WaitForSingleObjectEx+0xa8 (FPO: [Non-Fpo])
03 08d6fb44 0aad7c5c 00000480 00002710 00000000 kernel32!WaitForSingleObject+0×12 (FPO: [Non-Fpo])
*** ERROR: Symbol file could not be found. Defaulted to export symbols for mdnsNSP.dll -
WARNING: Frame IP not in any known module. Following frames may be wrong.
04 08d6fbc8 160851bf 16080000 00000002 00000000 0xaad7c5c
05 08d6fc08 16085279 16080000 7c93118a 16080000 mdnsNSP!NSPStartup+0×254f
06 08d6fc30 7c94b175 1608525c 16080000 00000002 mdnsNSP!NSPStartup+0×2609
07 08d6fca4 7c94afee 08d6fd30 08d6fd30 657a6aa0 ntdll!LdrpInitializeThread+0xc0 (FPO: [Non-Fpo])
08 08d6fd1c 7c93e437 08d6fd30 7c930000 00000000 ntdll!_LdrpInitialize+0×219 (FPO: [Non-Fpo])
09 00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0×7

ntdll!KiUserApcDispatcher과 ntdll!LdrpInitializeThread를 볼때 Thread 생성중 InMemoryOrderLinks에 존재하는  DLL Entry를 실행하고 있다는 것을 알 수 있습니다.  하지만 문제를 발생시킨 부분이 깨져보이는군요. Manual Stack Trace를 해보아야 겠군요. ( 어떨결에 잘못보면 mdnsNSP에서 문제가 발생한 것으로 오인할 수 있으니 주의 하시길… )

0:029> !teb
TEB at 7ff94000
ExceptionList: 08d6fb20
StackBase: 08d70000
StackLimit: 08d62000
SubSystemTib: 00000000
FiberData: 00001e00
ArbitraryUserPointer: 00000000
Self: 7ff94000
EnvironmentPointer: 00000000
ClientId: 000009e0 . 00000a10
RpcHandle: 00000000
Tls Storage: 00000000
PEB Address: 7ffd5000
LastErrorValue: 0
LastStatusValue: c0000046
Count Owned Locks: 0
HardErrorMode: 0
0:029> dps 08d62000 08d70000

…

08d6fb18 08d6fae0
08d6fb1c 00006bb7
08d6fb20 08d6fbf8
08d6fb24 7c839ac0 kernel32!_except_handler3
08d6fb28 7c802608 kernel32!`string’+0xd0
08d6fb2c 00000000
08d6fb30 08d6fb44
08d6fb34 7c802542 kernel32!WaitForSingleObject+0×12
08d6fb38 00000480
08d6fb3c 00002710
08d6fb40 00000000
08d6fb44 08d6fbc8
08d6fb48 0aad7c5c
08d6fb4c 00000480
08d6fb50 00002710
08d6fb54 00000000
08d6fb58 7c800000 kernel32!_imp___wcsnicmp <PERF> (kernel32+0×0)
08d6fb5c 0aad791b
08d6fb60 0ab00000
08d6fb64 00000006
08d6fb68 08d6fb74
08d6fb6c 0000000c
08d6fb70 7c943405 ntdll!RtlDecodePointer
08d6fb74 7c800000 kernel32!_imp___wcsnicmp <PERF> (kernel32+0×0)
08d6fb78 1609b9ac mdnsNSP!NSPStartup+0×18d3c
08d6fb7c 00000000
08d6fb80 0aad80cb
08d6fb84 7c800000 kernel32!_imp___wcsnicmp <PERF> (kernel32+0×0)
08d6fb88 1609b9ac mdnsNSP!NSPStartup+0×18d3c
08d6fb8c 00000000
08d6fb90 7c8097d0 kernel32!TlsGetValue
08d6fb94 16080000 mdnsNSP
08d6fb98 1608956f mdnsNSP!NSPStartup+0×68ff
08d6fb9c 7c800000 kernel32!_imp___wcsnicmp <PERF> (kernel32+0×0)
08d6fba0 1609b9ac mdnsNSP!NSPStartup+0×18d3c
08d6fba4 032c6708
08d6fba8 16085126 mdnsNSP!NSPStartup+0×24b6
08d6fbac 565f744f
08d6fbb0 00000031
08d6fbb4 032c6708
08d6fbb8 00000000
08d6fbbc 00000002
08d6fbc0 16080000 mdnsNSP
08d6fbc4 00000000
08d6fbc8 08d6fc08
08d6fbcc 160851bf mdnsNSP!NSPStartup+0×254f
08d6fbd0 16080000 mdnsNSP
08d6fbd4 00000002
08d6fbd8 00000000
08d6fbdc 4765a141
08d6fbe0 00000000
08d6fbe4 08d6fc24
08d6fbe8 7ffd5000
08d6fbec 00000001
08d6fbf0 08d6fbdc
08d6fbf4 76f11178 WLDAP32!_DllMainCRTStartup+0×52
08d6fbf8 08d6fc94
08d6fbfc 16083400 mdnsNSP!NSPStartup+0×790
08d6fc00 59ba9289
08d6fc04 00000000
08d6fc08 08d6fc30
08d6fc0c 16085279 mdnsNSP!NSPStartup+0×2609
08d6fc10 16080000 mdnsNSP
08d6fc14 7c93118a ntdll!LdrpCallInitRoutine+0×14
08d6fc18 16080000 mdnsNSP
08d6fc1c 00000002
08d6fc20 00000000
08d6fc24 7ffd5000
08d6fc28 00000000
08d6fc2c 00255a98
08d6fc30 08d6fca4
08d6fc34 7c94b175 ntdll!LdrpInitializeThread+0xc0
08d6fc38 1608525c mdnsNSP!NSPStartup+0×25ec
08d6fc3c 16080000 mdnsNSP
08d6fc40 00000002
08d6fc44 00000000
08d6fc48 7ff94000
08d6fc4c 7ffd5000
08d6fc50 00000000
08d6fc54 00000014
08d6fc58 00000001
08d6fc5c 00000000
08d6fc60 001da9c8
08d6fc64 00000000
08d6fc68 00000000
08d6fc6c 00000000
08d6fc70 00000000
08d6fc74 00000000
08d6fc78 00000000
08d6fc7c 00000000
08d6fc80 7ffd5000
08d6fc84 1608525c mdnsNSP!NSPStartup+0×25ec
08d6fc88 00255a98
08d6fc8c 08d6fc48
08d6fc90 00000000

…
Windbg에서 보여주고 있는 부분은 0xaad7c5c 부분입니다만 실제로 mdnsNSP!NSPStartup+0×254f 영역에서 호출한 함수는 mdnsNSP!NSPStartup+0×231d 이 부분 입니다. 그렇다면 이 Function이 호출된 것은 Stack 상에 어디에 나타 날까 ?

 0:029> ub mdnsNSP!NSPStartup+0x254f
*** ERROR: Symbol file could not be found. Defaulted to export symbols for mdnsNSP.dll -
mdnsNSP!NSPStartup+0x2538:
160851a8 ffd0 call eax
160851aa 8945e4 mov dword ptr [ebp-1Ch],eax
160851ad 837de400 cmp dword ptr [ebp-1Ch],0
160851b1 0f8496000000 je mdnsNSP!NSPStartup+0×25dd (1608524d)
160851b7 57 push edi
160851b8 56 push esi
160851b9 53 push ebx
160851ba e8cefdffff call mdnsNSP!NSPStartup+0×231d (16084f8d)

0:029> uf mdnsNSP!NSPStartup+0×231d
mdnsNSP!NSPStartup+0×231d:
16084f8d 55 push ebp
16084f8e 8bec mov ebp,esp
16084f90 51 push ecx
16084f91 8b450c mov eax,dword ptr [ebp+0Ch]
16084f94 83f801 cmp eax,1
16084f97 53 push ebx
16084f98 56 push esi
…생략
mdnsNSP!NSPStartup+0×24e5:
16085155 57 push edi
16085156 e83c470000 call mdnsNSP!NSPStartup+0×6c27 (16089897)
1608515b 59 pop ecx

mdnsNSP!NSPStartup+0×24ec:
1608515c 33c0 xor eax,eax
1608515e 40 inc eax

mdnsNSP!NSPStartup+0×24ef:
1608515f 5f pop edi
16085160 5e pop esi
16085161 5b pop ebx
16085162 c9 leave
16085163 c20c00 ret 0Ch
mdnsNSP!NSPStartup+0×231d 함수가 메모리 상에 실제 위치하는 영역은 16084f8d  부터 16085163 부분 이군요 그럼 이 부분 Stack상에 어디에 표시되어 있을까 ?

...
08d6fb90 7c8097d0 kernel32!TlsGetValue
08d6fb94 16080000 mdnsNSP
08d6fb98 1608956f mdnsNSP!NSPStartup+0×68ff
08d6fb9c 7c800000 kernel32!_imp___wcsnicmp <PERF> (kernel32+0×0)
08d6fba0 1609b9ac mdnsNSP!NSPStartup+0×18d3c
08d6fba4 032c6708
08d6fba8 16085126 mdnsNSP!NSPStartup+0×24b6
…

Stack상에 그 영역의 값을 가지는 것이 보이는군요. 그럼 다시 mdnsNSP!NSPStartup+0×24b6 위치에서 호출되진 함수를 보죠.

0:029> ub mdnsNSP!NSPStartup+0x24b6
mdnsNSP!NSPStartup+0x249a:
1608510a 3bf7 cmp esi,edi
1608510c 59 pop ecx
1608510d 59 pop ecx
1608510e 0f84a9feffff je mdnsNSP!NSPStartup+0x234d (16084fbd)
16085114 56 push esi
16085115 ff3538fc0916 push dword ptr [mdnsNSP!NSPStartup+0x1cfc8 (1609fc38)]
1608511b ff350c090a16 push dword ptr [mdnsNSP!NSPStartup+0x1dc9c (160a090c)]
16085121 e8fa430000 call mdnsNSP!NSPStartup+0×68b0 (16089520)

0:029> uf mdnsNSP!NSPStartup+0×68b0
mdnsNSP!NSPStartup+0×68b0:
16089520 56 push esi
16089521 ff353cfc0916 push dword ptr [mdnsNSP!NSPStartup+0x1cfcc (1609fc3c)]
16089527 8b35ecb00916 mov esi,dword ptr [mdnsNSP!NSPStartup+0x1847c (1609b0ec)]
1608952d ffd6 call esi
1608952f 85c0 test eax,eax
16089531 7421 je mdnsNSP!NSPStartup+0×68e4 (16089554)

mdnsNSP!NSPStartup+0×68c3:
16089533 a138fc0916 mov eax,dword ptr [mdnsNSP!NSPStartup+0x1cfc8 (1609fc38)]
16089538 83f8ff cmp eax,0FFFFFFFFh
1608953b 7417 je mdnsNSP!NSPStartup+0×68e4 (16089554)

mdnsNSP!NSPStartup+0×68cd:
1608953d 50 push eax
1608953e ff353cfc0916 push dword ptr [mdnsNSP!NSPStartup+0x1cfcc (1609fc3c)]
16089544 ffd6 call esi
16089546 ffd0 call eax
16089548 85c0 test eax,eax
1608954a 7408 je mdnsNSP!NSPStartup+0×68e4 (16089554)

mdnsNSP!NSPStartup+0×68dc:
1608954c 8b80fc010000 mov eax,dword ptr [eax+1FCh]
16089552 eb1b jmp mdnsNSP!NSPStartup+0×68ff (1608956f)

mdnsNSP!NSPStartup+0×68e4:
16089554 689cb90916 push offset mdnsNSP!NSPStartup+0×18d2c (1609b99c)
16089559 ff15d0b00916 call dword ptr [mdnsNSP!NSPStartup+0x18460 (1609b0d0)]
1608955f 85c0 test eax,eax
16089561 741a je mdnsNSP!NSPStartup+0×690d (1608957d)

mdnsNSP!NSPStartup+0×68f3:
16089563 68acb90916 push offset mdnsNSP!NSPStartup+0×18d3c (1609b9ac)
16089568 50 push eax
16089569 ff1558b00916 call dword ptr [mdnsNSP!NSPStartup+0x183e8 (1609b058)]

mdnsNSP!NSPStartup+0×68ff:
1608956f 85c0 test eax,eax
16089571 740a je mdnsNSP!NSPStartup+0×690d (1608957d)

mdnsNSP!NSPStartup+0×6903:
16089573 ff742408 push dword ptr [esp+8]
16089577 ffd0 call eax
16089579 89442408 mov dword ptr [esp+8],eax

mdnsNSP!NSPStartup+0×690d:
1608957d 8b442408 mov eax,dword ptr [esp+8]
16089581 5e pop esi
16089582 c3 ret

같은 방법으로 mdnsNSP!NSPStartup+0×68b0 Function내에 Address를 나타내는 Return Address를 Raw Stack에서 발견할 수 있죠. ( mdnsNSP!NSPStartup+0×68ff 값을요 … )  mdnsNSP!NSPStartup+0×68ff값을 Return Address로 가지는 함수 Call을 찾아 보면 정말 문제를 일으킨 원인이 대략적으로 보여지겠죠.

0:029> dd 1609b058
1609b058 0aad8085 0aad7ee5 7c809f81 7c8097f6
1609b068 7c809a1d 7c8099bf 7c80981e 7c812a99
1609b078 7c93ff0d 7c949b80 7c9400a4 7c8097b8
1609b088 7c812fad 7c812b6e 7c80ac51 7c801e1a
1609b098 7c80de85 7c863e6a 7c8449fd 7c813123
1609b0a8 7c810f88 7c812c46 7c809b74 7c861c00
1609b0b8 7c809ae1 7c95aba5 7c80cd27 7c812fc9
1609b0c8 7c810ee1 7c833490 7c80b731 7c81cafa

0:029> dps 1609b048
1609b048 7c80a0ed kernel32!WaitForMultipleObjects
1609b04c 7c83089d kernel32!CreateEventA
1609b050 7c80a164 kernel32!WideCharToMultiByte
1609b054 7c814f7a kernel32!GetSystemDirectoryA
1609b058 0aad8085
1609b05c 0aad7ee5
1609b060 7c809f81 kernel32!InitializeCriticalSection
1609b064 7c8097f6 kernel32!InterlockedIncrement
1609b068 7c809a1d kernel32!LocalAlloc
1609b06c 7c8099bf kernel32!LocalFree
1609b070 7c80981e kernel32!InterlockedExchange
1609b074 7c812a99 kernel32!RaiseException
1609b078 7c93ff0d ntdll!RtlFreeHeap
1609b07c 7c949b80 ntdll!RtlReAllocateHeap
1609b080 7c9400a4 ntdll!RtlAllocateHeap
1609b084 7c8097b8 kernel32!GetCurrentThreadId
1609b088 7c812fad kernel32!GetCommandLineA
1609b08c 7c812b6e kernel32!GetVersionExA
1609b090 7c80ac51 kernel32!GetProcessHeap
1609b094 7c801e1a kernel32!TerminateProcess
1609b098 7c80de85 kernel32!GetCurrentProcess
1609b09c 7c863e6a kernel32!UnhandledExceptionFilter
1609b0a0 7c8449fd kernel32!SetUnhandledExceptionFilter
1609b0a4 7c813123 kernel32!IsDebuggerPresent
1609b0a8 7c810f88 kernel32!HeapDestroy
1609b0ac 7c812c46 kernel32!HeapCreate
1609b0b0 7c809b74 kernel32!VirtualFree
1609b0b4 7c861c00 kernel32!FatalAppExitA
1609b0b8 7c809ae1 kernel32!VirtualAlloc
1609b0bc 7c95aba5 ntdll!RtlUnwind
1609b0c0 7c80cd27 kernel32!LockResource
1609b0c4 7c812fc9 kernel32!GetStdHandle

0:029> lmv m mdnsNSP
start end module name
16080000 160a5000 mdnsNSP (export symbols) mdnsNSP.dll
Loaded symbol image file: mdnsNSP.dll
Image path: C:\Program Files\Bonjour\mdnsNSP.dll
Image name: mdnsNSP.dll
Timestamp: Fri Aug 15 07:54:04 2008 (48A4B78C)
CheckSum: 0002A010
ImageSize: 00025000
File version: 1.0.5.11
Product version: 1.0.5.11
File flags: 0 (Mask 17)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Apple Inc.
ProductName: Bonjour
InternalName: mdnsNSP.dll
OriginalFilename: mdnsNSP.dll
ProductVersion: 1,0,5,11
FileVersion: 1,0,5,11
FileDescription: Bonjour Namespace Provider
LegalCopyright: Copyright (C) 2003-2008 Apple Inc.

대략적으로 7c로 지작하는 주소들이 쭉있는것으로 봐서 mdnsNSP의 Import된 Function 임을 추정할 수 있습니다. 그런데 이상한점은 실제로 Call되어지는 함수는 어떤모듈에 의해서 Hooking 되어 졌군요.

0aa90000 0aac0000 Foo.dll ( 실제 이름은 Foo가 아닙니다. )
Timestamp: Thu Jan 01 09:00:01 1970 (00000001)
Checksum: 00000000

0aad8085의 위치는 Foo.dll의 영역이군요. 원인이된 부분은 바로 Foo.dll의 Hooking Function중 하나겠군요  !!! ( 그런데 아쉽게 Unload 되어 졌군요. 무슨 이유에서인지 Waiting 상태에서 Unload된것으로 보여지는군요. ) 만약 Waiting이 풀렸더라도 Exception….

System Process 점유가 100% ㅜ.ㅜ

Published
by
admin
on 10월 19, 2008
in Debugging Windows
. 0 Comments

노트북으로 열심히 업무를 진행중 재미있는 현상이 발생했습니다.

System Process가 100%를 먹고 있더군요. 일단 필요없는 프로세스를 시작목록에서 제거 하고 노트북을 리부팅 !!

하지만 역시나 System Process는 100%를 먹고 있더군요.

무슨일일까 해서 Windbg를 열고 System Process의 Thread를 확인 !!

lkd> !process 0 f System
PROCESS 86fa15f0 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 00039000 ObjectTable: e1000cc0 HandleCount: 163.
Image: System
VadRoot 86f987d8 Vads 3 Clone 0 Private 3. Modified 1191. Locked 0.
DeviceMap e1004450
Token e1001678
ElapsedTime 00:08:45.605
UserTime 00:00:00.000
KernelTime 00:00:39.667
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (67, 0, 345) (268KB, 0KB, 1380KB)
PeakWorkingSetSize 596
VirtualSize 0 Mb
PeakVirtualSize 2 Mb
PageFaultCount 7105
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 7

THREAD 86fa1378 Cid 0004.0008 Teb: 00000000 Win32Thread: 00000000 READY
Not impersonating
DeviceMap e1004450
Owning Process 86fa15f0 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 2997 Ticks: 49517 (0:00:08:15.883)
Context Switch Count 937
UserTime 00:00:00.000
KernelTime 00:00:01.231
Start Address nt!Phase1Initialization (0×806a138a)
Stack Init bacd0000 Current baccf79c Base bacd0000 Limit baccd000 Call 0
Priority 0 BasePriority 0 PriorityDecrement 0 DecrementCount 0
ChildEBP RetAddr
baccf7b4 804de0f7 nt!KiSwapContext+0×2e (FPO: [Uses EBP] [0,0,4])
baccf7c0 804e5b7d nt!KiSwapThread+0×46 (FPO: [0,0,0])
baccf7f8 804e9cb5 nt!KeWaitForMultipleObjects+0×284 (FPO: [Non-Fpo])
baccf844 8069febd nt!MmZeroPageThread+0×61 (FPO: [Non-Fpo])
baccfdac 8057f0f1 nt!Phase1Initialization+0×1144 (FPO: [Non-Fpo])
baccfddc 804fa27a nt!PspSystemThreadStartup+0×34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0×16

THREAD 86fa0b30 Cid 0004.0010 Teb: 00000000 Win32Thread: 00000000 WAIT: (WrQueue) UserMode Non-Alertable
80563640 Unknown
Not impersonating
DeviceMap e1004450
Owning Process 86fa15f0 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 52454 Ticks: 136 (0:00:00:01.361)
Context Switch Count 1465
UserTime 00:00:00.000
KernelTime 00:00:00.040
Start Address nt!ExpWorkerThread (0×804e6196)
Stack Init bace0000 Current bacdfd1c Base bace0000 Limit bacdd000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr
bacdfd34 804de0f7 nt!KiSwapContext+0×2e (FPO: [Uses EBP] [0,0,4])
bacdfd40 804e607e nt!KiSwapThread+0×46 (FPO: [0,0,0])
bacdfd6c 804e623d nt!KeRemoveQueue+0×20e (FPO: [Non-Fpo])
bacdfdac 8057f0f1 nt!ExpWorkerThread+0xd6 (FPO: [Non-Fpo])
bacdfddc 804fa27a nt!PspSystemThreadStartup+0×34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0×16

… 생략
THREAD 86fc7908 Cid 0004.0060 Teb: 00000000 Win32Thread: 00000000 READY
Not impersonating
DeviceMap e1004450
Owning Process 86fa15f0 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 53845 Ticks: 39 (0:00:00:00.390)
Context Switch Count 26470
UserTime 00:00:00.000
KernelTime 00:00:34.649
 Start Address ACPI!ACPIWorker (0xba869b10)
Stack Init bad30000 Current bad2fd1c Base bad30000 Limit bad2d000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
ChildEBP RetAddr
bad2fd34 804e5896 nt!KiUnlockDispatcherDatabase+0×77 (FPO: [Uses EBP] [0,0,4])
bad2fd6c ba869b57 nt!KeWaitForMultipleObjects+0×334 (FPO: [Non-Fpo])
bad2fdac 8057f0f1 ACPI!ACPIWorker+0×47 (FPO: [Non-Fpo])
bad2fddc 804fa27a nt!PspSystemThreadStartup+0×34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0×16

… 생략

 그냥 대충 봐도 평소 스택과 다른 모습입니다. 결정적으로 KernelTime이 34.649 … System Process의 KernelTime이 39.667으로 봐서 엄청나게 잡아 먹고 있군요 -_- ;;  Stack 상으로 봐도 nt!KiUnlockDispatcherDatabase가 호출 된것을 볼때 Waiting Object가 Release 되는 시점이라는 것을 확인 할 수 있습니다. ( 사실 저 역시 세마포어가 Release 될때 nt!KiUnlockDispatcherDatabase 가 호출되는것 외에는 실제로 구경하는게 2번째 입니다. ) 

 ACPI쪽인것으로 봐서 대략 System의 과열로 발생한 현상으로 생각 됩니다. 실제로 평소 PC의 ACPI Stack를 보면 아래와 같습니다.

THREAD 8a8bc628 Cid 0004.0118 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
f74ddf90 NotificationEvent
f74ddf80 NotificationEvent
Not impersonating
DeviceMap e1000168
Owning Process 8a8ee9c8 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 959537 Ticks: 46 (0:00:00:00.718)
Context Switch Count 7052
UserTime 00:00:00.000
KernelTime 00:00:00.046
Start Address ACPI!ACPIWorker (0xf74d0b10)
Stack Init baf94000 Current baf93d10 Base baf94000 Limit baf91000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
ChildEBP RetAddr
baf93d28 804e3bd2 nt!KiSwapContext+0×2f (FPO: [Uses EBP] [0,0,4])
baf93d34 804e3b83 nt!KiSwapThread+0×8a (FPO: [0,0,0])
baf93d6c f74d0b57 nt!KeWaitForMultipleObjects+0×284 (FPO: [Non-Fpo])
baf93dac 80577723 ACPI!ACPIWorker+0×47 (FPO: [Non-Fpo])
baf93ddc 804ee6d9 nt!PspSystemThreadStartup+0×34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0×16

KernelTime의 수치가 그리 높지 않은 것을 확인 할 수 있죠 ^ ^

재미있는 Stack 이군요  . Enjoy …

[windbg] .sound_notify 를 아십니까?

Published
by
admin
on 10월 10, 2008
in Basic Debugging
. 1 Comment

.sound_notify는 Windbg가 wait for command 상태즉 Command 입력이 이루어질 수 있는 상태가 되면 wav 파일을 Play해서 상태를 알려줍니다. Debugging을 할때 딴짓을 많이하는 저에게는 유용하죠. 일단 Debugging을 걸어 놓고 특정 Break Point가 걸리게 되면 제가 지정한 wav 파일이 Play 됩니다.

잡기능이지만 때로는 꽤 유용합니다. ^^

.sound_notify /ed           <== Default Wav 출력
.sound_notify /ef File     <== 지정한 wav 파일 출력
.sound_notify /d             <== sound notify disable

[windbg] .frame shortcut , .f+, .f-

Published
by
admin
on 10월 7, 2008
in Basic Debugging
. 1 Comment

Current stack frame index를 지정할때는 .frame 이라는 명령을 사용하여 지정을합니다. 하지만 그 frame 보다 하나위에나 하나 아래의 frame index를 지정하고자 하면 다시 kn 명을 치고 .frame을 통해서 다시 지정을 해야 하는 불편함이 있지요. 그러한 불편함을 좀더 쉽게해주는 shortcurt이 바로 .f+와 .f- 입니다.  사용법은 아래와 같이 굉장히 간단합니다.

0:000> kvn
# ChildEBP RetAddr Args to Child
00 0007feb8 77cf91be 77cf91f1 0007fefc 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
01 0007fed8 01002a1b 0007fefc 00000000 00000000 USER32!NtUserGetMessage+0xc
02 0007ff1c 01007511 01000000 00000000 000a1eff notepad!WinMain+0xe5 (FPO: [Non-Fpo])
03 0007ffc0 7c817067 7c941440 01bef55c 7ffdc000 notepad!WinMainCRTStartup+0×174 (FPO: [Non-Fpo])
04 0007fff0 00000000 0100739d 00000000 78746341 kernel32!BaseProcessStart+0×23 (FPO: [Non-Fpo])
0:000> .frame 0
00 0007feb8 77cf91be ntdll!KiFastSystemCallRet
0:000> .f+
01 0007fed8 01002a1b USER32!NtUserGetMessage+0xc
0:000> .f+
02 0007ff1c 01007511 notepad!WinMain+0xe5
0:000> .f+
03 0007ffc0 7c817067 notepad!WinMainCRTStartup+0×174
0:000> .f+
04 0007fff0 00000000 kernel32!BaseProcessStart+0×23
0:000> .f-
03 0007ffc0 7c817067 notepad!WinMainCRTStartup+0×174
0:000> .f-
02 0007ff1c 01007511 notepad!WinMain+0xe5
0:000> .f-
01 0007fed8 01002a1b USER32!NtUserGetMessage+0xc

실전에서 꽤나 유용하게 사용이 가능하겠죠.  ^ ^

[windbg] .kframes Command

Published
by
admin
on 10월 6, 2008
in Basic Debugging
. 0 Comments

간혹 보면 call Stack의 Depth가 깊어서 Stack이 다 보지 않을 경우가 있지요. 그렇게되면 명령어에 Depth 옵션을 주어 Trace하면 스택이 정상적으로 보이게 됩니다. 아래와 같이 말이죠

0:000> kvn 100

이것도 귀찮다면 .kframes라는 Command를 사용해보시면 도움이 되실것 같습니다.  .kframe Command는 trace 되는 Stack Depth의 Default 값을 지정할 수 있도록 해줍니다.  

0:000> .kframes 0×100
Default stack trace depth is 0n256 frames

나중에 기회가 되시면 꼭 한번 사용해보시길 …. ^^