이미 EOS Windows 2003 이 자꾸 Cash 된다고 하여 덤프 분석을 진행해 봤습니다.

제일 먼저 실행해야 할 !analyze -v를 실행해 보았습니다.

 

BugCheck 0x7E 라는 코드인데 시스템의 중요 스레드에서 Exception이 발생했는데 처리하지 못해서 시스템이 크래시 된 것 입니다.

3: kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

 

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)

This is a very common bugcheck.  Usually the exception address pinpoints

the driver/function that caused the problem.  Always note this address

as well as the link date of the driver/image that contains this address.

Arguments:

Arg1: ffffffffc0000005, The exception code that was not handled

Arg2: fffffadf26a2ce30, The address that the exception occurred at

Arg3: fffffadf27925950, Exception Record Address

Arg4: fffffadf27925360, Context Record Address

 

Exception record를 확인하니 srv 라는 네트워크 드라이버를 담당하는 드라이버에서 Access Violation 오류가 발생한 것을 확인할 수 있습니다.

EXCEPTION_RECORD:  fffffadf27925950 -- (.exr 0xfffffadf27925950)

ExceptionAddress: fffffadf26a2ce30 (srv!memmove+0x0000000000000064)

   ExceptionCode: c0000005 (Access violation)

  ExceptionFlags: 00000000

NumberParameters: 2

   Parameter[0]: 0000000000000001

   Parameter[1]: 0000000100089458

Attempt to write to address 0000000100089458

 

 

아래의 .cxr 을 클릭하면 오류가 발생한 코드로 이동을 합니다.

CONTEXT:  fffffadf27925360 -- ( .cxr 0xfffffadf27925360 )

rax=00000000000893f0 rbx=fffffadf36263958 rcx=0000000100089458

rdx=fffffade3720f0f0 rsi=fffffadf3734cb20 rdi=00000000000893f0

rip=fffffadf26a2ce30 rsp=fffffadf27925b78 rbp=0000000000000000

 r8=0000000000000018  r9=0000000000000003 r10=0000000000000012

r11=0000000100089458 r12=0000000000000000 r13=0000000000000018

r14=00000000ffffff84 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

srv!memmove+0x64:

fffffadf`26a2ce30 488901          mov     qword ptr [rcx],rax ds:002b:00000001`00089458=????????????????

Resetting default scope

 

 

오류가 발생한 코드로 이동을 해보니 rcx 레지스터에 잘못된 값이 들어 있어서 문제가 발생한 것입니다. [rcx] rcx 의 값에 해당하는 주소에 접근한다는 의미 입니다.

3: kd> .cxr 0xfffffadf27925360

rax=00000000000893f0 rbx=fffffadf36263958 rcx=0000000100089458

rdx=fffffade3720f0f0 rsi=fffffadf3734cb20 rdi=00000000000893f0

rip=fffffadf26a2ce30 rsp=fffffadf27925b78 rbp=0000000000000000

 r8=0000000000000018  r9=0000000000000003 r10=0000000000000012

r11=0000000100089458 r12=0000000000000000 r13=0000000000000018

r14=00000000ffffff84 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

srv!memmove+0x64:

fffffadf`26a2ce30 488901          mov     qword ptr [rcx],rax ds:002b:00000001`00089458=????????????????

 

 

콜스택을 확인해보니 다른 드라이버 모듈은 안 보이고 SRV만 보입니다. 아마도 네트워크 드라이브에 대한 요청을 받은 후 네트워크 요청을 처리하던 중으로 보입니다.

3: kd> k

  *** Stack trace for last set context - .thread/.cxr resets it

 # Child-SP          RetAddr           Call Site

00 fffffadf`27925b78 fffffadf`26ae24c9 srv!memmove+0x64

01 fffffadf`27925b80 fffffadf`26a2c8f7 srv!SrvSmbNtTransactionSecondary+0x3e9

02 fffffadf`27925c40 fffffadf`26a2c853 srv!SrvProcessSmb+0x19f

03 fffffadf`27925ca0 fffffadf`26a8d0f2 srv!SrvRestartReceive+0xca

04 fffffadf`27925d10 fffff800`0124f932 srv!WorkerThread+0x144

05 fffffadf`27925d70 fffff800`01020556 nt!PspSystemThreadStartup+0x3e

06 fffffadf`27925dd0 00000000`00000000 nt!KiStartSystemThread+0x16

 

 

어떤 시스템 중요 프로세스인지 확인해 봅니다.

3: kd> !process -1 0

PROCESS fffffadf38bf85a0

    SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000

    DirBase: 23be01000  ObjectTable: fffffa8000001bd0  HandleCount: 2717.

    Image: System

 

 

어셈블리로 분석을 해 보았지만 특이한 점이 확인되지 않아서 SrvSmbNtTransactionSecondary 함수를 인터넷에서 검색해 봅니다.

DELL 문서에서 KB2696547에 해당하는 이슈라고 확인됩니다.

Stop Code 0x50 srv.sys caused by EternalBlue Exploit

https://www.dell.com/support/article/kr/ko/krdhs1/sln306200/stop-code-0x50-srvsys-caused-by-eternalblue-exploit?lang=en

Microsoft released a Security Bulletin regarding SMBv1.0. External Link The most severe of the vulnerabilities could allow remote code execution if an attacker sends specially crafted messages to a Microsoft Server Message Block 1.0 (SMBv1) server.

 

You can identify that this issue is occuring by analyzing the Stack on the Memory Dump and finding this specific lines:

 

ffffd001`078b0700 fffff801`71252360 nt!KiPageFault+0x12f

ffffd001`078b0890 fffff801`712522a5 srv!SrvOs2FeaToNt+0x48

ffffd001`078b08c0 fffff801`7127369b srv!SrvOs2FeaListToNt+0x125

ffffd001`078b0910 fffff801`7127c8ba srv!SrvSmbOpen2+0xc3

ffffd001`078b09b0 fffff801`7127fb2e srv!ExecuteTransaction+0x2ca

ffffd001`078b09f0 fffff801`7120d84f srv!SrvSmbTransactionSecondary+0x40b

ffffd001`078b0a90 fffff801`7120da20 srv!SrvProcessSmb+0x237

ffffd001`078b0b10 fffff801`7124cac8 srv!SrvRestartReceive+0x114

ffffd001`078b0b50 fffff800`13591306 srv!WorkerThread+0x5248

ffffd001`078b0bd0 fffff800`1317f280 nt!IopThreadStart+0x26

ffffd001`078b0c00 fffff800`131d89c6 nt!PspSystemThreadStartup+0x58

ffffd001`078b0c60 00000000`00000000 nt!KiStartSystemThread+0x16

 

 

