Superstar's New World

플랫폼 빌더 내의 PUBLIC나 PLATFORM쪽의 소스들을 보게 되면 'DEGUBMSG()'라는 녀석을 자주 볼 수 있다. 이녀석은 디버깅 모드로 빌딩을 했을 때 디버깅 메시지를 볼 수 있도록 해주는 녀석이다. 하지만.. 디버깅 모드로 빌드를 하게되면.. 용량도 엄청(?)커지게 되고.. 느리지고.. 뭐 그래서 잘 하지 않을 것이다.

그렇다면.. 릴리즈 모드로 빌드를 해서 디버깅 메시지를 어떻게 확인을 할 수 있을까? -_-
그래서 'RETAILMSG()'라는 녀석이 존재한다.
'RETAILMSG()'라는 녀석은 릴리즈 모드로 빌드를 했을 때 디버깅 모드의 'DEBUGMSG()'와 마찬가지로 디버깅 메시지를 볼 수 있도록 해주는 녀석이다.

RETAILMSG()의 문법은 다음과 같다.

Expression는 0 혹은 0이 아닌 다른 것으로써, 0이 아니면 Message의 내용을 출력하게 된다..
Message는 일반적인 printf와 같은 포맷으로 동작을하고, Message의 내용이 디버깅 메시지로 출력이 된다.

주의할 사항은 RETAILMSG는 2개의 인자(Expression, Message)만을 받기 때문에 두번째 인자를 주의해서 사용해야 한다.
예를 들면 다음과 같다.

위의 예에서 보는 것처럼 Message에 들어갈 내용을 괄호로 묶어 하나의 인수처럼 사용을 해야한다. 괄호로 묶지 않고 일반 C에서 사용하는 printf처럼("xxx %d", value) 사용하면 에러가 발생한다. -_-

다음은 'zdnet'에 올라와 있는 라영호님의 글을 스크랩한 것이다.

라영호님은 Windows Embedded 분야 Microsoft MVP로 현제 인벤텍 상하이 연구소에서 Windows Embedded CE 기반의 단말기 및 스마트폰을 개발하고 있으며, Windows Embedded 운영체제에 대한 블로그를 운영하고 있다.


윈도우 임베디드 CE(Windows Embedded CE) 개발 과정을 크게 4가지로 구분해 본다면, 하드웨어에 관련된 부트 로더 개발 부분, 디바이스 드라이버 관련 개발 부분, OS를 포팅하고 최적화 하는 부분, 개발한 장비에서 동작할 애플리케이션을 개발하는 것으로 분류해 볼 수 있다. 각 개발 단계 중 본 칼럼에서는 윈도우 임베디드 CE 상의 애플리케이션 개발이라는 주제, 그 중에서도 애플리케이션 개발 과정 중의 디버깅 방법에 대한 내용에 대해 알아보고자 한다.

윈도우 임베디드 CE용 애플리케이션 개발은 <그림 1>과 같이 윈도우 임베디드 CE 운영체제의 포팅, SDK 생성과 같이 PC 애플리케이션에서는 고려하지 않았던 단계들이 추가되고 개발하는 하드웨어의 LCD나 장치를 고려하고 개발해야 한다는 제한 사항이 있다.

다른 어려움은 PC와 같이 어느 정도 안정화된 운영체제 환경에서 개발을 하는 것이 아니라, 개발 중인 운영체제에서 애플리케이션을 개발해야 한다는 것이다. 문제점이 애플리케이션에서 발생하는 것인지 포팅이 완전히 안 끝난 시스템의 문제인지 확인하기가 난해하다는 것이다.

일례로 필자가 이전 개발 프로젝트 개발 중에 생겼던 문제를 꼽을 수 있다. 필자는 LCD 디바이스 드라이버 개발을 담당하고 있었고, 카메라 프로그램을 위한 API를 제공하여 애플리케이션을 개발하도록 돕고 있었다. 카메라 애플리케이션에서 일정 작업을 하다 보면 Memory Leak가 생기는 경우가 있었다.

