산업용 카메라 제어 앱이 1개월 뒤에 갑자기 떨어질 때(후편) - Application Verifier란 무엇인가와 이상계 테스트 기반의 만드는 방법

Application Verifier는 Windows의 네이티브 코드나 Win32 경계에서 일어나는 이상을 앞당겨 표면화시키고 싶을 때 유력한 도구입니다. 특히 핸들 이상, 힙 파괴, 저리소스 시의 failure path를 테스트하고 싶은 장면에서는, 통상계의 시험만으로는 보이지 않는 문제를 꽤 일찍 표면에 낼 수 있습니다.

전편의 산업용 카메라 제어 앱이 1개월 뒤에 갑자기 떨어질 때(전편) - 핸들 누수의 발견 방법과 장기 가동용 로그 설계에서는, 장시간 운전 후에 떨어지는 제어 앱을 조사한 결과 원인이 핸들 누수였던 사례를 정리했습니다.
다만 로그를 강화한 것만으로는 아직 절반입니다. 정말로 필요한 것은 앞으로도 만약 상정 외의 프로그래밍 실수로 메모리 누수나 핸들 누수, 도중 실패, 해제 누락이 일어나도 「무엇이 일어났는지 알 수 있는」 상태로 되어 있는가를 미리 시험할 수 있는 것입니다.

그래서 쓴 것이 Application Verifier입니다.
Windows의 네이티브 코드나 Win32 경계에서 동작하는 처리에 대해 실행 시에 체크나 fault injection을 넣을 수 있는 도구입니다. 실무에서 특히 편리한 것은 정말로 머신의 메모리를 다 먹지 않아도 메모리 부족이나 자원 부족 같은 부서지는 방식을 앞당겨 일으킬 수 있는 점입니다.

후편에서는 Application Verifier란 무엇인가, 어떤 일을 할 수 있는가, 그것을 어떻게 이상계 테스트 기반에 넣을 것인가를 산업용 카메라 제어 앱의 문맥으로 정리합니다.

1. 먼저 결론(한마디로)

• Application Verifier는 Windows의 언매니지드 / 네이티브 경계에서 일어나는 오용을 실행 시에 찾기 쉽게 하는 도구입니다
• 편리한 것은 「버그를 찾는」 것뿐만 아니라 평소에는 나오기 어려운 이상계를 앞당겨 일으킬 수 있는 것입니다
• Handles에서는 invalid handle의 검출, Heaps에서는 힙 파괴의 현재화, Low Resource Simulation에서는 메모리 부족이나 자원 부족 같은 상황의 fault injection이 가능합니다
• 장시간 상주하는 EXE의 leak 조사를 Application Verifier에만 맡기는 것은 자가당착이며, Handle Count나 resource lifecycle의 자체 로그와 조합하는 것이 현실적입니다
• 이상계 테스트 기반에서는 통상계의 verifier run과 fault injection run을 나누어 돌리는 편이 읽기 쉽습니다
• DLL을 시험하고 싶은 경우에도 Application Verifier를 유효화하는 대상은 그 DLL을 실제로 동작시키는 테스트용 EXE입니다

요컨대 Application Verifier는 Windows의 native / Win32 주변에 있는 “짜증나는 버그”를 표면으로 끌어내는 도구입니다.
특히 장치 제어 앱처럼 native SDK, P/Invoke, Win32 API가 평범하게 섞이는 세계에서는 꽤 상성이 좋습니다.

2. Application Verifier란 무엇인가

2.1. 한마디로 말하면 무엇인가

Application Verifier는 Windows의 user-mode 앱에 대한 런타임 검증 도구입니다.
실행 중인 앱의 OS API 이용이나 자원의 취급 방식을 감시해 의심스러운 사용 방식을 검출하거나 의도적으로 실패를 주입하거나 할 수 있습니다.

「정적 해석」이나 「단체 테스트」와 달리 실제로 그 코드 패스를 지나갔을 때 어떻게 부서지는가를 보는 도구입니다.
그래서 평소의 기능 테스트에서는 보이지 않는 failure path를 끌어내는 데 맞습니다.