좀더 검색을 해보니 MS SMB 취역점인 MS17-010을 분석한 문서가 보입니다. 아마도 MS17-010 취약점에 대한 공격이 들어왔는데 srv 드라이버가 이를 잘 처리하지 못해서 시스템이 크래시 된 것으로 보입니다.

https://github.com/nixawk/labs/issues/9

===============

Bug5: Transaction secondary request is accepted and processed after transaction execution is started

===============

If we send a transaction secondary request to a transaction that AllDataReceived member has already been set, a server will

send back an error without processing the request.

 

For multipiece transaction, AllDataReceived is set (in SrvSmbTransactionSecondary()/SrvSmbNtTransactionSecondary()) before

executing transaction. But AllDataReceived is NOT set (in SrvSmbTransaction()/SrvSmbNtTransaction()) when transaction is

completed in 1 SMB message. This allow us to send a transaction secondary request to modify InParamter/InData buffer and

ParameterCount/DataCount while server is executing a transaction or sending a reply.

 

 

Windows Server 2003은 이미 EOS 되어 보안 취약점에 대해서도 패치를 제공하지 않은 상태입니다. 하지만 SMB 취약점은 영향도가 커서 특별히 패지가 만들어져 있습니다. 혹시 아직 Windows 2003을 운영하고 계신다면 꼭 아래 패치를 설치해주세요

Security Update for Windows Server 2003 (KB4012598)

https://www.microsoft.com/en-us/download/details.aspx?id=55248

 

감사합니다.


'Debugging' 카테고리의 다른 글

System Hang 분석  (0) 2018.11.24
Symbol Server 설정 (공유, HTTP)  (0) 2018.03.04
[디버거 명령]!Mex.p  (0) 2017.09.25
[디버깅 명령]!mex.help  (0) 2017.09.24

VMware 에서 실행되는 Windows VM이 시스템 행 현상이 있다고 하여 분석을 진행해 보았습니다.


먼저 !vm 명령을 싱행해서 메모리 상태를 확인해 보았는데 별다른 문제가 확인되지 않았습니다.

0: kd> !vm

Page File: \??\C:\pagefile.sys

  Current:   1048576 Kb  Free Space:    807844 Kb

  Minimum:   1048576 Kb  Maximum:     10485500 Kb

 

Physical Memory:          4194156 (   16776624 Kb)

Available Pages:          3479978 (   13919912 Kb)

ResAvail Pages:           4063051 (   16252204 Kb)

Locked IO Pages:                0 (          0 Kb)

Free System PTEs:      4294989313 (17179957252 Kb)

Modified Pages:             13432 (      53728 Kb)

Modified PF Pages:          12747 (      50988 Kb)

Modified No Write Pages:        0 (          0 Kb)

NonPagedPool    0:             33 (        132 Kb)

NonPagedPoolNx  0:          32181 (     128724 Kb)

NonPagedPool    1:              0 (          0 Kb)

NonPagedPoolNx  1:              0 (          0 Kb)

NonPagedPool Usage:           168 (        672 Kb)

NonPagedPoolNx Usage:       40172 (     160688 Kb)

NonPagedPool Max:      4294967296 (17179869184 Kb)

PagedPool  0:               79908 (     319632 Kb)

PagedPool  1:               51553 (     206212 Kb)

PagedPool  2:                   0 (          0 Kb)

PagedPool Usage:           131461 (     525844 Kb)

PagedPool Maximum:     4160749568 (16642998272 Kb)

Processor Commit:             917 (       3668 Kb)

Session Commit:             16179 (      64716 Kb)

Syspart SharedCommit 0

Shared Commit:              51347 (     205388 Kb)

Special Pool:                   0 (          0 Kb)

Kernel Stacks:               8889 (      35556 Kb)

Pages For MDLs:               342 (       1368 Kb)

Pages For AWE:                  0 (          0 Kb)

NonPagedPool Commit:        38599 (     154396 Kb)

PagedPool Commit:          131461 (     525844 Kb)

Driver Commit:               9397 (      37588 Kb)

Boot Commit:                50253 (     201012 Kb)

System PageTables:            997 (       3988 Kb)

VAD/PageTable Bitmaps:       6871 (      27484 Kb)

ProcessLockedFilePages:        12 (         48 Kb)

Pagefile Hash Pages:          206 (        824 Kb)

Sum System Commit:         315470 (    1261880 Kb)

Total Private:             473164 (    1892656 Kb)

Misc/Transient Commit:       4291 (      17164 Kb)

Committed pages:           792925 (    3171700 Kb)

Commit limit:             4456300 (   17825200 Kb)




Storage에는 Pending 된 IO가 있는지 확인을 해 보았지만 Pending 된 것이 확인되지 않았습니다.

0: kd> !storunit

STORPORT Units:

==================

Product                 SCSI ID  Object            Extension         Pnd Out Ct  State

--------------------------------------------------------------------------------------

VMware     Virtual di   0  0  0  ffffab06b03a4060  ffffab06b03a41b0    0   0  0  Working

VMware     Virtual di   0  1  0  ffffab06b0399060  ffffab06b03991b0    0   0  0  Working

 

0: kd> !storunit ffffab06b03a4060

   DO: ffffab06b03a4060   Ext: ffffab06b03a41b0   Adapter: ffffab06b03cb1a0   Working

   Vendor: VMware    Product: Virtual disk      SCSI ID: (0, 0, 0)

   Claimed Enumerated

   SlowLock: Free  RemLock: 1  PageCount: 1

   QueueTagList: ffffab06b03a42b0     Node 0 Outstanding: Head: 0000000000000000  Tail: 0000000000000000  Timeout: 0 (Ticking Down)

   Node 1 Outstanding: Head: 0000000000000000  Tail: 0000000000000000  Timeout: 0 (Ticking Down)

   DeviceQueue: ffffab06b03a4340  Depth: 64  Status: Not Frozen   PauseCount: 0  BusyCount: 0

   IO Gateway: Busy Count: 0  Pause Count: 0

   Requests: Outstanding: 0  Device: 0  ByPass: 0

 

 

[Device-Queued Requests]

 

IRP               SRB Type   SRB               XRB               Command           MDL               SGList            Timeout

-----------------------------------------------------------------------------------------------------------------------------------

 

 

[Bypass-Queued Requests]

 

IRP               SRB Type   SRB               XRB               Command           MDL               SGList            Timeout

-----------------------------------------------------------------------------------------------------------------------------------

 

 

[Outstanding Requests]

 

IRP               SRB Type   SRB               XRB               Command           MDL               SGList            Timeout

-----------------------------------------------------------------------------------------------------------------------------------

 

 

[Completed Requests]

 

IRP               SRB Type   SRB               XRB               Command           MDL               SGList            Timeout

-----------------------------------------------------------------------------------------------------------------------------------




커널에서 동기화 객체를 기다리는 것이 있는지 확인해 보았지만 없었습니다.

