Platform Engineer

시스템 행 현상이 발생 되었을때 원인 분석을 하는 방법에 대해서 글을 써보려고 하고 다음번 글에서는 행 덤프를 분석하는 방법을 쓰려고 합니다.

Windows나 ESXi 모두 커널 레벨에서 행이 발생하였을때 Reset을 해서 시스템을 재부팅하는 방법으로 문제를 해결하는 경우가 종종 있습니다. 하지만 문제가 빈번하게 재현되고 운영중인 Application이 중요한 역할을 하는 경우 원인 분석을 해야 하는 경우가 많이 있습니다. 행 현상이 발생하면 NMI를 이용해서 덤프를 수집하는 방법을 알아보겠습니다.

NMI란 무엇인가?

우선 NMI가 무엇인지 확인해보면 Wiki에 Non-maskable interrupt 라고 되어 있고 하드웨어가 발생시키는 인터럽트로 시스템이 ignore 할 수 없다고 되어 있습니다. 하지만 NMI는 하드웨어에서 발생시키는 경우만 있는 것이 아니라 행 분석을 위해서 시스템에 있는 NMI switch를 눌러(쇼트)서 수동으로 발생시키는 경우도 있습니다.

https://en.wikipedia.org/wiki/Non-maskable_interrupt

먼저 하드웨어로 인한 문제를 확인해 보겠습니다. 아래 HPE의 문서를 보면 하드웨어 이슈로 NMI가 호출되어 VMware의 ESXi에서 PSOD가 발생되었다고 합니다.

Advisory: (Revision) VMware - HPE ProLiant Gen8 Servers running VMware ESXi 5.5 Patch 10, VMware ESXi 6.0 Patch 4, Or VMware ESXi 6.5 May Experience Purple Screen Of Death (PSOD): LINT1 Motherboard Interrupt

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c05392947

ESXi host fails with intermittent NMI purple diagnostic screen on HP servers (2085921)

https://kb.vmware.com/s/article/2085921

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers (2149043)

https://kb.vmware.com/s/article/2149043

VMware 환경에서 하드웨어로 인한 NMI 크래시에 대해서 설명하고 있습니다.

"LINT1 motherboard interrupt" error in an ESX/ESXi host (1804)

https://kb.vmware.com/s/article/1804

Windows 환경에서도 유사하가 하드웨어(Memory) 오류로 NMI가 호출되어 시스템이 BSOD가 발생된 것이 확인됩니다.

NMI Memory Parity error received during shutdown on Windows 7 and Windows Server 2008 R2

https://support.microsoft.com/en-au/help/2845432/nmi-memory-parity-error-received-during-shutdown-on-windows-7-and-wind

물리적인 하드웨어 뿐만 아니라 가상 하드웨어로 인해서 NMI가 발생할 수도 있습니다. 

VMware ESXi 5.5.x and 6.x hosts experiences a purple diagnostic screen mentioning ALERT: NMI: 709: NMI IPI received (2149704)

https://kb.vmware.com/s/article/2149704

하드웨어로 인한 NMI가 발생한 경우 하드웨어 업체에 연락을 해서 관련 이슈가 있는지 파악을 하고 하드웨어 점검, Firmware, Driver 업데이트 등을 진행할 수 있습니다. 문제가 계속 재현되는 경우 하드웨어를 교체해야할 수도 있습니다.

시스템 행 현상이 발생하였을 때 NMI를 이용한 행 덤프 수집

시스템 행 현상은 ESXi host에 ssh 접속이 안되거나 Windows 의 경우 RDP 등이 접속안되는 상태를 이야기 합니다. 결국 시스템의 중요 프로세스가 응답하지 못하는 상태가 되어 SSH 연결이나 RDP 연결을 받아주지 못하는 경우를 이야기 합니다. 이런 경우 우선 Ping을 해서 하드웨어 레벨에서 행이 걸렸는지 확인해볼 수 있습니다. Ping은 되는데 SSH나 RDP가 안되는 경우 하드웨어가 아닌 소프트웨어 이슈로 시스템이 응답하지 않는 것입니다.