flowchart LR
    A[테스트 harness] --> B[제어 앱 / SDK 래퍼]
    B --> C[Application Verifier]
    C --> D[Win32 API / native DLL / OS 자원]
    C --> E[verifier stop]
    C --> F[debugger output]
    C --> G[AppVerifier logs]
    B --> H[자체 structured log]

2.2. 어떤 장면에서 효과가 있는가

특히 효과가 있기 쉬운 것은 다음 같은 장면입니다.

• native DLL이나 카메라 SDK를 호출하고 있다
• P/Invoke나 COM을 넘나들고 있다
• handle, heap, lock, virtual memory를 직접 또는 간접적으로 많이 쓴다
• 일반적인 정상계에서는 우선 떨어지지 않지만, 이상계에서만 수명 관리가 무너질 것 같다
• 「떨어진다」보다 「가끔 이상한 실패를 돌려준다」가 먼저 나온다

반대로 순 managed 세계만의 object graph를 쫓기 위한 도구는 아닙니다.
그래서 C# 앱이어도 native SDK나 Win32 경계가 두껍다면 꽤 효과가 있지만, 순 managed heap leak을 이것 하나로 전부 본다는 이야기는 아닙니다.

2.3. 무엇이 기쁜가

실무에서 기쁜 것은 대체로 다음 3가지입니다.

1. 네이티브 경계의 오용을 빨리 멈출 수 있다
   • invalid handle
   • heap corruption
   • lock misuse
   • virtual memory API misuse 등
2. 저리소스 시에만 나오는 부서지는 방식을 앞당길 수 있다
   • malloc 상당이 가끔 실패한다
   • CreateEvent나 CreateFile이 가끔 실패한다
   • VirtualAlloc이 실패한다
3. debugger와 조합하면 쫓기 쉽다
   • !avrf
   • !htrace
   • !heap -p -a
   • verifier stop의 로그

장치 제어 앱에서 곤란한 것은 「이상계에서 무엇이 일어났는지 모르겠다」는 것입니다.
Application Verifier는 그 “모르겠음”을 줄이는 데 꽤 효과가 있습니다.

3. Application Verifier로 어떤 일을 할 수 있는가

3.1. Basics: Handles / Heaps / Locks / Memory / TLS 등

Application Verifier의 기본 세트는 Basics입니다.
여기에 실무에서 자주 쓰는 체크가 정리되어 있습니다.

포인트는 「떨어진 뒤에 읽으면 안다」가 아니라 「의심스러운 사용 방식을 그 자리에서 멈춘다」는 것입니다.
장시간 운전형의 불량에서는 이 앞당김이 꽤 효과가 있습니다.

3.2. Low Resource Simulation: 메모리 부족이나 자원 부족의 앞당김

실무에서 꽤 편리한 것이 여기입니다.
정말로 RAM을 다 먹지 않아도 메모리 부족이나 자원 부족에 가까운 현상을 일으킬 수 있기 때문입니다.

사고방식으로는 단순합니다.

• 어떤 API 호출을
• 일정 확률로
• 일부러 실패시킨다

이것으로 평소에는 우선 지나지 않는 error path를 지나게 할 수 있습니다.

예를 들어 다음 같은 현상을 의도적으로 일으키기 쉬워집니다.

• HeapAlloc이나 VirtualAlloc이 실패한다
• CreateFile이 실패한다
• CreateEvent가 실패한다
• MapViewOfFile이 실패한다
• SysAllocString 같은 OLE/COM 계 할당이 실패한다

정말로 메모리 부족으로 하려고 머신 전체를 괴롭히기보다 이쪽이 훨씬 다루기 쉽습니다.
또한 특정 DLL만을 노려 fault injection을 넣는 것도 가능합니다. 장치 제어 앱처럼 자체 래퍼와 vendor SDK가 섞인 구성에서는 꽤 실무적입니다.

3.3. Page Heap과 debugger

힙 파괴를 본다면 Heaps와 page heap의 조합이 강합니다.
특히 full page heap은 guard page를 써서 부서진 순간에 멈추기 쉬운 것이 이점입니다.