0: kd> !locks

**** DUMP OF ALL RESOURCE OBJECTS ****

KD: Scanning for held locks.........

89274 total locks




그렇다면 CPU가 바빠서 발생하는 이슈일지 모른다고 생각해서 CPU의 상태를 확인해보았으니 IDLE 상태 였습니다.

0: kd> !cpuinfo

CP  F/M/S Manufacturer  MHz PRCB Signature    MSR 8B Signature Features

 0  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

 1  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

 2  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

 3  6,79,1 GenuineIntel 2295 0b00002a00000000                   311b3fff

                      Cached Update Signature 0b00002a00000000

                     Initial Update Signature 0b00002a00000000

0: kd> !running

Process PID Thread           Id Pri Base Pri Next CPU CSwitches User          Kernel State              Time Reason

======= === ================ == === ======== ======== ========= ==== =============== ======= =============== ==============

Idle      0 fffff8035d3d5940  0   0        0        0  24448367    0   23h:56:06.250 Running 1d.00:48:53.796 Executive

Idle      0 ffffdf005f631000  0   0        0        1  20088217    0   23h:48:42.703 Running          3s.984 WrCalloutStack

Idle      0 ffffdf005f6b9000  0   0        0        2  18610602    0   23h:58:19.172 Running 1d.00:48:53.796 Executive

Idle      0 ffffdf005f741000  0   0        0        3  25365439    0 1d.00:00:03.219 Running 1d.00:48:53.796 Executive

 

Count: 4 | Show Unique Stacks

 

0: kd> !mex.us -cpu

4 threads: ffffdf005f6b9000 ffffdf005f741000 fffff8035d3d5940 ffffdf005f631000

    fffff8035d223ff1 nt!PpmIdleGuestExecute+0x15

    fffff8035d109eac nt!PpmIdleExecuteTransition+0xcbc

    fffff8035d10903a nt!PoIdle+0x33a

    fffff8035d17afac nt!KiIdleLoop+0x2c

 

1 stack(s) with 4 threads displayed (4 Total threads)




lpc의 상태를 확인해보니 svchost.exe가 explorer에 lpc message를 보내고 기다리는 것이 확인 됩니다.

0: kd> !lpcwait

Server Process ffffab06`b8137800  Connection Port ffffab06`b853c540  (\Device\HarddiskVolume1\Windows\explorer.exe)

 

    Client Thread        Client Wait Time     Client Message       Server Thread   

    =================    =================    =================    =================

    ffffab06`b1b28800           1:25.406      ffffce0e`5b04dcf0                                                          (\Device\HarddiskVolume1\Windows\System32\svchost.exe)

 

    1 thread waiting




svchost.exe의 Thread를 확인해보니 logoff를 처리하던 것으로 보입니다.

0: kd> kc

  *** Stack trace for last set context - .thread/.cxr resets it

 # Call Site

00 nt!KiSwapContext

01 nt!KiSwapThread

02 nt!KiCommitThreadWait

03 nt!KeWaitForSingleObject

04 nt!AlpcpSignalAndWait

05 nt!AlpcpReceiveSynchronousReply

06 nt!AlpcpProcessSynchronousRequest

07 nt!NtAlpcSendWaitReceivePort

08 nt!KiSystemServiceCopyEnd

09 ntdll!NtAlpcSendWaitReceivePort

0a RPCRT4!LRPC_BASE_CCALL::DoSendReceive

0b RPCRT4!I_RpcSendReceive

0c combase!CMessageCall::CallI_RpcSendReceive

0d combase!ThreadSendReceive

0e combase!CSyncClientCall::SwitchAptAndDispatchCall

0f combase!CSyncClientCall::SendReceive2

10 combase!SyncClientCallRetryContext::SendReceiveWithRetry

11 combase!CSyncClientCall::SendReceiveInRetryContext

12 combase!DefaultSendReceive

13 combase!CSyncClientCall::SendReceive

14 combase!CClientChannel::SendReceive

15 combase!NdrExtpProxySendReceive

16 RPCRT4!NdrpClientCall3

17 combase!ObjectStublessClient

18 combase!ObjectStubless

19 combase!RemoteReleaseRifRefHelper

1a combase!RemoteReleaseRifRef

1b combase!CStdMarshal::DisconnectCliIPIDs

1c combase!CStdMarshal::Disconnect

1d combase!CStdIdentity::{dtor}

1e combase!CStdIdentity::CInternalUnk::Release

1f netprofmsvc!ATL::IConnectionPointImpl<CImplINetworkListManager,&IID_INotifyNetworkGlobalCostEvents,ATL::CComDynamicUnkArray>::Unadvise

20 netprofmsvc!CImplINetworkListManager::UnadviseAndRemoveSessionCookie<&IID_INotifyNetworkGlobalCostEvents>

21 netprofmsvc!CImplINetworkListManager::PurgeClients

22 netprofmsvc!EnterPurgeClientsCallback

23 combase!EnterForCallback

24 combase!SwitchForCallback

25 combase!PerformCallback

26 combase!CObjectContext::InternalContextCallback

27 combase!CObjectContext::ContextCallback

28 combase!CContextSwitcher::ContextCallback

29 netprofmsvc!NetProfileManUserLogOff

2a ntdll!TppSimplepExecuteCallback

2b ntdll!TppWorkerThread

2c KERNEL32!BaseThreadInitThunk

2d ntdll!RtlUserThreadStart




Explorer는 파일을 닫는 중이었는데 백신 프로그램의 필터 드라이버인 TmXPFlt가 IO가 더 진행되지 못하게 막고 있었습니다.

0: kd> !us -p ffffab06b8137800

1 thread [stats]: ffffab06b8121080

    fffff8035d17e576 nt!KiSwapContext+0x76

    fffff8035d0d74fd nt!KiSwapThread+0x17d

    fffff8035d0d6f9f nt!KiCommitThreadWait+0x14f

    fffff8035d0d8d77 nt!KeWaitForSingleObject+0x377

    fffff8022e82bce3 TmXPFlt+0x1bce3

    fffff8022e814884 TmXPFlt+0x4884

    fffff8022e814d65 TmXPFlt+0x4d65

    fffff8022e814f65 TmXPFlt+0x4f65

    fffff8022e4b3f8d TmPreFlt!TmpQueryFullName+0x1e85

    fffff8022e4b40d8 TmPreFlt!TmpQueryFullName+0x1fd0

    fffff8022c603d15 FLTMGR!FltpPerformPostCallbacks+0x2a5

    fffff8022c603756 FLTMGR!FltpPassThroughCompletionWorker+0x76

    fffff8022c605299 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x239

    fffff8022c603146 FLTMGR!FltpDispatch+0xb6

    fffff8035d4e75a0 nt!IopCloseFile+0x150

    fffff8035d5142c5 nt!ObCloseHandleTableEntry+0x245

    fffff8035d43098b nt!NtClose+0xcb

    fffff8035d187503 nt!KiSystemServiceCopyEnd+0x13

    00007ffe863c5ce4 ntdll!NtClose+0x14

    00007ffe83335aa2 KERNELBASE!CloseHandle+0x62

    00007ffe82f02560 SHCORE!CGenericFileHandle::Release+0x160

    00007ffe82f02082 SHCORE!CFileStream::~CFileStream+0xd2

    00007ffe82f00d35 SHCORE!CFileStream::Release+0x35

    00007ffe84b0d273 SHELL32!IconCacheSave+0x18965b

    00007ffe84983a05 SHELL32!SHDesktopMessageLoop+0x45

    00007ff694781468 Explorer!wWinMain+0x714

    00007ff694810727 Explorer!__wmainCRTStartup+0x1c7

    00007ffe83ce8364 KERNEL32!BaseThreadInitThunk+0x14

    00007ffe8638e851 ntdll!RtlUserThreadStart+0x21