LCD 디바이스 드라이버나 카메라 드라이버 역시 충분히 테스트를 했기 때문에 그럴 일이 없다고 장담을 하고 있는 상황이었고, CETK나 테스트 절차를 통해 대부분의 테스트가 Pass를 했기 때문에 안정화가 되었다고 생각하고 애플리케이션만의 문제라고 손 놓고 있었다.

하지만 애플리케이션 개발자의 집요한 분석 리포트와 테스트 방법론을 보고 할 수 없이 드라이버를 디버깅해야 했다. 결국 필자의 잘못으로 결론이 나왔고 많은 사람들의 원망(?)속에서 수정을 해야 했다. 이렇듯 윈도우 임베디드 CE 상의 애플리케이션 개발은 단순히 애플리케이션 개발뿐 아니라 시스템의 문제까지도 고려해야 하는 어려운 개발 작업이다.

따라서 개발을 하다 보면 비주얼 스튜디오 2005의 막강한 디버깅 기능만 가지고 디버깅을 하여 문제점을 찾아내기 어려울 때가 있다. 이러한 문제를 디버깅하기 위해 마이크로소프트는 다양한 디버깅 툴을 제공하고, 필자는 이 툴을 사용하여 어떻게 디버깅을 해 나가야 하는지 알려드리고자 한다.

<그림 1 - AppDev.bmp>

윈도우 임베디드 CE용 애플리케이션 개발에 있어 버그가 없고 안정적인 프로그램을 만들기 위한 좋은 방법은 무엇일까? 이 질문에 대한 필자의 대답은 ‘개발 경험’+’좋은 설계’+’좋은 툴’+’테스트’+’@’ 이 5가지를 꼽을 수 있겠다. 개발 경험이야 개발하면서 얻어져야 하는 것이고, 좋은 설계 방법이나 방법론적인 방법은 S/W Engineering 책에 수없이 다루어졌기 때문에 본 칼럼에서 다루지는 않겠다.

플랫폼 빌더(Platform Builder), 비주얼 스튜디오라는 개발 환경은 사실상 널리 확인이 된 좋은 개발 환경이다. 여기에 반복적인 테스트를 통해 생겨날 수 있는 모든 문제점을 확인하는 것이야말로 윈도우 임베디드 CE용 애플리케이션 개발의 최적의 조건이라고 할 수 있겠다.

@는 어떤 요소일까? 윈도우 임베디드 CE용 애플리케이션은 임베디드 시스템이라는 것과 윈도우 임베디드 CE라는 운영체제라는 것을 염두에 두어야 한다는 것이다. 임베디드 시스템의 제한 사항을 머리에 항상 염두에 두고 적은 메모리를 차지하고 빠르게 동작할 수 있는 애플리케이션을 만들 수 있도록 노력을 해야 한다.

그러기 위해서는 윈도우 임베디드 CE라는 운영체제가 어떻게 동작하는지에 대한 지식을 가지고 있어야 한다. 6.0으로 오면서 메모리, 슬롯(Slot) 개념, 스레드(Thread)에 대한 제한이 많이 없어 졌지만 윈도우 CE 5.0 버전의 경우 이러한 시스템 제한 요소 때문에 애플리케이션 개발 시에도 문제가 되는 경우가 많았다.

슬롯의 한계 때문에 개별 프로그램으로써 개발 할 때는 잘 되다가도 정작 운영체제에 포함시키고 동작시킬 때는 갑자기 프로세스가 종료 되거나 시스템과 충돌하는 문제가 생기기도 했었다.

이러한 이유로 애플리케이션 개발을 할지라도 시스템에 대한 깊은 이해는 좋은 프로그램을 만들기 위한 밑받침이 되는 것이다. 따라서 윈도우 임베디드 CE에 대한 시스템적인 지식이 좋은 프로그램을 만들기 위한 @가 되는 것이다.