시스템 행 현상이 발생하면 일반적으로 Reset 키를 눌러서 시스템을 재부팅을 하게 되는데 기술지원 계약이 되어 있는 경우 NMI를 이용해서 Dump를 수집하면 원인분석을 의뢰 할 수 있습니다.

-------------------------------------------------------- ESXi -----------------------------------------------------------

VMware는 KB문서를 통해서 시스템 행 현상이 있을 때 덤프를 수집하는 방법을 가이드 하고 있습니다.

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers (2149043)

https://kb.vmware.com/s/article/2149043https://kb.vmware.com/s/article/1014767

문서의 내용을 살펴보면 행 현상이 어떤 것인지 정의를 먼저 하고 있습니다. 행 현상은 vSphere client 에 응답하지 않거나, Ping에 응답하지 않거나, ESXi에서 실행중인 VM이 network에 응답하지 않거나, 콘솔 명령에 응답하지 않거나, Alt+F12를 콘솔에서 눌렀을때 VMkernel log가 화면에 출력되지 않는 경우를 이야기 합니다. 행 현상이 하드웨어에 의한 것인지 확인하기 위해 NumLock 키를 눌러 보거나 디스크나 네트워크에 워크로드가 있는지 확인, Ping으로 확인하는 등의 작업을 할 수 있지만 원인 분석을 위해서는 NMI를 이용해서 덤프를 수집해야 합니다.

Determining why an ESX/ESXi host does not respond to user interaction at the console (1017135)

https://kb.vmware.com/s/article/1017135?CoveoV2.CoveoLightningApex.getInitializationData=1&r=2&ui-communities-components-aura-components-forceCommunity-seoAssistant.SeoAssistant.getSeoData=1&other.KM_Utility.getArticleDetails=1&other.KM_Utility.getArticleMetadata=2&other.KM_Utility.getUrl=1&other.KM_Utility.getUser=1&other.KM_Utility.getAllTranslatedLanguages=2&ui-comm-runtime-components-aura-components-siteforce-qb.Quarterback.validateRoute=1

NMI를 사용해서 수동으로 덤프를 수집하기 위해서는 ESXi에 설정이 필요한데 ESXi 5.0 이후로는 별도의 설정 없이 NMI 버튼을 누르면 PSOD 덤프가 수집 됩니다.

KB의 마지막 부분에는 각 하드웨어 별로 NMI를 발생시키는 방법이 가이드 되어 있습니다.

Triggering the NMI

The NMI button or switch location varies depending on the hardware. A small set of examples are available:

IBM x3650 M2 – The NMI button is on the diagnostic panel. There may also be a Send NMI button in the RSA. For more information, see the x3650 M2 Installation and Users Guide.

HP Proliant – The NMI button or jumper is on the motherboard. There is also a Send NMI button in the iLO. For more information, see Performing an HP ProLiant server NMI crash dump.

Dell R900 – The NMI button is on the front panel. For more information, see the R900 Systems Hardware Owner's Manual.

Fujitsu PRIMERGY Servers (RX/TX) - The NMI button is on the front of the server. For more information, see the Operating Manual for your PRIMERGY Servers. The manual can be found at the Fujitsu website.

Click [Industry standard servers] - [PRIMERGY Servers]

Select your PRIMERGY Servers from the pulldown menu. For example, [PRIMERGY RX Servers] - [PRIMERGY RX300 Sriese] - [PRIMERGY RX300 S7]

Download the Operating Manual and check for the NMI button location.

Cisco UCS – The NMI can be sent via IPMI or the UCS Manager command-line interface:

IPMI command – ipmitool -I lan -H <RemoteServerBMCAddress> -U <Username> -a chassis power diag

UCSM command – diagnostic-interrupt.

For more information, see the Cisco UCS command-line reference documentation for the diagnostic-interrupt command.

The preceding links were correct as of November 6, 2013. If you find a link is broken, provide feedback and a VMware employee will update the link.