다만 이것은 꽤 무겁습니다.
장시간의 총당이라기보다 재현이 가까운 시나리오로 좁혀 debugger 아래에서 돌리는 편이 쓰기 쉽습니다.

그래서 운용으로는 이런 구분이 현실적입니다.

• 우선 Basics로 넓게 적용
• 힙이 의심스러워지면 full page heap을 쓴다
• 너무 무거울 때는 light page heap으로 떨어뜨린다
• 운영 상당의 장시간 시험은 자체 로그 중심으로 본다

요컨대 AppVerifier는 만능 지팡이가 아니라 장면별로 날을 바꾸는 도구입니다.

3.4. !avrf / !htrace / 로그

Application Verifier는 stop을 내고 끝이 아닙니다.
debugger 확장이나 로그가 있으므로 무엇이 일어났는지를 쫓기 쉬워집니다.

• !avrf
  • 현재의 verifier 설정이나 지금 일어나고 있는 stop을 본다
• !htrace
  • handle의 open / close / invalid reference의 스택을 본다
• !heap -p -a
  • page heap과 조합해 부서진 힙 블록을 따라간다
• AppVerifier의 로그
  • stop이 일어났을 때의 로그를 남길 수 있다

특히 Handles를 유효화하고 있으면 handle tracing이 자동으로 유효화되는 것이 고맙습니다.
이것으로 「이 handle을 어디서 열고 어디서 닫았는가」를 나중에 쫓기 쉬워집니다.

4. 이번에 왜 도입했는가

4.1. 목적은 「버그를 찾는」 것뿐만이 아니다

이번 목적은 단순히 「AppVerifier로 버그를 1개 찾는」 것은 아니었습니다.
더 실무적으로 말하면 다음을 확인하고 싶었습니다.

• 장래 또 다른 failure path에서 자원 누설이 일어났을 때
• 제대로 로그에 문맥이 남는가
• debugger 정보와 함께 다 쫓을 수 있는가
• 「무엇이 일어났는지 불명」이라는 상태가 되지 않는가

즉 검출기로서뿐만 아니라 관측 기반의 테스트로서 썼습니다.

4.2. 메모리 부족 같은 현상을 일으킨다

평소의 개발기에서 정말로 메모리 부족을 일으키는 것은 꽤 번거롭습니다.
게다가 머신 전체가 불안정해지면 이번에는 테스트 자체가 잡음투성이가 됩니다.

그래서 Low Resource Simulation을 써서 메모리 부족이나 자원 부족에서 일어날 것 같은 failure path를 노려 밟게 하는 방향으로 했습니다.

예를 들어 다음 같은 질문에 답하기 쉬워집니다.

• CreateEvent가 실패하면 로그에 cameraId와 phase는 남는가
• 중도 반의 초기화 뒤에 clean up은 제대로 도는가
• VirtualAlloc이 실패하면 리트라이로 부서지지 않는가
• save path의 CreateFile 실패 시에 핸들이 돌아오는가

여기가 꽤 중요해서 이상을 일으키는 것 자체가 목적이 아니라 이상 시에 부서지는 방식이 읽힐 수 있는 것이 목적입니다.

4.3. 핸들 이상이 일어났을 때 쫓을 수 있는지 확인

전편에서 나온 핸들 누수도 그렇지만, 핸들 주변은 마지막에 떨어진 장소와 정말의 원인이 어긋나기 쉽습니다.

그래서 확인하고 싶었던 것은 다음입니다.

• invalid handle stop이 나왔을 때 !htrace로 open / close를 쫓을 수 있는가
• 자체 로그의 resourceId / sessionId / phase와 연결되는가
• 실패 후에 handle count가 돌아오는가
• harness를 단명 프로세스로 했을 때 누수의 차분이 보이기 쉬운가

여기까지 보이면 단순한 「버그가 나왔습니다」에서 「어느 책임으로 수명 관리가 무너졌는가」까지 갈 수 있게 됩니다.

5. 메모리 부족이나 자원 부족 같은 현상을 어떻게 일으킬까

5.1. Low Resource Simulation의 사고방식

Low Resource Simulation은 이른바 fault injection입니다.
저리소스 환경을 본물처럼 재현한다기보다 저리소스 시에 일어나는 대표적인 API 실패를 인공적으로 섞는 이미지입니다.