개발한 애플리케이션의 알고리즘적인 버그를 디버깅 하기 위해서는 구현한 세부 코드를 잘 살피고 변수의 변경을 추적하면서 어떠한 부분이 잘못되었는지 추적해 나가야 한다.

하지만 윈도우 임베디드 CE용 애플리케이션은 시스템과의 관계 및 구조를 잘 이해하면서 문제에 대해 집중하여 디버깅을 해야 한다. 이때 도움을 줄 수 있는 것들이 비주얼 스튜디오와 플랫폼 빌더, 그리고 각종 Remote Tool들이다.

이제부터 윈도우 임베디드 CE에서의 애플리케이션 디버깅에 관한 내용에 대해 살펴보도록 하겠다.

비주얼 스튜디오 2005 디버깅
일반적으로 윈도우 임베디드 CE 6.0용 애플리케이션의 개발과 디버깅은 비주얼 스튜디오 2005에서 이루어진다. 이전에 임베디드 비주얼 C++이 있어 플랫폼과 응용프로그램 개발도구 각각 존재하였지만 이제는 비주얼 스튜디오 2005라는 통합 환경으로 운영체제, 애플리케이션의 개발 및 디버깅을 같이 할 수 있게 되었다.

<그림 2>는 비주얼 스튜디오 2005에서 윈도우 임베디드 CE용 애플리케이션을 디버깅 하는 화면이다. 코드상의 문제점을 추적하기 위한 중단점(Breakpoint)의 설정을 통해 프로그램 진행을 잠시 중단하도록 한 후에 ‘한 단계씩 코드 실행’, ‘프로시저 단위 실행’ 명령을 통해 애플리케이션의 진행을 Step By Step 진행시키면서 디버깅 할 수 있다.

<그림 2-VS2005 Debug.BMP>

비주얼 스튜디오에서 애플리케이션 디버깅의 중요 요소들
이제 비주얼 스튜디오 환경은 윈도우 임베디드 CE 운영체제 개발 환경일 뿐 아니라 애플리케이션 개발 환경이다. 비주얼 스튜디오를 이용한 디버깅 방법은 이제 모두 다 아는 사실이다. 그래도 디버깅에 관련된 중요 키워드를 확인해 본다면 다음과 같다.

(1)중단점(BreakPoint) – 중단점은 윈도우 임베디드 CE용 애플리케이션 디버깅을 하기 위한 기본 요소이다. 프로그램 소스 내에 디버깅을 원하는 중요한 위치에 중단점을 설치하고 거기서부터 디버깅이 이루어진다.

(2)지역, 자동 – 지역 및 자동 창에는 현재 실행중인 코드 영역에 해당하는 지역 변수가 표시되고, 자동 창에는 현재 줄과 코드의 이전 줄에 사용된 변수가 나타나게 된다.

(3)호출 스택 – 애플리케이션 디버깅 시 눈 여겨 별 중요한 부분은 호출 스택 창이다. 호출 스택 창은 디버그 메뉴/창/호출 스택에서 확인할 수 있다. 실시간 디버깅작업에서는 호출된 순서를 보여주는 기능으로 사용할 수 있다. 즉, 현재 프로그램 라인까지 어떠한 함수가 호출되었는지 과정을 보여준다.

복잡한 애플리케이션의 디버깅 시 호출된 함수를 순서대로 역추적하면서 문제점을 확인할 수 있기 때문에 중요한 기능이라고 하겠다. <그림 3>은 비주얼 스튜디오 2005에 호출 스택 화면이다.

<그림 3 - CallStack.BMP>

(4)메모리, 레지스터 – 애플리케이션 동작 중 레지스터의 값 및 메모리의 내용을 확인하기 위해 사용한다. 레지스터나 실제 메모리를 직접 바꾸면서 디버깅 용도로도 사용할 수 있다. <그림 2> 화면 참조.