ESXi 호스트가 아닌 VM에 행 현상이 발생할 경우에도 NMI를 이용해서 덤프를 수집할 수 있습니다. ESXi 에서는 Snapshot을 이용해서 메모리 파일을 덤프 파일로 변환하는 방법으로 덤프를 수집할 수 도 있지만 VM에 NMI 인터럽트를 전달해서 행 덤프를 수집할 수도 있습니다. vCenter Web Clinet를 이용하거나 VM-support 명령 또는 vmdumper 명령을 사용해서 덥프를 수집할 수 있습니다.

How to send NMI to Guest OS on ESXi 6.x (2149185)

https://kb.vmware.com/s/article/2149185

How to capture a vmcore of hung Red Hat Enterprise Linux VMware® guest system using VMware® "vmss2core" tool ?

https://access.redhat.com/solutions/411653

아래 문서는 NMI로 인해 Windows VM이 크래시 된 것에 대한 설명을 하고 있습니다.

Windows virtual machines fails with a Stop Error: Hardware Malfunction - Call your hardware vendor for support (2105345)

https://kb.vmware.com/s/article/2105345

아래 문서에서는 Red Hat 리눅스가 행 현상이 있을때 ESXi 에서 NMI를 발생하는 방법을 설명하고 있습니다.

Red Hat Enterprise Linux - How to Force a Crash on a Hung Linux Virtual Machine Running on VMware ESXi Server

https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0105964

------------------------------------------------------ Windows ---------------------------------------------------------

Microsoft 에서는 아래 문서에서 행 현상이 있을때 덤프를 수집하는 방법을 설명하고 있습니다.

How to generate a kernel or a complete memory dump file in Windows Server

https://support.microsoft.com/en-us/help/969028/how-to-generate-a-kernel-or-a-complete-memory-dump-file-in-windows-ser

이 문서에서 별도로 행 현상에 대해서 설명을 하고 있지는 않지만 ESXi와 비슷하게 RDP 접속해보기, Numslock 눌러보기, Ping 해보기 등으로 행 현상이 있는지 확인해볼 수 있습니다.

Windows 는 커널 덤프, 전체 덤프와 같이 덤프의 유형이 있는데 각 유형에 따라서 적절한 페이지 파일 크기를 설정해 주어야 덤프파일이 정상적으로 수집됩니다. 커널 덤프의 경우 Windows 커널이 사용하는 메모리만 덤프 파일에 저장하는 것으로 커널의 메모리 사용량에 따라서 2 ~ 16GB 정도면 충분한 크기라고 할 수 있습니다. 전체 덤프의 경우 물리 메모리의 내용을 모두 덤프 파일에 저장하는 것으로 물리메모리 크기 + 1MB 이상의 페이지 파일이 있어야 덤프를 수집할 수 있습니다. Windows 커널의 행 현상에 대해서는 커널 덤프로 분석이 가능하지만 유저모드 프로세스의 행 현상은 전체 덤프를 수집해야 분석이 가능할 수 있습니다.

Windows 시스템에서는 일반적으로 키보드 (오른쪽 Ctrl 키를 누른 상태에서 Scroll Lock 를 두번 누르기)를 이용해서 덤프를 수집할 수 있는데 별도의 설정을 키보드에 해야하기 때문에 문제가 발생하기 전에 운영하는 시스템에 모두 키보드 덤프를 설정해 두어야 합니다. 덤프 생성을 위한 키를 변경할 수도 있으며 

Forcing a System Crash from the Keyboard

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/forcing-a-system-crash-from-the-keyboard

Windows 시스템에서도 NMI를 이용해서 덤프를 수집할 수 있습니다. 

How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system

https://support.microsoft.com/en-us/help/927069/how-to-generate-a-complete-crash-dump-file-or-a-kernel-crash-dump-file

PowerShell을 사용해서 Hyper-V 에서 VM에 NMI 인터럽트를 발생시키는 방법도 있습니다.

Debug-VM

https://docs.microsoft.com/en-us/powershell/module/hyper-v/debug-vm?view=win10-ps