1 stack(s) with 1 threads displayed (1 Total threads)



분석 결과를 보면 사용자는 Logoff를 하려고 하였는데 백신 제품이 IO를 잡고 있어서 시스템이 멈춘 것으로 보인 증상이었습니다.


'Debugging' 카테고리의 다른 글

Windows Server 2003 BugCheck 0x7E  (0) 2019.01.26
Symbol Server 설정 (공유, HTTP)  (0) 2018.03.04
[디버거 명령]!Mex.p  (0) 2017.09.25
[디버깅 명령]!mex.help  (0) 2017.09.24

WinDbg를 사용한 디버깅을 강의할 일이 있었는데 Release 한 제품에 대한 디버깅을 위해서 Symbol 서버를 구축해야 한다는 말씀들 드렸더니 SymStore 사용법이나 IIS 를 이용한 HTTP 기반의 Symbol server 구축에 대한 가이드가 있으면 좋겠다는 의견이 있어 이 블로그를 작성 하였습니다.

물론 저는 한번 구현해보는 수준으로 해본 것으로 실제 상용 제품의 Symbol Server를 구축 하시려고 하면 좀 더 고려할 것이 많을 것으로 보입니다.


SymStore 란?

SymStore는 심볼 저장소를 만드는 도구로 Debugging Tools for Windows 패키지에 포함되어 있습니다.
SymStore는 이미지의 타임 스탬프와 이미지 크기 또는 서명과 PDB 파일을 기간에 따라서 심볼을 찾을 수 있도록 심볼 파일을 보관 합니다.
SymStore를 사용하면 모든 심볼을 하나의 서버에 보관할 수 있으며 해당 제품이나 모듈에 대한 지식이 없이도 디버거가 심볼을 검색할 수 있습니다.
하지만 public 심볼과 private 실볼은 동일한 서명과 파일의 기간이 동일하기 때문에 동일한 서버에 보관할 수 없습니다.


SymStore 트랜잭션
SymStore은 add와 delete 라는 두 개의 트랜잭션이 있습니다.
심볼 저장소가 만들어지만 심볼 저장소로 사용되는 파일 서버의 파일 공유 루트에 000admin 이라는 폴더가 만들어지고 트랜잭션을 기록하는 파일이 트랜잭션당 하나 만들어 지고 Server.txt와 History.txt 파일이 만들어 집니다. Server.txt에는 현재 서버에 있는 모든 트랜잭션 목록이 들어 있고 History.txt에는 모든 트랜잭션의 기록이 시간순으로 있습니다.

add와 del 옵션을 사용해서 트랜잭션을 수행 합니다. /p 옵션을 사용하면 실제 파일이 추가되는 것이 아니고 파일에 대한 포인터가 추가된다고 하는데 별도의 심볼 서버를 운영하는 것이 더 간편하다고 생각되어 /p는 사용하지 않는게 나을 것으로 보입니다.

심볼 저장소를 만들 때 인덱스 파일과 실제 저장소를 나누어서 만들 수 있다고 되어 있으나 관리에 문제가 있으니 하나로 관리 하는 것이 더 좋다고 생각 됩니다. 대신 심볼 서버를 주기적으로 백업해주는 것이 좋을 것으로 생각 됩니다.

그리고 SymStore는 여러 사용자가 동시에 트랜잭션을 실행하는 것을 지원하지 않으므로 일일 빌드 또는 제품 출시를 위한 빌드에서 한 번만 수행하는 것이 좋습니다.


트랜잭션 예제
심볼 파일을 심볼 스토어에 추가하는 것은 아래와 같은 명령을 사용 합니다. MyApp 이라는 빌드 서버의 공유 폴더에서 심볼을 가져오는 것으로 되어 있는데 심볼 파일이 있는 경로에서 Symstore를 실행한다면 .\ 와 같은 경로를 지정할 수도 있습니다.
symstore add /r /f \\Myapp\appserver\x64\Release /s \\MySymServer\symsrv /t "My Application" /v "Build 001" /c "New Build"

트랜잭션을 삭제하는 것은 아래와 같이 트랜잭션 번호를 주어서 삭제할 수 있습니다.
symstore del /i 0000000001 /s \\MySymServer\symsrv

몇번 트랜잭션을 추가, 삭제 하였더니 아래와 같은 기록이 남았습니다.

Server.txt
0000000006,add,file,03/04/2018,16:34:40,"CreateProcess","1.0","The first build",

History.txt
0000000001,add,file,03/03/2018,15:46:26,"title","version","comment",
0000000002,add,file,03/03/2018,15:51:02,"title","version","comment",
0000000003,add,file,03/04/2018,16:15:24,"title","version info","comment",
0000000004,del,0000000001
0000000005,del,0000000002
0000000006,add,file,03/04/2018,16:34:40,"My Application","Build 001","New build",
0000000007,del,0000000003

그리고 0000000001 트랜잭션 파일에는 아래와 같이 기록이 남아 있습니다.
"appserver.exe\5A5ADF8B4f000","D:\MyApp\appserver\Release\appserver.exe"
"appserver.pdb\DAE2D118C40348C4981D98DF6D249C046","D:\MyApp\appserver\Release\appserver.pdb"


심볼 스토리지 포맷
Symstore는 파일 시스템 자체를 데이터베이스로 사용합니다. 심볼 파일 타임 스탬프, 서명, 파일 기간 그리고 다른 데이터를 사용하여 폴더 이름을 만들어서 관리 합니다.
아래 예는 SymStore 설명에 있는 예제 입니다.
Directory of \\mybuilds\symsrv\acpi.dbg
10/06/1999  05:46p      <DIR>          .
10/06/1999  05:46p      <DIR>          ..
10/04/1999  01:54p      <DIR>          37cdb03962040
10/04/1999  01:49p      <DIR>          37cdb04027740
10/04/1999  12:56p      <DIR>          37e3eb1c62060
10/04/1999  12:51p      <DIR>          37e3ebcc27760