윈도우 임베디드 CE 애플리케이션 개발의 첫걸음, 디버그 메시지
DEBUGZONE, DEBUGMSG, RETAILMSG 등의 디버깅 메시지 출력 매크로는 윈도우 임베디드 CE 개발을 하게 되면서 알게 된 중요한 매크로들이다. 시리얼 포트를 통하여 하이퍼 터미널이나 플랫폼 빌더의 디버그메시지 창에 출력된 메시지 정보 디버깅을 위한 중요한 실마리다.

문제에 따라 디버그 존을 설정해 어떠한 메시지를 중점적으로 볼 것인가 선택을 하고 출력된 메시지를 추적해 나가면서 문제점을 추적하는 방법은 고전적이지만 매우 유용한 디버깅 방법이다. 비주얼 스튜디오에서의 디버깅 메시지 출력뿐 아니라 OS 이미지 내에 포함되어서도 유용한 디버깅 정보를 제공하기 때문에 DEBUGMSG의 사용은 디버깅을 위한 기본 준비라고 하겠다.

DEBUGMSG 등록 및 사용 아래와 같다. DEBUGZONE을 등록하고, 등록한 DEBUGZONE에 따라 디버그 메시지를 출력할 수 있도록 DEBUGMSG를 사용하는 예이다. DEBUGMSG의 DEBUGZONE 설정은 실시간 디버깅 환경에서 디버깅 메시지 출력을 선택적으로 조절하면서 좀 더 쉽게 디버깅하고자 하기 위해서 사용한다.


플랫폼 빌더에서 모듈에 대한 DEBUGZONE의 표시와 DEBUGZONE의 선택은 <그림 4>과 같다.

<그림 4 - DEBUGZONE.BMP>

Kernel Debugger를 이용한 애플리케이션 디버깅 방법
비주얼 스튜디오 2005를 이용한 임베디드 CE OS용 애플리케이션의 디버깅 방법은 PC용 애플리케이션을 디버깅하는 것과 별반 차이가 없다. 하지만 윈도우 임베디드 CE에서는 설치 가능한 독립적인 윈도우 임베디드 CE용 애플리케이션을 개발한다기 보다 NAND나 NOR같은 Flash 메모리상에 OS와 함께 탑재되어 동작되는 상황을 고려해야 한다.

UI(User Interface)와 프로그램의 기본 동작에 관련된 사항은 비주얼 스튜디오를 이용하여 디버깅을 마무리하고 OS에 탑재될 환경을 고려하여 OS이미지에 애플리케이션이 포함되어 빌드 되도록 하거나 플랫폼 빌더에서 애플리케이션을 실행시켜 OS 상에서의 애플리케이션의 동작 검증 및 디버깅을 할 수 있도록 한다.

<그림 5>는 윈도우 임베디드 CE 상에서 플랫폼 빌더를 이용해 OS 이미지에 포함된 “WavPlay.exe”라는 윈도우 임베디드 CE용 애플리케이션을 디버깅하는 그림이다. 비주얼 스튜디오에서 애플리케이션 디버깅 방법과 같이 소스 코드에 중단점을 설정한 후 디버깅을 진행하면 된다. 애플리케이션이 OS 이미지 내에 포함되어 있다는 것뿐 디버깅 방법은 차이가 없다.

<그림 5- PlatformDebug.BMP>

Remote Tools을 사용한 애플리케이션 디버깅
플랫폼 빌더에서 애플리케이션을 디버깅하는 것은 간단하게는 윈도우 임베디드 CE 운영체제가 동작하는 환경에서 애플리케이션이 제대로 동작하는지 검증하는 것도 있지만 운영체제 사이와의 동작 관계를 확인하는 목적도 있다.

이때 사용하는 것이 플랫폼 빌더의 Remote tool이다. 애플리케이션과 운영체제 간의 미묘한 동작 검증을 하기 위해 사용한다. CeLog는 <표 1>과 같이 윈도우 임베디드 CE 운영체제에 대한 Heap 생성, 인터럽트 처리등과 같은 시스템 이벤트가 발생할 때 관련 이벤트를 기록하여 분석할 수 있게 하는 기능이다.

<표 1 - CeLog Event 예>