Azure 환경에서 Serial console을 사용해서 Guest에 NMI를 보내는 방법도 있습니다. AWS에서는 어떻게 NMI를 보낼 수 있는지 찾지를 못했습니다.

Use Serial Console for SysRq and NMI calls

https://docs.microsoft.com/ko-kr/azure/virtual-machines/troubleshooting/serial-console-nmi-sysrq

다음 번에는 수집된 덤프를 분석하는 방법을 써보려고 합니다.

감사합니다.

최근에 BSOD 분석을 넘어서 PSOD 분석을 하고 있습니다. 처음에는 gdb 사용법을 전혀 몰라서 고생을 했는데 이제는 간단한 분석은 회사 시스템을 통해서 할 수 있게 되었습니다.

디버깅을 하면서 느낀 것은 Windows Kernel Debugging과 원리는 비슷한데 실제 구현은 다르다는 것입니다. 비슷하면서 다른 점을 확인해보면 Windows kernel에 있는 spinlock이라는 개념이 동일하게 Linux와 ESXi에 있고 ESXi 에서는 spinlock을 오래 소유하면 시스템이 크래시 될 수 있습니다. Windows 에서는 Spinlock을 오래 소유하면 행만 말생하고 크래시가 되지는 않습니다. (시스템을 행 상태로 둘 것인지? 아니면 크래시를 해서라도 행을 해소하고 원인 분석을 할지는 업체마다 판단이 다릅니다.)

아래 VMware 문서의 설명을 보면 Spinlock을 오래 소유하고 있어서 Spinlock count가 한계에 달해서 시스템이 크래시 되었다고 합니다. 스택에 나오는 것은 Spinlock을 소유하기 위해 대기하는 Thread 이어서 원인을 찾기 위해서는 Spinlock을 소유한 Thread를 찾아야합니다. 일반적으로 원인은 ESXi 또는 3^rd party kernel driver 가 spinlock을 해제하지 않았기 때문입니다.

Microsoft는 WinDbg를 통해서 BSOD를 분석할 수 있게 공개하였지만 VMware는 디버깅 방법이 공개되어 있지 않기 때문에(아마도 공개 안 되어 있을 것 같습니다.) VMware support 부서에 연락해서 기술지원을 받아야 할 것입니다. 만약 원인 분석 보다는 문제 예방을 원하실 경우 ESXi 와 각종 드라이버를 최신으로 update 하면 좋습니다. 신규 버그가 아니라면 패치를 설치해서 기존 문제들을 해결할 수 있습니다. 그래도 문제가 재현된다면 core dump 파일을 수집해서 업체의 분석을 받아야 합니다.

Understanding a "Spin count exceeded" purple diagnostic screen (1020105)

https://kb.vmware.com/s/article/1020105

VMware ESX Server [Releasebuild-207095]

Spin count exceeded (iplLock) - possible deadlock

cr2=0xb6ea3fff cr3=0x22401000 cr4=0x6f0

frame=0x14028d4 ip=0x626265

es=0xffffffff ds=0xffffffff fs=0xffffffff gs=0xffffffff

eax=0xffffffff ebx=0xffffffff ecx=0xffffffff edx=0xffffffff

ebp=0x1402a3c esi=0xffffffff edi=0xffffffff err=-1 eflags=0xffffffff

*0:1024/console 1:1094/vmm0:M100 2:1086/vmware-vm 3:1118/mks:dby-d

4:1109/vmm0:M102 5:1116/vmm0:dby- 6:1096/mks:M1000 7:1082/vmm0:M100

@BlueScreen: Spin count exceeded (iplLock) - possible deadlock

0x1402a3c:[0x626265]Panic+0x10 stack: 0x83821c, 0x2970608, 0x4

0x1402a90:[0x634ff3]SP_WaitLock+0x1ca stack: 0x2970600, 0x1402ab8, 0x9d75ef

0x1402a9c:[0x9b1386]cosShadow+0x385 stack: 0x0, 0x2865a40, 0x2865a40

0x1402ab8:[0x9d75ef]cosShadow+0x265ee stack: 0x0, 0xa8ae9be8, 0x53ac1