심볼 파일은 SRV*c:\symbols*\\mybuilds\symsrv 와 같이 설정해주면 됩니다.


Web 기반 Symbol 서버 구축
1. Windows Server 2012 Standard 설치
2. IIS 설치
  2.1 Server Manager를 실행 한 후 우측 상단의 Manage - Add Roles and Features - Next - Next - Next - Web Server (IIS) - Web Server 선택 후
      Management Tools 에서 IIS Management Script and Tools 선택 하여 설치
  2.2 Web Server (IIS) - Web Server - Security - Windows Authentication 선택하여 설치
3. Server Manager에서 Tools 를 선택 후 Innetnet Information service (IIS) Manager 실행
4. C:\Symbols 폴더 만들기
5. 서버명 - sites - Default Web Site에서 오른쪽 마우스 클릭하여 Add Virtual Directory 선택 후 Alias 에 Symbols 입력하고 Path에 c:\Symbols 입력하고 OK
6. 서버명을 클릭한 후 가운데 Management 아래에 있는 Configuration Editor 더블 클릭
7. Section 에서 system.applicationHost - sites 선택 후 virtualDirectoryDefaults - allowSubDirConfig 를 False 로 변경
8. 서버명 - Sites - Default Web Site - Symbols 를 클릭한 후 IIS 아래에 있는 Directory Browsing 을 더블 클릭 한 후 Enable 선택
9. Default Web Site 를 클릭한 후 MIME Types 를 더블 클릭한 후 add 를 클릭하고 File name extension에 .* 룰 입력하고 MIME type에 application/octet-stream 입력하고
10. 서버명 - Sites - Default Web Site - Symbols 로 이동한 후 Authentication 더블 클릭후 Windows Authentication 만 Enable 하고 나머지는 Disable 함
   (만약 Windows Authentication이 없으면 2.2 과정에서 추가가 안 된 것임)
  10.1 Authentication - Windows Authentication 선택 후 우측의 Providers 선택한 후 Negotiate 를 선택 후 Remove 선택


WinDbg 설정
1. 인증을 처리할 수 있도록 prompts 설정합니다.
   !sym prompts on
2. 심볼 서버를 설정합니다.
  .sympath srv*c:\Mysymbols*http://192.168.1.51/sym;srv*c:\OSsymbols*https://msdl.microsoft.com/download/symbols


참고
Using SymStore
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681417(v=vs.85).aspx

SymStore Command-Line Options
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681378(v=vs.85).aspx

HTTP Symbol Stores
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/http-symbol-stores

'Debugging' 카테고리의 다른 글

Windows Server 2003 BugCheck 0x7E  (0) 2019.01.26
System Hang 분석  (0) 2018.11.24
[디버거 명령]!Mex.p  (0) 2017.09.25
[디버깅 명령]!mex.help  (0) 2017.09.24

Mex Extension 명령 중 프로세스의 정보를 보여주는 !Mex.p 에 대해서 알아보도록 하겠습니다.


우선 !Mex.p의 사용법을 확인하기 위해서 /help를 사용해 보았습니다.


0: kd> !mex.p /help

Failed converting value '/help' to System.UInt64 for argument "Process Address" (internal name = processAddress)

!p - Displays process details


Usage:

    !p [-t] [-z] [-p <PID>] [<Process Address>] 

        -t|-threads        : Show Threads

        -z                 : Show Terminated (zombie) threads

        -p|-pid <PID>      : Finds a process via its Process ID (PID)

        Process Address    : Address of _EPROCESS Object


    !p 

        !p with no params assumes current implicit process (set with .process)


    !p [-?|-h] 

        -?|-h|-help    : Display this help text


Note: In usermode, you may not specify a PID of process Address, only the current process can be displayed

Keywords: process, pid

Current Owner: mexfeedback



Mex는 파라미터로 PID나 Process Address를 받아서 Process의 상세 정보를 출력 합니다. 그럼 Explorer의 정보를 확인하기 위해 아래 명령을 사용하여 Explorere의 Prcess Address를 확인하도록 합니다.



0: kd> !process 0 0 explorer.exe

PROCESS ffffe00100fda900

    SessionId: 1  Cid: 0c8c    Peb: 7ff66a125000  ParentCid: 0db8

    DirBase: 119a35000  ObjectTable: ffffc001ce3e1c80  HandleCount: <Data Not Accessible>

    Image: explorer.exe



Explorer의 주소는 ffffe00100fda900 로 확인 되었고 Process Address 파라미터를 사용하여 !Mex.p를 실행 합니다.



0: kd> !mex.p ffffe00100fda900

Name         Address                  Ses PID          Parent       PEB              Create Time                Mods Handle Thrd User Name

============ ======================== === ============ ============ ================ ========================== ==== ====== ==== ================

explorer.exe ffffe00100fda900 (E|K|O)   1 c8c (0n3212) db8 (0n3512) 00007ff66a125000 07-10-2017 08:39:08.606 오전  184      0   47 MyPC\admin


Command Line: C:\Windows\Explorer.EXE


Memory Details:


    VM   Peak Work Set  Commit Size PP Quota NPP Quota

    ==== ==== ========= =========== ======== =========

    2 TB 2 TB 145.94 MB    58.53 MB  1.34 MB   91.5 KB


Explorer's main thread


Show LPC Port information for process


Show Threads: Unique Stacks    !mex.listthreads (!lt) ffffe00100fda900    !process ffffe00100fda900 7



실행 결과 이름, 주소, Session, PID, 부모 process, PEB, Create Time, Module 수, Handle 수 Thread 수 그리고 사용자 이름이 출력 됩니다.

프로세스의 메모리에 대한 정보가 추가로 출력 됩니다. Windows 운영체제에 추가된 보안 기능 때문에 VM이 2TB로 보입니다.

그리고 몇가지 링크가 출력되는데 Process의 상세 정보를 개별 명령을 입력해서 확인할 필요 없이 간단하게 링크를 클릭해서 결과를 확인할 수 있습니다.



0: kd> !mex.lt ffffe00100fda900

Process      PID Thread             Id State        Time Reason

============ === ================ ==== ======= ========= =============

explorer.exe c8c ffffe00101344080  fe8 Waiting   42s.937 WrUserRequest

explorer.exe c8c ffffe001014d6080  cc4 Waiting    1s.640 WrUserRequest

explorer.exe c8c ffffe00100666080  fac Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe00101522080  a54 Waiting 1m:08.265 UserRequest

explorer.exe c8c ffffe00101534700  198 Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe00101536800  3d8 Waiting 6m:03.656 UserRequest