그래서 쓰는 곳은 꽤 분명합니다.

• failure path의 뒷정리 확인
• retry / reconnect의 견고함 확인
• 도중 성공·도중 실패가 섞이는 초기화 확인
• 「평소는 일어나지 않는 실패」여도 로그가 남는지 확인

여기서의 요령은 처음부터 뭐든지 실패시키지 않는 것입니다.
갑자기 전부 담으면 로그가 폭발해 「무엇을 보고 있는지」를 알 수 없게 됩니다.

5.2. 무엇을 실패시킬 수 있는가

Low Resource Simulation에서는 대표적으로 다음 종류의 API를 확률적으로 실패시킬 수 있습니다.

실무에서는 전부를 동시에 여는 것보다
이번에 보고 싶은 failure path에 가까운 것부터 좁혀 여는 것이 꽤 중요합니다.

5.3. 실무에서의 적용 방식

커맨드 라인의 이미지로는 예를 들어 다음과 같이 됩니다.

appverif /verify CameraHarness.exe
appverif /verify CameraHarness.exe /faults
appverif -enable lowres -for CameraHarness.exe -with heap_alloc=20000 virtual_alloc=20000 file=20000 event=20000
appverif -query lowres -for CameraHarness.exe

사고방식으로는 이런 느낌입니다.

1. 우선 Basics만으로 통상계를 돌린다
2. 다음으로 Low Resource Simulation을 더해 fault injection 있음으로 돌린다
3. 필요하다면 file이나 event 등 보고 싶은 실패만 확률을 가지게 한다
4. 특정 DLL만 노리고 싶다면 그 DLL에 좁혀 넣는다

/faults의 단축키는 편리하지만 이것만이면 OLE_ALLOC과 HEAP_ALLOC 중심입니다.
CreateFile이나 CreateEvent의 failure path를 보고 싶다면 -enable lowres -with file=... event=...까지 쓰는 편이 꽤 이해하기 쉽습니다.

장치 제어 앱에서는 앱 전체에 fault를 흩뿌리기보다 camera wrapper나 save path의 DLL에 좁히는 편이 읽기 쉬운 경우가 많습니다.

예를 들어 이런 시나리오를 만들 수 있습니다.

• reconnect 개시 직후의 CreateEvent 실패
• 저장 개시 시의 CreateFile 실패
• 일시 버퍼 확보 실패
• COM 변환의 SysAllocString 실패
• 대기 API의 실패 경로 확인

이쪽은 평소의 정상계 테스트만으로는 우선 밟을 수 없습니다.
그래서야말로 의도적으로 밟게 할 가치가 있습니다.

6. 핸들 이상을 어떻게 볼까

6.1. Handles 체크

핸들 주변에서는 우선 Handles를 씁니다.
이것으로 invalid handle의 사용을 검출하기 쉬워집니다.

전형적으로는 다음 같은 사고에 효과가 있습니다.

• close 완료 handle을 다시 쓴다
• 부서진 handle 값을 건넨다
• 도중 실패로 초기화되지 않은 handle을 쓴다
• lifetime이 무너져 다른 스레드에서 건드린다

장시간 운전에서 보면 「가끔 이상한 에러가 나온다」만으로도 verifier 아래에서는 그 자리에서 멈춰 줄 때가 있습니다.
이 앞당김은 꽤 도움이 됩니다.

6.2. !htrace로 open / close의 스택을 본다

Handles가 고마운 것은 handle tracing과 상성이 좋은 것입니다.

windbg -xd av -xd ch -xd sov CameraHarness.exe
!avrf
!htrace 0x00000ABC

!htrace로 보고 싶은 것은 대체로 다음입니다.

• 그 handle이 어디서 open됐는가
• 어디서 close됐는가
• invalid handle로서 참조됐는가
• 상정보다 많이 open이 쌓이지 않았는가

핸들 누수나 handle misuse가 까다로운 것은 마지막에 걸린 API가 정말의 원인이 아닌 것입니다.
!htrace가 있으면 그 handle의 이력을 꽤 구체적으로 쫓을 수 있습니다.