0x1402af0:[0x63b947]TimerBHHandlerLoop+0x18e stack: 0x1456c98, 0x0, 0x148a798

0x1402b30:[0x63e7b1]Timer_BHHandler+0xb8 stack: 0x0, 0xdf, 0x0

0x1402b88:[0x6188c5]BH_Check+0x84 stack: 0x1, 0x1402bac, 0x1754941

0x1402bac:[0x620126]IDT_HandleInterrupt+0x85 stack: 0x1402bf8, 0x0, 0x37638000

0x1402bc0:[0x62024d]IDT_IntrHandler+0x4c stack: 0x1402bf8, 0x4028, 0x4028

0x1402c70:[0x693b7c]CommonIntr+0xb stack: 0x14897a0, 0x0, 0x1402de0

0x1402e1c:[0x763234]CpuSchedDispatch+0x487 stack: 0x2391f00, 0x14897a0, 0x0

0x1402e88:[0x765a36]CpuSchedDoWaitDirectedYield+0x351 stack: 0x0, 0x1f57f60, 0x0

0x1402ea4:[0x765b66]CpuSched_WaitIRQ+0x31 stack: 0xfedcba90, 0x6, 0x1f57f60

0x1402ec4:[0x692893]VMNIXVMKSyscall_Idle+0xe2 stack: 0x1402f6c, 0x6924e3, 0x0

0x1402ecc:[0x687538]VMNIXVMKSyscallUnpackIdle+0x7 stack: 0x0, 0x0, 0x0

0x1402f6c:[0x6924e3]HostSyscall+0xf6 stack: 0x1402fbc, 0xc03dbf98, 0x1c

0x1402fe8:[0x69187f]HostVMKEntry+0xce stack: 0x0, 0x0, 0x0

VMK uptime: 6:09:43:15.399 TSC: 1472031313725856

Starting coredump to disk Starting coredump to disk Dumping using slot 1 of 1... using slot 1 of 1... log

Windows에는 Spinlock에 의한 크래시는 없지만 인터럽트의 후속처리를 하는 DPC (Linux의 Bottom half에 해당하는 것으로 보임) 에서 너무 많은 시간 동은 실행이 되면 BugCheck 0x133이 발생합니다. 일반적으로 HW 에서 인터럽트가 발생하고 DPC 루틴을 실행할 때 너무 시간이 많이 걸려서 크래시 되는 것입니다.

Bug Check 0x133 DPC_WATCHDOG_VIOLATION

https://docs.microsoft.com/ko-kr/windows-hardware/drivers/debugger/bug-check-0x133-dpc-watchdog-violation

DPC 루틴 하나가 너무 많은 시간을 사용한 경우 콜스택만 보면 원인을 확인할 수 있으나 다수의 DPC 루틴이 실행된 경우 원인을 찾기가 힘들어집니다. 이 경우 아래 블로그를 참고해서 xPerf를 실행해야할 수도 있습니다. (꼭 Microsoft의 지원을 받으셔야 원인을 찾을 수 있습니다.)

Determining the source of Bug Check 0x133 (DPC_WATCHDOG_VIOLATION) errors on Windows Server 2012

https://blogs.msdn.microsoft.com/ntdebugging/2012/12/07/determining-the-source-of-bug-check-0x133-dpc_watchdog_violation-errors-on-windows-server-2012/

아래와 같이 HP 드라이버에서 문제가 발생할 수도 있고 Windows Kernel의 문제로 발생할 수도 있습니다.

권고: HP 네트워크 서버 어댑터 - Windows Server 2012 R2에서 ocnd64.sys v11.1.145.30 드라이버를 실행하면 Bugcheck 0x133 오류가 발생할 수 있음

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00005104es_es

FIX: Stop error 0x133 or 0x9E occurs when WHEA record is not acknowledged by SMI in Windows

https://support.microsoft.com/en-us/help/2877237/fix-stop-error-0x133-or-0x9e-occurs-when-whea-record-is-not-acknowledg