explorer.exe c8c ffffe00101545080  418 Waiting     765ms UserRequest

explorer.exe c8c ffffe00101542800  410 Waiting     765ms UserRequest

explorer.exe c8c ffffe0010154a080  40c Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe0010155b080  31c Waiting 3m:58.531 UserRequest

explorer.exe c8c ffffe001014f9880  d94 Waiting 1m:20.468 WrQueue

explorer.exe c8c ffffe00101516080  ddc Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe0010151c080  d40 Waiting   42s.937 UserRequest

explorer.exe c8c ffffe00101564080  d34 Waiting 1m:17.968 UserRequest

explorer.exe c8c ffffe0010155c080 1004 Waiting 3m:21.046 WrUserRequest

explorer.exe c8c ffffe0010155e080 1018 Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe00101568080 1020 Waiting 1m:17.968 UserRequest

explorer.exe c8c ffffe00101573080 1034 Waiting 1m:17.968 UserRequest

explorer.exe c8c ffffe00101574080 1038 Waiting 1m:17.968 UserRequest

explorer.exe c8c ffffe00101575080 103c Waiting   42s.937 UserRequest

explorer.exe c8c ffffe00101578080 1040 Waiting 1m:17.984 UserRequest

explorer.exe c8c ffffe0010157a080 1044 Waiting 6m:30.718 WrUserRequest

explorer.exe c8c ffffe0010157c080 1050 Waiting 2m:04.281 UserRequest

explorer.exe c8c ffffe0010157d080 1054 Waiting 1m:58.546 WrUserRequest

explorer.exe c8c ffffe00101586080 1060 Waiting 1m:17.984 WrUserRequest

explorer.exe c8c ffffe00101598500 1068 Waiting   12s.843 UserRequest

explorer.exe c8c ffffe001015ae080 1080 Waiting 3m:58.593 UserRequest

explorer.exe c8c ffffe001015b5080 1088 Waiting 1m:17.968 WrUserRequest

explorer.exe c8c ffffe000ffb25080 11d0 Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe0010014b080 11e4 Waiting 6m:30.718 WrQueue

explorer.exe c8c ffffe001020b8080  f94 Waiting   42s.937 WrUserRequest

explorer.exe c8c ffffe000ff760080  360 Waiting 3m:21.187 UserRequest

explorer.exe c8c ffffe00107423880 1578 Waiting 1m:17.968 UserRequest

explorer.exe c8c ffffe00107cba380  c48 Waiting 1m:17.968 UserRequest

explorer.exe c8c ffffe00109594080 1744 Waiting     765ms UserRequest

explorer.exe c8c ffffe00109cd6880  ba4 Waiting   53s.171 UserRequest

explorer.exe c8c ffffe0010af95880 12e8 Waiting 6m:30.718 UserRequest

explorer.exe c8c ffffe0010aad1080 1714 Waiting 1m:17.984 UserRequest

explorer.exe c8c ffffe0010b1e1880 1640 Waiting   18s.265 WrQueue

explorer.exe c8c ffffe000ffe232c0  ca8 Waiting   42s.937 UserRequest

explorer.exe c8c ffffe0010b114880 148c Waiting   18s.265 WrQueue

explorer.exe c8c ffffe000ffe98880  d10 Waiting   42s.937 WrQueue

explorer.exe c8c ffffe001025f0080  b08 Waiting     765ms WrQueue

explorer.exe c8c ffffe001019d1240  3dc Waiting   13s.796 WrQueue

explorer.exe c8c ffffe00101932880  a5c Waiting   42s.937 WrQueue

explorer.exe c8c ffffe0010b1e8880  6b4 Waiting   18s.843 WrQueue

explorer.exe c8c ffffe0010abba780  f68 Waiting   42s.937 WrQueue


Thread Count: 47



위의 결과는 Mex의 list thread 명령의 출력으로 각 Thread의 주소, TID, Thread 상태, Wait 상태로 전환된지 얼마나 지났는지, 그리고 Wait 상태로 전환된 이유에 대한 설명을 출력 합니다.



0: kd> !mex.fems -s Explorer!.*WinMain !mex.t

Process                         Thread                       CID       TEB              UserTime KernelTime ContextSwitches Wait Reason      Time State   COM-Initialized

explorer.exe (ffffe00100fda900) ffffe00101344080 (E|K|W|R|V) c8c.fe8   00007ff66a12e000   5s.641    11s.984          939044 WrUserRequest 42s.937 Waiting APTKIND_APARTMENTTHREADED (STA)


WaitBlockList:

    Object           Type                 Other Waiters

    ffffe001005352f0 SynchronizationEvent             0


Priority:

    Current Base Decrement ForegroundBoost IO Page

    10      8    0         0               0  5


# Child-SP         Return           Call Site

0 ffffd000215846b0 fffff801feaa5f1e nt!KiSwapContext+0x76

1 ffffd000215847f0 fffff801feaa5999 nt!KiSwapThread+0x14e

2 ffffd00021584890 fffff801feaa4f60 nt!KiCommitThreadWait+0x129

3 ffffd00021584910 fffff96000180288 nt!KeWaitForMultipleObjects+0x3a0

4 ffffd000215849c0 fffff9600017b361 win32k!xxxRealSleepThread+0x278

5 ffffd00021584a80 fffff96000259bcf win32k!xxxSleepThread+0xc1

6 ffffd00021584ad0 fffff801feb6bab3 win32k!NtUserWaitMessage+0x20

7 ffffd00021584b00 00007ffd8399104a nt!KiSystemServiceCopyEnd+0x13

8 00000000008ff358 00007ffd821a1527 USER32!NtUserWaitMessage+0xa

9 00000000008ff360 00007ffd82356b7d SHELL32!CDesktopBrowser::_MessageLoop+0x112

a 00000000008ff3f0 00007ff66ac08498 SHELL32!SHDesktopMessageLoop+0x3d

b 00000000008ff420 00007ff66abe8c21 Explorer!wWinMain+0x5f4

c 00000000008ff710 00007ffd81fa13d2 Explorer!CApplicationUsageTracker::OnPowerBroadcastMessage+0x334

d 00000000008ff7e0 00007ffd846854e4 KERNEL32!BaseThreadInitThunk+0x22

e 00000000008ff810 0000000000000000 ntdll!RtlUserThreadStart+0x34


Explorer 의 Main Thread를 확인하는 링크를 클릭하여 나온 결과 입니다. GUI를 가진 프로세스는 WinMain 이라는 Entry 함수를 가지는데 Mex에서는 각 Thread의 Stack을 확인하여 WinMain 함수를 가진 Thread를 찾고 정보를 출력 합니다. GUI를 가진 Process가 "응답 없음" 상태가 되는 경우 Message 처리를 하지 못하는 것인데 이 경우 WinMain Thread가 어떤 동작을 하고 있는지 확인해서 원인을 찾을 수 있습니다. 