플랫폼 빌더 Remote Tool 사용을 위한 준비
윈도우 임베디드 CE 운영체제에서의 애플리케이션 디버깅은 위와 같이 플랫폼 빌더 상에서 실행 이미지를 직접 로드하거나 OS 이미지 내에 포함시켜 디버깅을 하면 된다. 하지만 Remote Tool을 이용하면 운영체제와의 관계를 파악하거나 Profiler를 통해 좀더 OS와의 관계를 통한 내부적인 동작내용을 확인할 수 있다.

그러기 위해서는 몇 가지 운영체제의 옵션을 추가해야 한다.

<그림 6>와 같이 프로젝트/속성 명령에서 설정하거나 환경 변수에 다음과 같이 추가 하면 된다. 환경 변수를 설정한 후 OS를 다시 빌드해야 Remote Tool을 이용해 애플리케이션의 문제점을 분석할 수 있는 환경이 준비되는 것이다.

Profiler나 CeLog Enable의 경우 Ethernet이나 USB 통한 KITL뿐만 아니라 ActiveSync를 통해서도 이용할 수 있기 때문에 개발 시 Profiler, CeLog가 Enable된 이미지를 별도로 릴리스한 후 ActiveSync 연결만으로 Application 디버깅을 위한 OS 이미지로 사용할 수 있다.

set IMGCELOGENABLE=1
set IMGPROFILER=1
set IMGAUTOFLUSH=1

<그림 6-ProfilerSetting.bmp>

Kernel Tracker를 이용한 Memory Leak 디버깅
윈도우 임베디드 CE용 애플리케이션 개발 중 가장 많이 겪는 문제는 애플리케이션의 성능 문제, 잘못된 동작 혹은 시스템 호출을 통한 “Data Abort” 발생 후 시스템의 중단, Memory Leak 문제이다. Data Abort의 발생은 동작 중 잘못된 코드를 호출한 후 생기는 문제이기 때문에 Data Abort가 발생한 시점의 모듈과 관계를 추적하다 보면 쉽게 찾아낼 수 있다.