Analyzing the dump showed the following stack

DPC_WATCHDOG_VIOLATION (133)

The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL

or above.

Arguments:

Arg1: 0000000000000001, The system cumulatively spent an extended period of time at

DISPATCH_LEVEL or above. The offending component can usually be

identified with a stack trace.

Arg2: 0000000000003c19, The watchdog period.

Arg3: 0000000000000000

Arg4: 0000000000000000

Debugging Details:

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

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x133

PROCESS_NAME: System

CURRENT_IRQL: d

ANALYSIS_VERSION: 6.13.0015.1713 (debuggers(dbg).130203-2012) amd64fre

LAST_CONTROL_TRANSFER: from fffff802145e3cb3 to fffff80214464440

STACK_TEXT:

fffff880`0c4a54f8 fffff802`145e3cb3 : 00000000`00000133 00000000`00000001 00000000`00003c19 00000000`00000000 : nt!KeBugCheckEx

fffff880`0c4a5500 fffff802`144a8774 : fffff880`0c4a5670 00000000`0042f906 fffff880`0c4a5680 fffff780`00000320 : nt! ?? ::FNODOBFM::`string'+0x14600

fffff880`0c4a5580 fffff802`14b78eca : 00000000`00000001 fffffa80`31427a01 00000000`00275f48 fffffa80`437f7000 : nt!KeUpdateTime+0x2ec

fffff880`0c4a5760 fffff802`1445d00e : 0000009f`6bc998e4 ffff7af7`41437906 fffff802`14ba2580 00001f80`004a0260 : hal!HalpTimerClockInterrupt+0x86

fffff880`0c4a5790 fffff802`14b740ba : fffffa80`437f70b8 00000000`00010008 00000000`0000e39d fffff802`14b96e80 : nt!KiInterruptDispatchLBControl+0x1ce

fffff880`0c4a5920 fffff880`00d79c88 : 00000000`00000001 00000000`00000001 fffff802`14b96e80 00000000`00000001 : hal!HalpTimerStallExecutionProcessor+0x10b

fffff880`0c4a59b0 fffff880`00d787f8 : 00000000`00000001 fffff802`14b96e80 00000000`00000700 fffff802`1456a72d : PSHED!PshedpWaitForOperationToComplete+0x1c

fffff880`0c4a59e0 fffff880`00d77539 : fffffa80`00000609 fffff802`14b96e80 fffffa80`321fb950 fffffa80`437f7010 : PSHED!PshedpWriteErrorRecordERST+0x89

fffff880`0c4a5a10 fffff802`1456ac60 : 00000000`00000001 00000000`00000000 00000000`00000000 fffffa80`437f7038 : PSHED!PshedWriteErrorRecord+0x71

fffff880`0c4a5a40 fffff802`14b83703 : fffff880`00000728 00000000`00000000 fffff880`0c4a5ba0 fffff802`14b96e80 : nt!WheaReportHwError+0x200

fffff880`0c4a5aa0 fffff802`14b831f3 : 00000000`00000001 00000000`00000000 fffff880`0c4a5c50 00000000`00000000 : hal!HalpMcaReportError+0x53

fffff880`0c4a5c00 fffff802`14bb0485 : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalpCmcPollProcessor+0x73

fffff880`0c4a5c50 fffff802`144a22b1 : fffff802`14690110 fffffa80`3316b700 fffff802`14bb03f0 fffff802`1446dc00 : hal!HalpCmcWorkerRoutine+0x95

fffff880`0c4a5cc0 fffff802`14437045 : fffff880`0c4a5ec0 00000000`00000080 fffff802`144a2170 fffffa80`3316b700 : nt!ExpWorkerThread+0x142

fffff880`0c4a5d50 fffff802`144eb766 : fffff880`02a47180 fffffa80`3316b700 fffff880`02a53d40 fffffa80`310ba980 : nt!PspSystemThreadStartup+0x59

fffff880`0c4a5da0 00000000`00000000 : fffff880`0c4a6000 fffff880`0c4a0000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

감사합니다.

이미 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

감사합니다.