0: kd> !kdexts.alpc /lpp ffffe00100fda900


Ports created by the process ffffe00100fda900:


ffffe001014fab00('OLE68D95701484F75BAC07FBACD02B9') 0, 5 connections

ffffe00101505e40 0 ->ffffe001014f2bb0 0 ffffe000ffda2080('svchost.exe')

ffffe001015474a0 0 ->ffffe00101547910 0 ffffe000ffd736c0('svchost.exe')

ffffe001015ac7f0 0 ->ffffe001015aca20 0 ffffe000fffe3900('svchost.exe')

ffffe001091b5e40 0 ->ffffe00101fdba80 0 ffffe001091e3300('dllhost.exe')

ffffe001012e3780 0 ->ffffe0010a9b0e40 0 ffffe00101fca900('rdpclip.exe')


Ports the process ffffe00100fda900 is connected to:


ffffe000fffaa330 0 -> ffffe000fe6fdda0('ApiPort') 0 ffffe000ffcde080('csrss.exe')

ffffe000ffd4edb0 0 -> ffffe000fffe8900('ThemeApiPort') 0 ffffe000fe6a5900('svchost.exe')

ffffe000ffb494c0 0 -> ffffe000ffdbc1e0('LSMApi') 20 ffffe000ffd736c0('svchost.exe')

ffffe001014c7570 0 -> ffffe000ffd608a0('lsasspirpc') 0 ffffe000ffd4c900('lsass.exe')

ffffe001015059e0 0 -> ffffe000ffd9a8c0('epmapper') 0 ffffe000ffda2080('svchost.exe')

ffffe00101508e40 0 -> ffffe000fffcee40('DwmApiPort') 0 ffffe000ffdd8840('dwm.exe')

ffffe00101537070 0 -> ffffe000ffd78c10('ntsvcs') 38 ffffe000ffcae900('services.exe')

ffffe00101549c70 0 -> ffffe000fef70070('PdcPort') 0 ffffe000fe69d040('System')

ffffe001015415b0 0 -> ffffe000ffd9c090('actkernel') 0 ffffe000ffd736c0('svchost.exe')

ffffe00101555e40 0 -> ffffe000fef70070('PdcPort') 0 ffffe000fe69d040('System')

ffffe00101527d70 0 -> ffffe001001b7e40('FontCachePort') 0 ffffe000fffe3900('svchost.exe')

ffffe001013d7cd0 0 -> ffffe000ffda89e0('umpo') 0 ffffe000ffd736c0('svchost.exe')

ffffe000ffdafe40 0 -> ffffe000fef70070('PdcPort') 0 ffffe000fe69d040('System')

ffffe000ffd80660 0 -> ffffe001014e5c80('webcache_{7329ea82-0845-4e4c-bd18-02b67ac065cc}_S-1-5-21-2726512140-888677503-3125549036-1001') 0 ffffe001014d4900('dllhost.exe')

ffffe000ffd1be40 0 -> ffffe000ffb22090('OLE9F792F2B42A5C2F467737E8AEF83') 0 ffffe001014d4900('dllhost.exe')

ffffe000ffcb7a30 0 -> ffffe000fffcee40('DwmApiPort') 0 ffffe000ffdd8840('dwm.exe')

ffffe001014fb840 0 -> ffffe000fffe5e40('OLE613E2E13198237E01302C92BBC53') 0 ffffe000fffe3900('svchost.exe')

ffffe001014c9cf0 0 -> ffffe000fffc7e40('eventlog') 30 ffffe000fe6a7900('svchost.exe')

ffffe00101526a30 0 -> ffffe000fef70070('PdcPort') 0 ffffe000fe69d040('System')

ffffe001015cc380 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe001016193d0 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe0010161ca50 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe0010161a770 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe0010165a070 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe00101608e40 0 -> ffffe000fe9a82c0('SessEnvPrivateRpc') 0 ffffe000fe6a5900('svchost.exe')

ffffe001096c76b0 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe001096658d0 0 -> ffffe001090c32b0('OLE2B514DB3A33CF461692869C92314') 0 ffffe001091e3300('dllhost.exe')

ffffe0010afd4700 0 -> ffffe00100b4c1a0('TermSrvApi') 0 ffffe000fe9c3640('svchost.exe')

ffffe0010ac22e40 0 -> ffffe001015eca50('msctf.serverDefault1') 0 ffffe000fe73e080('taskhostex.exe')

ffffe001093a46b0 0 -> ffffe000ffd944b0('OLE6FAB873CEB8A01A900BB6C89EA7E') 0 ffffe00101fca900('rdpclip.exe')

ffffe00100f51660 0 -> ffffe00100e50090('OLE5BB8085653D110B414538A51314E') 0 ffffe001019f3900('TSTheme.exe')



Process의 LPC 정보를 나열 하는 링크를 클릭한 결과 입니다. LPC는 Local Procedure Call 로 간단히 이야기 하면 Process 간에 통신을 하는것입니다. Explorer 프로세스가 만든 Port에 connect 되어 있는 Process와 Explorer 가 connect 한 Process의 상태를 확인할 수 있습니다.



0: kd> !us -p ffffad8ad052a080

1 thread [stats]: ffffad8ad0528080

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b6d78 nt!KeWaitForSingleObject+0x2b8

    fffffbb43e64d6f8 win32kfull!xxxRealSleepThread+0x2d8

    fffffbb43e64d377 win32kfull!xxxSleepThread2+0x97

    fffffbb43e6e4242 win32kfull!NtUserWaitMessage+0x42

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc14211204 0x7ffc14211204


1 thread [stats]: ffffad8ad22ac080

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b56b7 nt!KeWaitForMultipleObjects+0x217

    fffffbb43e64d6f8 win32kfull!xxxRealSleepThread+0x2d8

    fffffbb43e64d377 win32kfull!xxxSleepThread2+0x97

    fffffbb43e6509c9 win32kfull!xxxRealInternalGetMessage+0x919

    fffffbb43e64df5c win32kfull!NtUserGetMessage+0x8c

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc14211144 0x7ffc14211144


4 threads [stats]: ffffad8ad0677080 ffffad8ad0a8d080 ffffad8ad0a8e080 ffffad8ad0a95700

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b6d78 nt!KeWaitForSingleObject+0x2b8

    fffff801f7d0cdb8 nt!NtWaitForSingleObject+0xf8

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc177b5424 0x7ffc177b5424


5 threads [stats]: ffffad8ad0688080 ffffad8acdfe3080 ffffad8ad09f3080 ffffad8ad1b0a700 ffffad8ad061f080

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b6d78 nt!KeWaitForSingleObject+0x2b8

    fffff801f7d0c7d1 nt!ObWaitForMultipleObjects+0x2c1

    fffff801f7d0c4d9 nt!NtWaitForMultipleObjects+0xf9

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc177b5ef4 0x7ffc177b5ef4