누적해서 발생하는 문제가 아니라면 Data Abort 발생 지점을 추적하여 Data Abort를 일으키는 모듈의 위치 및 코드까지 추적할 수 있다.(자세한 사항은 Sue Loh’s Blog, http://blogs.msdn.com/sloh/를 참조하기 바란다).

Memory Leak는 애플리케이션에서 메모리 할당과 해지를 제대로 안 할 경우에 발생한다. Memory Leak을 방지하기 위해서는 사용 메모리의 할당과 해지에 대해서 주의해서 프로그램을 해야 한다.

Memory Leak은 Kernel Tracker를 이용하여 보다 손쉽게 디버깅 할 수 있다. 메모리의 할당과 해지를 이벤트 형태로 실시간 볼 수 있기 때문에 어떠한 부분에서 메모리 해지가 일어나지 않아 문제가 생기는지 확인할 수 있는 것이다. Kernel Tracker를 이용한 Memory Leak을 디버깅하기 위한 방법은 다음과 같다.

● Kernel Tracker의 Edit 메뉴에서 Event Filter를 선택한다. Synchronization, Miscellaneous, User Defined, Extensions에 설정된 이벤트 명을 모두 클리어 시키고 Memory 탭 부분만 설정한 채로 남겨둔다. <그림 7> 참고.

<그림 7- MemoryLeak.bmp>

● Find Event를 선택하여 메모리 할당에 관련된 Allocate Heap 이벤트와 Free Heap 이벤트, Allocate Virtual Memory와 Free Virtual Memory 이벤트간의 관계 중에 빠진 것이 있는지 확인을 하면서 보다 자세하게 Memory Leak에 대해 디버깅 할 수 있는 것이다. <그림 7>은 Kernel Tracker를 이용한 Memory Leak 디버깅 화면이다. 그림과 같이 Allocate Virtual Memory에 해당하는 Free Virtual Memory가 없기 때문에 Memory Leak이 발생한다는 것을 손쉽게 디버깅할 수 있게 한다. <그림 8>은 Kernel Tracker를 이용해 Memory Leak을 찾아내는 화면이다.

<그림 8 - KernelTracker.bmp>

Call Profiler를 이용한 수행시간 최적화
Call Profiler는 프로그램내의 함수나 코드의 동작시간을 수치와 그래픽적으로 표시해주어 어떠한 루틴에서 지연 요소가 생겼는지 분석할 수 있게 해주는 Remote Tool이다.

윈도우 임베디드 애플리케이션 개발이 어느 정도 마무리가 되었다면 Call Profiler로 프로그램의 수행시간을 측정하여 동작 지연 요소가 생기는 부분을 찾아내어 개선하는 방법도 애플리케이션의 성능 개선을 위한 좋은 방법이라고 하겠다. <그림 9>은 Call Profiler를 이용하여 프로그램의 수행 시간을 분석하는 화면이다.

<그림 9 - CallProfiler.bmp>

ActiveSync 없이 Visual Studio 2005로 디버깅 하기
비주얼 스튜디오 2005로 윈도우 임베디드 CE용 애플리케이션을 개발하다 보면 귀찮은 부분 중의 하나가 ActiveSync를 통하여 단말기를 연결하고 디버깅을 해야 한다는 것이다.

만약 디버깅을 위한 Ethernet 포트가 있고, 프로세서가 ARMV4i나 X86계열이라면 "www.OpenNETCF.com"를 사용할 것을 추천한다. ActiveSync 없이 TCP/IP를 통해 Windows Embedded CE 장치와 연결하고 Application의 개발과 디버깅을 할 수 있게 하는 유틸리티이다.

테스트 자동화를 통한 Bug Free !
윈도우 임베디드CE 애플리케이션의 개발 방법론은 PC나 웹과 같은데 적용되는 개발 방법론과 결코 다르지 않다. 리펙토링(Refactoring), 페어 프로그래밍(Pair Programming)과 같이 현재 각광 받고 있는 프로그래밍 기법들 역시 윈도우 임베디드 CE 애플리케이션에서도 적용이 가능하다.

하지만 잊지 말아야 할 중요한 차이점은 애플리케이션에서 하드웨어에 대해 좀더 관여를 하고 있다는 점이다. 한 비트 잘못 설정한 프로세서의 레지스터 값이 나비 효과처럼 작용하여 전체 시스템을 불안하게 만드는 원인으로 작용할 수 있다는 것이다. 따라서 작은 문제점도 찾아낼 수 있는 테스트 방법과 기준이 필요한 것이다.

하지만 이러한 문제는 쉽게 발견되는 것이 아니기 때문에 테스트 방법에 대한 기준을 정하고 자동화할 수 있는 방법을 모색하라는 것이다. 말은 쉽지만 많은 시행착오가 있어야 좋은 방법을 찾을 수 있다.

개발 시작 초기에 어떤 테스트를 하고 어떤 테스트 결과를 기대할 것인가에 대한 기준을 정하는 것이 좋다. 완벽한 기준이 있다면 다행이지만 없다면 간단하게라도 만들라는 것이다. 제일 좋은 것은 실제 기기를 사용하는 것과 같은 기준으로 기준을 만들고 테스트 하는 것이다. 즉, "최소한 사용자가 어떻게 사용한다는 가정 하에 기준을 만들고 사용자가 사용하는 것처럼 테스트 하라" 라는 것이다.

예를 들어 내비게이션 시스템을 개발하고 있다고 가정하여 하루에 사용자가 키를 몇 번 누르는지 예측을 하여 제품의 수명만큼 계속 누르는 반복 테스트를 하라는 것이다.

실제로 핸드폰 품질을 책임지고 있는 품질 기술 연구소에서는 자동화된 기계나 로봇을 이용하여 사용자가 핸드폰을 사용하는 형태를 짧은 시간에 집중 테스트 하여 소프트웨어, 하드웨어서 생길 수 있는 문제를 검증하고 있다.

테스트를 하다 보면 개발 중에 예측하지 못하는 다양한 문제점을 이러한 테스트를 통하여 발견 할 수 있다. 실생활에서 특정 키를 연속으로 1만번 누르거나 전원 켜고 끄는 것을 1,000번 이상을 하지는 않는다. 하지만 이러한 반복적인 테스트에서 소프트웨어에서 있을지 모르는 버그를 발견할 수 있는 것이다.

일례로, 필자는 100ms 단위로 키를 반복적으로 1만번 누르는 테스트를 한 적이 있었다. 윈도우 CE의 포팅이나 응용프로그램이 어느 정도 안정화 됐다고 생각을 하고 있었다. 실제로 직접 이것저것 동작 시켜보면 제대로 동작하였다. 하지만 테스트 시작 후 3일 정도가 지난 후 모든 장치가 멈춰있는 것을 보게 되었다. 한마디로 시스템이 다운된 것이다.

나중에 알아낸 사실이지만 드라이버에서 수십 바이트의 메모리 누수가 발생하였고 이게 누적되어 3일 후에는 시스템을 다운 시키는 요소로 작용하였던 것이다. 평상시 간단히 테스트 할 때는 이러한 문제점을 찾을 수 없었다. 이러한 테스트를 하기 위해서 테스트 장치를 모든 회사에서 구비할 필요는 없다.

좀 고민을 하다 보면 몇 줄 안 되는 C 코드로 구현해서 테스트 해볼 수 있기 때문이다. 필자도 테스트 하는 장소가 필자의 회사에서 좀 멀리 떨어진 곳에 있어서 테스트 하러 가기 귀찮아서 고안해낸 방법이다.

다음 코드는 키 입력을 에뮬레이션 하는 간단한 코드이다. 필자는 이 코드를 별도 애플리케이션에서 구현하여 테스트 하는 방법을 사용하고 있다.

Sleep(KEY_PRESS_DURATION);
keybd_event((BYTE) VK_TUP, 0x0, 0, 0);
Sleep(KEY_PRESS_DURATION);
keybd_event((BYTE) VK_TUP, 0x0, KEYEVENTF_KEYUP, 0);

이 방법은 별도의 장치 없이 테스트 하는 방법이며 운영체제의 안정성뿐만 아니라 응용프로그램의 신뢰성 테스트에도 필자는 이용하고 있다. 이런 식의 간단한 루틴으로 간단하게는 키 테스트부터 Application의 반복 동작 시 문제점을 검증할 수 있는 것이다.

조금만 고민 한다면 자동으로 모든 테스트를 할 수 있고, 이러한 자동화된 테스트 방법이 여러분 시스템 및 안정성을 더욱 높여줄 것이다.

끝으로
윈도우 임베디드 CE 상의 애플리케이션 디버깅 방법을 위한 비주얼 스튜디오 2005의 디버깅 방법, 디버그 메시지 등록방법, 디버깅 테크닉 등에 대해 간략히 살펴봤다.

실제 디버깅에 사용되는 방법들은 단순한 한 가지 방법으로는 문제가 해결되지 않을 것이다. 하지만 문제에 대한 실마리는 언제나 비주얼 스튜디오의 디버깅 창에 나온 작은 단서로부터 찾아낼 수 있다.

실제 제품이 기획에서 생산이 되고 출시가 되기까지에는 무수히 반복된 테스트와 디버깅을 통해 안정성을 확보해야 한다. 그래야 비로소 상품으로써의 그 가치를 인정 받을 수 있을 것이다.

디버깅을 하기 위해 밤새 반복된 테스트와 원인 분석을 하고 마침내 그 문제가 해결 됐을 때의 기쁨은 엔지니어가 아니면 누리기 힘든 기쁨일 것이다. 비주얼 스튜디오와 플랫폼 빌더의 막강한 디버깅기능을 이용해 “Bug Free!” Application에 도전해 보기 바란다!