6.3. 자체 로그와 어떻게 조합할까

그렇다고는 해도 Application Verifier만으로는 부족합니다.
특히 장시간 상주하는 EXE의 leak 조사를 이것만으로 하는 것은 꽤 괴롭습니다.

그래서 실무에서는 다음을 함께 합니다.

• 정기 Handle Count
• sessionId
• resourceId
• phase
• create/open과 close/dispose의 lifecycle log
• verifier stop 시의 dump와 debugger 출력

이것으로 예를 들어 다음처럼 쫓을 수 있습니다.

1. heartbeat으로 Handle Count의 기울기가 의심스러운 것을 안다
2. lifecycle log로 Create는 있는데 Close가 없는 resource를 좁힌다
3. verifier run으로 invalid handle이나 misuse를 앞당겨 낸다
4. !htrace로 open / close stack을 본다

이 합기로 꽤 쫓기 쉬워집니다.

7. 이상계 테스트 기반의 만드는 방법

7.1. 실행 단위를 harness로 치우친다

Application Verifier는 동작하고 있는 도중의 프로세스에 나중에 유효화할 수 없습니다.
설정하고 나서 기동, 입니다.

또한 설정은 명시적으로 지울 때까지 남습니다.
그래서 실무에서는 본 앱 본체보다 테스트용 harness EXE에 치우치는 편이 다루기 쉽습니다.

예를 들어 이런 구성입니다.

flowchart LR
    A[Scenario Runner] --> B[CameraHarness.exe]
    B --> C[CameraSdkWrapper.dll]
    C --> D[Vendor SDK]
    B --> E[Structured Log]
    B --> F[Dump / Debugger]

이것이라면,

• 1 시나리오 1 프로세스로 돌릴 수 있다
• leak 차분이 보기 쉽다
• AppVerifier 설정의 ON/OFF를 전환하기 쉽다
• DLL을 시험할 경우에도 EXE 측에서 다룰 수 있다

라는 이점이 있습니다.

커맨드의 이미지는 예를 들어 다음입니다.

appverif /verify CameraHarness.exe
appverif /n CameraHarness.exe

유효화는 기동 전, 해제는 명시적으로, 입니다.
이쯤을 harness 전제로 돌리면 설정의 사고도 줄이기 쉽습니다.

7.2. 테스트 메뉴를 나눈다

이상계 테스트 기반에서는 전부를 1회에 하지 않는 편이 좋습니다.
대체로 다음 3개로 나누면 읽기 쉽습니다.

1. 통상계 + Basics
   • 아무것도 실패를 주입하지 않는다
   • verifier stop이 나오지 않는 것을 확인한다
2. fault injection 계
   • Low Resource Simulation
   • event / file / heap_alloc / virtual_alloc 등을 노려 실패시킨다
3. heap 심굴계
   • Heaps
   • full page heap
   • debugger 아래에서 국소적으로 재현한다

여기를 나누면
「평소의 사용 방식으로 부서져 있는가」와 「저리소스 시에만 부서지는가」가 뒤섞이기 어렵습니다.

특히 fault injection의 유무로는 지나는 code path가 꽤 바뀝니다.
그래서 fault 없이의 run과 fault 있음의 run은 양쪽 다 돌리는 편이 좋습니다.

7.3. 수집하는 것

최소한 다음은 취하고 싶습니다.

필요하다면 AppVerifier 쪽의 로그도 XML로 해서 집계할 수 있습니다.
다만 거기만 봐서는 원인이 닫히지 않는 경우가 많으므로, 자체 로그와 나란히 읽는 전제인 쪽이 실무에 맞습니다.

로그가 많은 것 자체는 훌륭하지 않습니다.
나중에 인과가 이어지는 것이 중요합니다.

7.4. 합격 조건

합격 조건도 「떨어지지 않았다」만으로는 약합니다.
이번 문맥에서는 적어도 다음이 필요했습니다.