7 threads [stats]: ffffad8ad1de1080 ffffad8ad0aa6080 ffffad8ad05dd080 ffffad8acdfcd080 ffffad8acce87080 ffffad8ad08a3080 ffffad8acd0b8700

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b6d78 nt!KeWaitForSingleObject+0x2b8

    fffffbb43e64d6f8 win32kfull!xxxRealSleepThread+0x2d8

    fffffbb43e64d377 win32kfull!xxxSleepThread2+0x97

    fffffbb43e6509c9 win32kfull!xxxRealInternalGetMessage+0x919

    fffffbb43e64df5c win32kfull!NtUserGetMessage+0x8c

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc14211144 0x7ffc14211144


10 threads [stats]: ffffad8acccfa700 ffffad8ad06fc080 ffffad8ac8ed1700 ffffad8ad15f0080 ffffad8ad0365080 ffffad8ad085c700 ffffad8ad0a63080 ffffad8ad0354080 ffffad8ace0ee080 ffffad8ad2736080

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b6d78 nt!KeWaitForSingleObject+0x2b8

    fffff801f789f104 nt!KiSchedulerApc+0x304

    fffff801f78b94fe nt!KiDeliverApc+0x23e

    fffff801f79f39a3 nt!KiApcInterrupt+0xc3

    fffff801f7cc0405 nt!PspUserThreadStartup+0x35

    fffff801f79f5a86 nt!KiStartUserThread+0x16

    fffff801f79f5a00 nt!KiStartUserThreadReturn

    00007ffc17780d30 0x7ffc17780d30


22 threads [stats]: ffffad8ad4141080 ffffad8ad412d040 ffffad8acba56080 ffffad8ad06a5080 ffffad8ad249b080 ffffad8ad09f6700 ffffad8ad1b8c700 ffffad8ace697080 ffffad8acba54080 ffffad8ad40a1080 ...

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b62e8 nt!KeRemoveQueueEx+0x238

    fffff801f78b5dfd nt!IoRemoveIoCompletion+0x8d

    fffff801f78b4beb nt!NtWaitForWorkViaWorkerFactory+0x30b

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc177b8c34 0x7ffc177b8c34


30 threads [stats]: ffffad8ad06a1080 ffffad8ad08bc280 ffffad8ad09f4080 ffffad8ad06a6080 ffffad8acd02c080 ffffad8acba60080 ffffad8ad02b1080 ffffad8acba68080 ffffad8ad11c5700 ffffad8ad06643c0 ...

    fffff801f79f52f6 nt!KiSwapContext+0x76

    fffff801f78b7a9a nt!KiSwapThread+0x16a

    fffff801f78b7461 nt!KiCommitThreadWait+0x101

    fffff801f78b56b7 nt!KeWaitForMultipleObjects+0x217

    fffff801f7d0c7d1 nt!ObWaitForMultipleObjects+0x2c1

    fffff801f7d0c4d9 nt!NtWaitForMultipleObjects+0xf9

    fffff801f79fb413 nt!KiSystemServiceCopyEnd+0x13

    00007ffc177b5ef4 0x7ffc177b5ef4


8 stack(s) with 80 threads displayed (100 Total threads)

20 stack(s) were not displayed because we could not switch to thread context, or stack trace was empty


!us 명령은 흥미로운 Mex 명령 입니다. 디버깅을 하다보면 반복되는 콜스택이 화면 전체를 채워버리는 경우를 많이 보았을 것 입니다. 커널스택에서 Thread가 Wait 상태에 들어가면 ObWaitForMultipleObjects 함수를 호출하는 콜스택이 반복적으로 보이게 됩니다. 이 경우 !us 명령은 아주 유용합니다.

!us 는 반복적으로 보이는 콜스택은 1번만 보여주고 각 Thread의 address를 출력하여 어떤 Thread 들이 동일한 콜스택을 보이고 있는지 보여 줍니다.


!Mex.p 명령을 통해서 나오는 출력들을 사용해서 많은 정보를 확인할 수 있는데 각 Case study에 대해서는 나중에 설명하도록 하겠습니다.

'Debugging' 카테고리의 다른 글

Windows Server 2003 BugCheck 0x7E  (0) 2019.01.26
System Hang 분석  (0) 2018.11.24
Symbol Server 설정 (공유, HTTP)  (0) 2018.03.04
[디버깅 명령]!mex.help  (0) 2017.09.24

WinDbg Extension들은 .help 라는 명령을 모두 가지고 있어 해당 Extension에 어떤 명령이 있는지 그리고 어떻게 사용할 수 있는지 보여줍니다.


Mex extension에서 .help 라는 명령이 있어 어떤 명령들이 있는지 알 수 있습니다.

0: kd> !mex.help
Mex External 3.0.0.7172 Loaded!
Mex currently has 255 extensions available.  Please specify a keyword to search.
Or browse by category:

All PowerShell[6] SystemCenter[3] Networking[12] Process[5] Mex[2] Kernel[27] DotNet[32] Decompile[15] Utility[40] Thread[27] Binaries[6] General[22] 

너무 많은 명령들이 있기 때문에 Process를 클릭해보면 아래와 같이 Process에 해당하는 명령만 자세히 설명해 줍니다.

0: kd> !mex.help -cat 'Process'
Command                 Description                              Category
======================= ======================================== ========
conhost          (!con) Displays console host (conhost.exe) info Process
ldap                    Displays LDAP client or server details   Process
mappeddrives (!mdrives) Displays mapped drives                   Process
mheap                   A DML'd version of !heap.                Process
p                       Displays process details                 Process

한단계 더 자세히 들어가 보면 process의 상세한 정보를 보여주는 !mex.p 명령에 대해서 아래와 같이 설명하고 있습니다.


0: kd> !mex.p -?
!p - Displays process details

Usage:
    !p [-t] [-z] [-p <PID>] [<Process Address>] 
        -t|-threads        : Show Threads
        -z                 : Show Terminated (zombie) threads
        -p|-pid <PID>      : Finds a process via its Process ID (PID)
        Process Address    : Address of _EPROCESS Object

    !p 
        !p with no params assumes current implicit process (set with .process)

    !p [-?|-h] 
        -?|-h|-help    : Display this help text

Note: In usermode, you may not specify a PID of process Address, only the current process can be displayed
Keywords: process, pid
Current Owner: mexfeedback


'Debugging' 카테고리의 다른 글

Windows Server 2003 BugCheck 0x7E  (0) 2019.01.26
System Hang 분석  (0) 2018.11.24
Symbol Server 설정 (공유, HTTP)  (0) 2018.03.04
[디버거 명령]!Mex.p  (0) 2017.09.25

+ Recent posts