• 통상계 + Basics에서 verifier stop이 나오지 않는다
• fault injection 있음에서도 상정한 실패는 로그에 남는다
• 중도 반으로 초기화된 자원이 제대로 정리된다
• reconnect / retry 후에 Handle Count가 baseline 근처로 돌아온다
• verifier stop이 나왔을 때 sessionId / phase / stack으로 쫓을 수 있다
• 「무엇이 일어났는지 모르겠다」는 실패가 되지 않는다

여기서 중요한 것은
부서지지 않는 것과 부서졌을 때에 쫓을 수 있는 것을 나누어 평가하는 것입니다.

7.5. 주의점

Application Verifier는 꽤 편리하지만 마법은 아닙니다.

• 실제로 지나지 않은 코드 패스는 검증되지 않는다
• full page heap은 무겁다
• third-party SDK 쪽에서 stop이 나오는 경우도 있다
• fault injection 있음/없음으로 지나는 코드 패스는 꽤 다르다
• 순 managed heap leak의 조사를 이것 하나로 하는 도구가 아니다

그래서 입지로는 이렇습니다.

• 장시간의 기울기는 자체 로그와 counters
• native 경계의 오용은 Application Verifier
• 이상 시의 인과의 복원은 structured log + dump + debugger

이 분업이 가장 실무에 맞습니다.

8. 대략적인 구분 사용

• invalid handle이나 double close가 의심스럽다
  • Handles + !htrace
• heap corruption / use-after-free가 의심스럽다
  • Heaps + full page heap + !heap -p -a
• 메모리 부족이나 자원 부족 같은 현상을 일으키고 싶다
  • Low Resource Simulation
• 장시간 운전으로 서서히 부서진다
  • 우선 자체의 Handle Count / Private Bytes / lifecycle log
• DLL을 시험하고 싶다
  • 그 DLL을 호출하는 harness EXE에 대해 Application Verifier를 유효화한다

처음부터 전부 담으면 대체로 로그의 안개가 됩니다.
보고 싶은 failure path에 가까운 날부터 대는 편이 훨씬 이해하기 쉽습니다.

9. 정리

잡아 두고 싶은 점은 다음입니다.

Application Verifier의 입지:

• Windows의 native / Win32 경계의 runtime verifier
• Handles / Heaps / Locks / Memory / TLS / Low Resource Simulation 등을 쓸 수 있다
• 평소에는 나오기 어려운 failure path를 앞당겨 밟게 할 수 있다

이번 문맥에서 효과가 있었던 것:

• 핸들 이상이 일어났을 때 !htrace로 쫓기 쉽다
• 메모리 부족이나 자원 부족 같은 현상을 머신 전체를 부수지 않고 일으키기 쉽다
• 그때 자체 로그가 정말 도움이 되는지 확인할 수 있다

실무에서의 사용 방식:

• 통상계 + Basics와 fault injection 계를 나누어 돌린다
• harness EXE를 준비해 단명 프로세스로 시나리오를 돌린다
• 자체 로그, dump, debugger 정보와 조합한다
• 장시간 leak의 기울기 그 자체는 자체 counters로 본다

Application Verifier는,
「좀처럼 나오지 않는 이상」을 “우연히 기다리는” 것이 아니라 “이쪽에서 맞이하러 가는” 도구입니다.

장치 제어 앱에서는 부서지지 않는 것도 중요하지만,
부서졌을 때에 무엇이 일어났는지를 설명할 수 있는 것이 같은 정도로 중요합니다.
그런 의미에서 꽤 실무에 맞는 도구라고 생각합니다.

전편: 산업용 카메라 제어 앱이 1개월 뒤에 갑자기 떨어질 때(전편) - 핸들 누수의 발견 방법과 장기 가동용 로그 설계

10. 참고 자료

• 전편: 산업용 카메라 제어 앱이 1개월 뒤에 갑자기 떨어질 때(전편) - 핸들 누수의 발견 방법과 장기 가동용 로그 설계
• Application Verifier - Overview
• Application Verifier - Testing Applications
• Application Verifier - Tests within Application Verifier
• Application Verifier - Debugging Application Verifier Stops
• Application Verifier - Features
• !htrace (WinDbg)
• GetProcessHandleCount function (processthreadsapi.h)

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

관련 사례

실제 정리와 개선 진행 방식이 가까운 사례 페이지입니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.