Post on 27-Feb-2020
i
Windows Embedded CE 6.0
CTSMExam 70-571
전매 금지.
인증 시험 준비준비 키트(Preparation Kit)
R2 콘텐츠로
업데이트
됨
ii
발행인
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
이 문서는 정보용입니다 . MICROSOFT 는 이 문서에 포함된 정보에 대해 ( 직접 , 간접 , 특별한 )그 어떤 보증도 하지 않습니다 . 이 문서에 포함된 정보는 발행일을 기준으로 토론된 문제점에 대한 Microsoft Corporation 의 현재 관점을 대표합니다 . Microsoft 는 변하는 시세에 대처해야 하기 때문에 정보에 대한 책임을 질 수 없으며 발행일 이후에 제공되는 정보의 정확성을 보장할 수 없습니다 . URL 과 기타 인터넷 웹사이트 참고 자료를 포함하여 이 문서에 있는 정보는 통보없이 변경될 수 있습니다 .
모든 적용되는 저작권 법을 준수하는 것은 사용자의 책임입니다 . 저작권 하에 권리 제한이 허용되지 않는 한 , Microsoft Corporation 의 명시적 서면 허가없이 이 문서의 그 어느 일부도 그 어떤목적으로든 무단으로 복제 , 검색 시스템으로 저장 또는 입력 , 또는 그 어떤 형태나 방식으로 전송( 전자 , 기계 , 복사 , 기록 , 또는 기타 ) 될 수 없습니다 . Microsoft 는 이 문서상에 언급된 주제에관련된 특허 , 특허 응용 프로그램 , 등록 상표 , 저작권 또는 기타 지적 재산권을 소유할 수 있습니다 . Microsoft 와의 서면 사용권 계약에 명시적으로 나타나 있지 않은 이상 , 이 문서의 제공으로인해 이러한 특허 , 등록 상표 , 저작권 및 기타 지적 재산권에 대한 그 어떤 사용권도 부여되지 않습니다 .
저작권 © 2008 Microsoft Corporation. 모든 권리 소유 .
Microsoft, ActiveSync, IntelliSense, Internet Explorer, MSDN, Visual Studio, Win32,Windows 및 Windows Mobile 은 Microsoft 회사 그룹의 등록 상표입니다 . 이 문서에 언급된 회사와 제품의 실제 이름은 해당 소유자의 상표일 수 있습니다 .
용례에 사용된 회사 , 기관 , 제품 , 도메인 이름 , 전자 메일 주소 , 로고 , 사람 , 장소 및 이벤트는 다른 설명이 없는 한 실제 데이터가 아닙니다 . 어떠한 실제 회사 , 기관 , 제품 , 도메인 이름 , 전자 메일 주소 , 로고 , 사람 , 장소 또는 이벤트와도 연관시킬 의도가 없으며 그렇게 유추해서도 안 됩니다 .
인수 편집인 : 산드라 웨버 (Sondra Webber), Microsoft Corporation
저자 : 니콜라스 베슨 (Nicolas Besson), Adeneo Corporation레이 마르실라 (Ray Marcilla), Adeneo Corporation라제쉬 캐이드 (Rajesh Kakde), Adeneo Corporation
집필 감독 : 워런 루보 (Warren Lubow), Adeneo Corporation
기술 검수인 : 브리지트 후왕 (Brigette Huang), Microsoft Corporation
편집 제작 : Biblioso Corporation
본문 번호 X00-00000
iii
간단한 내용
서문 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
1 운영체제 디자인 설계 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 런타임 이미지 빌드와 배포 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 시스템 프로그래밍 실행 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4 디버깅 및 시스템 테스트 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5 보드 지윈 패키지의 사용자 지정 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6 장치 드라이버 개발 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
용어 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
색인 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
저자에 대하여 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
145
제 4 장
디버깅 및 시스템 테스트
디버깅과 시스템 테스트는 시스템 개발 주기에 있어서 중요한 작업이다 . 소프트
웨어와 하드웨어적인 결함을 찾아내고 해결하는 것을 궁극적인 목표로 한다 . 디
버깅의 의미는 코드를 단계적으로 실행시키거나 출력된 디버깅 메시지를 분석하
여 오류의 윈인을 분석하는 과정을 의미한다 . 시스템 구성요소에 대한 구현과 일
반적인 어플리케이션에 대해서 공부하는 것은 디버깅과 테스트를 위한 좋은 방
법 중 하나이다 . 또 한 편으로는 , 시스템 테스트는 일반적인 사용 시나리오 , 성
능 , 안전성 , 보안 , 그리고 기타 관련성이 있는 측면에서 그것의 최종 구성으로
시스템의 유효성을 검증하는 품질 - 보증 활동이다 . 시스템 테스트의 전체 목적
은 , 메모리 누수 , 교착 상태 , 또는 하드웨어 충돌 같은 제품 결함과 오류를 발견
하는 것이다 . 반면에 디버깅은 이러한 문제의 윈인을 규명하고 그들을 제거하는
것이다 . 소형 임베디드 시스템의 시스템 결함을 확인하고 제거하는 일은 대부분
의 개발자들에게도 어려운 부분중의 하나이다 . 이 장에서는 윈도우 임베디드 CE
6.0 R2 를 위한 개발 환경인 플랫폼 빌더 ( 마이크로소프트 비주얼 스튜디오®
2005 설치되어 있는 ) 에 있는 툴을 이용하여 디버깅과 테스트 하는 방법에 대해
다룬다 . 이 툴들은 디버깅 및 테스트 과정을 자동화 하고 보다 빠르게 하여 개발
하는 시스템을 보다 버그가 없는 시스템을 릴리스 할수 있도록 도와준다 . 또한
윈도우 임베디드 CE 테스트 키트 (CETK) 를 사용하여 테스트 자동화 방법에 대
해 설명한다 . 이러한 툴들에 대해 좀더 마스터할수록 코드를 수정하는 대신 코드
를 작성하는데 좀더 시간을 활용할 수 있다 .
이 장에서의 학습 목표 :
■ 런타임 이미지 디버깅을 위한 요구 사항을 식별
■ 코드 실행 분석을 위한 디버거 기능의 사용
■ 디버그 메시지의 출력을 관리하는 Debug Zone 에 대한 이해
■ CETK 툴을 이용하여 기본 테스트 및 사용자 정의 테스트 하기
■ 부트 로더와 운영 체제 (OS) 의 디버깅
146 제 4장 디버깅 및 시스템 테스트
시작하기 전에이 장의 학습을 완벽하게 이해하려면 , 사용자는 반드시 다음 과정을 하여야 한다 .
■ 윈도우 임베디드 CE 소프트웨어 개발 및 디버깅 개념에 관한 최소한의 기초
지식
■ 윈도우 임베디드 CE 지윈하는 드라이버 아키텍처의 기본적 이해
■ OS 디자인 및 시스템 구성 개념에 관한 지식
■ 플랫폼 빌더가 통합된 윈도우 임베디드 CE 6.0 R2 와 마이크로소프트 비주
얼 스튜디오® 2005 서비스 팩 1 이 설치된 개발용 컴퓨터 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 147
제 1과 : 소프트웨어 관련 오류 찾아내기소프트웨어 관련 오류 범위는 단순 오타 , 초기화되지 않은 변수 및 무한 루프에
서부터 중요한 경합 조건 (Critical Race Condition) 과 다른 쓰레드 동기화 문제
같은 더욱 복잡하고 난해한 문제까지 이른다 . 다행히도 , 한번에 대부분의 오류
위치를 수정하는 것은 용이하다 . 이러한 오류를 발견하는 가장 효과적인 비용 절
감 방법은 코드 분석을 통해서 이루어진다 . 사용자는 운영체제 디버깅뿐만 아니
라 드라이버와 어플리케이션 디버깅에까지 윈도우 임베디드 CE 장치의 다양한
도구를 사용할 수 있다 . 이러한 디버깅 도구의 완벽한 이해는 사용자가 코드 분
석을 빨리 하는 것을 도와 소프트웨어의 오류를 가능한 효율적으로 수정할 수 있
도록 한다 .
이 과정을 마치면 , 사용자는 다음과 같은 일을 할 수 있다 .
■ 윈도우 임베디드 CE 를 위한 중요한 디버깅 도구 식별 .
■ 드라이버와 응용 프로그램을 디버그 영역을 통한 디버그 메시지를 제어 .
■ 메모리 문제를 확인하기 위한 Target Control 의 사용 .
예상 학습 시간 : 90 분 .
디버깅 및 타겟 장치 제어윈도우 임베디드 CE 타겟 장치를 디버그하고 제어하는 주요한 도구는 그림 4-1
과 같이 개발용 워크스테이션에서 실행하는 플랫폼 빌더 이다 . 플랫폼 빌더 통합
개발 환경 (IDE) 는 디버깅 중 중단점에 멈춘 후 코드를 단계적으로 실행시키게
하거나 메모리 , 변수 , 의 정보를 표시하게 할 수 있다 . CE 타겟 제어 쉘 (CESH),
그리고 디버그 메시지 (DbgMsg) 기능과 같은 다양한 도구를 포함한다 . 플랫폼
빌더 IDE 는 런타임 이미지에서 타겟 장치의 상태를 분석하는 Heap Walker,
Processor Viewer, 그리고 kernel Tracker 와 같은 윈격 도구의 컬렉션을 포함
한다 .
148 제 4장 디버깅 및 시스템 테스트
그림 4-1 CE 디버깅 및 Target Control 구조
타겟 장치와 통신하기 위해서 , 플랫폼 빌더는 타겟 장치의 이미지에 포함된 디버
깅 컴포넌트와 코어 연결 (CoreCon) 인프라스트럭처를 이용한다 . CoreCon 인
프라스트럭처는 OS 접근 (OsAxS), Target Control, DbgMsg 서비스를 플랫폼
빌더에게 그리고 타겟 장치에는 Kernel Independent Transport Layer(KITL)
과 Bootstrap 서비스 인터페이스를 제공한다타겟 장치 . 타겟 장치에서는 디버깅
과 타겟 제어를 위해서는 KITL 을 사용하고 통신을 위해서는 부트 로더를 이용
한다 . 커널 디버거 스텁 (KdStub), 하드웨어 디버거 스텁 (HdStub), 그리고
OsAxS 라이브러리 같은 디버깅 컴포넌트를 런타임 이미지가 포함한다면 , 사용
자는 커널 런타임 정보를 얻고 Just-In-Time(JIT) 디버깅을 수행하기 위해 플
랫폼 빌더를 사용할 수 있다 . 사용자가 커널을 로드 하기 전에 타겟 장치 루틴을
제 1 과 : 소프트웨어 관련 오류 찾아내기 149
디버그 할 수 있도록 , 플랫폼 빌더는 또한 확장 디버깅 인터페이스 (eXDI) 통한
하드웨어 지윈 (hardware-assisted) 디버깅을 지윈한다 .
커널 디버거 커널 디버거는 커널 구성요소와 CE 응용프로그램을 디버깅 할 수 있게 하는 CE
소프트웨어 - 디버깅 엔진이다 . 개발용 위크스테이션에서 설치된 플랫폼 빌더를
이용하여 어플리케이션을 실행시키거나 디버깅 하기 위해 소스 코드에 중단점을
삽입하거나 삭제하는 작업을 직접할 수 있을 작업을 한다 . 그러나 플랫폼 빌더가
디버깅 정보를 잡을 수 있고 타겟 장치를 관리할 수 있도록 사용자는 KITL 을 지
윈할 수 있도록 런타임 이미지에 디버깅 라이브러리 (KdStub 과 OsAxS) 을 포함
해야 한다 . 이 장의 뒤에 있는 “디버깅 활성화를 위한 런타임 이미지 구성” 에
서 커널 디버깅에 대한 시스템 구성의 상세한 정보를 제공한다 . 다음의 타겟 중
심의 구성요소는 커널 디버깅에 필수적이다 .
■ KdStub 예외와 중단점을 캡처, 커널 정보의 검색과 커널 작업을 수행한다.
■ OsAxS 메모리 할당에 관한 정보 , 활성 프로세스 및 쓰레드 , 프록시
(proxies), 그리고 로드 된 동적 - 링크 라이브러리 (DLLs) 같이 운영 체제
의 상태에 대한 정보를 검색한다 .
참고 윈도우 임베디드 CE 의 응용프로그램 디버깅
커널 디버거를 이용하여 사용자는 전체 런타임 이미지 뿐만 아니라 개개의 어플리케이션을 제어할 수있다 . 그러나 KDSTUB 는 제 3 장 “시스템 프로그래밍의 수행”에서 설명한 첫 FIRST-CHANCE 예외와SECOND-CHANCE 예외를 받는 커널 구성요소이다 . 만약 사용자가 타겟 - 사이트 KDSTUB 모듈을 먼저 멈추지 않고 커널 디버거를 멈춘 상태에서 예외가 발생한다면 , 런타임 이미지는 디버거를 다시 연결할때까지 응답을 하지 않을 것이다 . 그 이유는 커널 디버거가 제대로 예외를 처리해야 타겟 장치가 계속 실행 할 수 있기 때문이다 .
디버그 메시지 서비스플랫폼 빌더에서 , 사용자가 KITL 와 KdStub- 활성화된 타겟 장치에 연결할 때 ,
사용자는 마이크로소프트 비주얼 스튜디오 2005 의 출력 윈윈도우에서 나오는
디버그 정보를 확인할 수 있다 . 풀랫폼 빌더는 CoreCon 인프라스트럭처의
DbgMsg 서비스를 이용하여 타겟 장치로부터 얻어지는 정보이다타겟 장치 . 디
버그 메시지는 실행중인 프로세서 정보 , 잘못된 입력과 같은 잠재적으로 중요한
문제를 일으킬만한 정보 , 오류가 발생할 만한 코드 위치에 대한 힌트를 준다 . 이
후 이 정보를 이용하여 커널 디버거를 이용하여 중단점을 설정하고 디버깅을 통
해 코드의 문제점을 확인할 수 있다 . 커널 디버거 스텁 (Stub) 의 기능 중 하나는
디버그 메시지의 동적 관리 지윈이다 . 그래서 사용자는 소스 코드 변경 없이 디
버그 메시지의 출력을 다양하게 구성할 수 있다 . 다른 것들 중에서 , 사용자가 비
150 제 4장 디버깅 및 시스템 테스트
주얼 스튜디오 안에 타겟 메뉴의 디버그 메시지 옵션 선택을 통해 사용자는
Timestamps, Process ID, 또는 Thread ID 를 배제할 수 있다 . 사용자는 또한
별도의 도구를 가지고 분석을 위한 파일에 대해 디버그 출력을 보낼 수 있다 . 타
겟 장치에서 , 모든 디버그 메시지는 NKDbgPrintf 함수를 통해 출력 스트림 ( 화
면이나 파일 ) 에 직접 보내진다 .
참고 KITL 과 KITL 없는 디버그 메시지
커널 디버거와 KITL 모두가 활성화된 경우 , 디버그 메시지를 비주얼 스튜디오의 OUTPUT WINDOW 에 출력된다 . 만약 KITL 을 사용할 수 없는 경우 , 디버그 정보는 타겟 장치에서 개발용 컴퓨터로 OAL(OEMADAPTATION LAYER) 을 이용한 시리얼 포트를 통해 전달된다 .
디버그 메시지를 위한 매크로
디버그 정보를 생성시키기 위하여 , 윈도우 임베디드 CE 는 디버그 매크로와 리테
일 매크로 두 범주로 일반적으로 나누어 지며 , 여러가지 디버깅 매크로를 제공한
다 . 리테일 매크로 가 디버그와 리테일 빌드 구성 (WINCEDEBUG= 리테일 ) 양쪽
모두 정보를 생성시키는 반면에 사용자가 Ship 구성 (WINCESHIP=1) 으로 런타임
이미지를 구축하지 않으면 , 디버그 빌드 구성 ( 환경변수 WINCEDEBUG=debug)
에서 단지 디버그 매크로 출력 정보만 컴파일 된다 . Ship 구성 , 모든 디버깅 매크
로는 사용할 수 없다 .
표 4-1 은 사용자가 디버그 정보를 생성하기 위하여 사용자의 코드에 삽입할 수
있는 디버깅 매크로를 요약한 것이다 .
표 4-1 디버깅 메시지 출력을 위한 윈도우 임베디드 CE 매크로
매크로 설명
DEBUGMSG 런타임 이미지가 디버그 빌드 옵션으로 컴파일 되면 printf-style 디버그 메시지를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 .
리테일 MSG 런타임 이미지가 디버그 또는 릴리스 빌드 옵션으로 컴파일 되었고, 그러나 Ship 빌드 구성이 아닌 경우 printf-style 디버그 메시지를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 .
ERRORMSG 런타임 이미지가 디버그 또는 릴리스 빌드 옵션으로 컴파일 되었고 Ship 빌드 구성이 아닌 경우 부가적인 printf-style 디버그 정보를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 . 이 오류 정보는 소스 코드 파일명과 행 번호를 포함한다 . 에러 메시지를 출력한 소스와 코드의 위치를 빠르게 찾을 수 있도록 해준다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 151
디버그 영역디버그 메시지는 다중 - 쓰레드 프로세스를 분석하는데 특히 유용한 도구이다 .
특히 쓰레드 동기화 및 다른 다른 타이밍 관련 문제를 디버거로 코드를 순차적으
로 실행시키면서 문제를 찾아내는 것은 어렵다 . 그러나 , 사용자의 코드에 디버
깅 매크로를 많이 사용한다면 , 타겟 장치에 생성된 디버그 메시지의 수가 압도적
일 수 있다 . 생성된 정보의 양을 제어하기 위하여 , 디버깅 매크로는 사용자가 인
자의 표현을 지정할 수 있게 한다 .
예를 들어 , dwCurrentIteration 값이 가능한 최대값보다 더 크다면 다음의 코드
는 오류 메시지를 출력한다 .
ERRORMSG(dwCurrentIteration > dwMaxIteration,
(TEXT("Iteration error: the counter reached %u, when max allowed is %u\r\n"),
dwCurrentIteration, dwMaxIteration));
위의 보기에서처럼 , ERRORMSG 가 dwCurrentIteration 이 dwMaxIteration 보
다 더 클 때마다 디버깅 정보를 출력한다 , 그러나 사용자는 또한 조건문에서
Debug Zone 을 이용하여 디버깅 메시지를 제어할 수 있다 . 사용자가 매시간마
다 소스 코드를 변화시키거나 다시 컴파일 하지 않고 다양한 수준에서 모듈 ( 즉 ,
실행 파일 또는 DLL) 의 코드 실행을 검사하기 위해 DEBUGMSG 매크로를 사용
하기 윈한다면 , 이것은 특히 유용하다 . 첫째로 사용자는 실행 가능한 파일이나
DLL 에서 디버그 영역을 활성화해야 한다 . 그리고 어떤 영역을 활성화 시킬건지
ASSERTMSG 런타임 이미지가 디버그 빌드 구성으로 컴파일 되면 사실 , ASSERTMSG 는 DBGCHK 에 의해 DEBUGMSG 를 호출한다 . printf-style 디버그 메시지를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 . 그리고 디버깅 모드로 전환된다 .
DEBUGLED 런타임 이미지가 디버그 빌드 옵션에서 컴파일 되고 WriteDebugLED 함수에 WORD 값을 인자로 전달한다 . 이 매크로는 시스템 상태를 나타내기 위한 발광 다이오드 (LED) 를 장착하고 OAL 에 OEMWriteDebugLED 함수가 구현된 시스템에 유용하다 .
리테일 LED 런타임 이미지가 디버그 빌드 옵션으로 컴파일 되고 WriteDebugLED 함수에 WORD 값을 인자 전달한다 . 이 매크로는 시스템 상태를 나타내기 위해 LED 가 장착되어 있고 OAL 에 OEMWriteDebugLED 함수가 구현되어 있는 시스템에서만 사용가능하다 .
표 4-1 디버깅 메시지 출력을 위한 윈도우 임베디드 CE 매크로
매크로 설명
152 제 4장 디버깅 및 시스템 테스트
지정하기 위해 디버그 메시지서비스를 가지고 글로벌 DBGPARAM 변수를 등록
한다 . 개발용 워크스테이션이나 타겟 장치에 있는 레지스트리 설정을 통하여 , 또
는 사용자가 현재 기본값 영역을 프로그래밍 방식으로 지정할 수 있다 . 또한 대
상 메뉴 또는 Target Control 윈도우에 , CE 디버그 영역을 통한 플랫폼 빌더에
있는 모듈을 위하여 동적으로 디버그 영역을 제어하는 것이 가능하다 .
팁 디버그 영역을 우회
사용자가 런타임 이미지를 REBUILD 할 때 사용자가 TRUE 나 FALSE 로 설정할 수 있는 DEBUGMSG 와 리테일 MSG 매크로에게 BOOLEAN 변수를 전달한다면 , 드라이버와 응용프로그램에 있는 디버그 영역을 우회할 수 있다 .
영역 등록
디버그 영역을 이용하기 위해 , 사용자는 표 4-2 에 요약된 모듈 이름 , 사용자가
등록하는 것을 윈하는 디버그 영역의 이름 , 그리고 현재의 영역 마스크를 위한
필드를 지정하는 하는 세가지 필드와 글로벌 DBGPARAM 변수를 정의해야 한다.
표 4-2 DBGPARAM 변수
필드 설명 보기
lpszName 모듈의 이름을 최대 길이 32 자까지정의한다 . TEXT("ModuleName")
rglpszZones 디버그 영역을 위해 16 가지 종류의 영역 이름의 배열을 정의한다 . 각각의 이름은 최대 32 자까지 사용할 수 있다 . 플랫폼 빌더는 모듈에서 활성 영역을 선택할 때 사용자에게 이 정보를 화면 표시한다 .
{
TEXT("Init"),
TEXT("Deinit"),
TEXT("On"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Undefined"),
TEXT("Failure"),
TEXT("Warning"),
TEXT("Error") }
ulZoneMask 현재의 선택한 영역을 확인하는 DEBUGZONE 매크로에서 현재 영역 마스크를 사용한다 .
MASK_INIT | MASK_ON |
MASK_ERROR
제 1 과 : 소프트웨어 관련 오류 찾아내기 153
참고 디버그 영역
윈도우 임베디드 CE 는 총 16 가지 이름의 디버그 영역을 지윈한다 . 그러나 모듈이 그들을 필요하지않는 다면 모두를 정의하지 않아도 된다 . 각 모듈은 구현된 DEBUG ZONE 목적에 명확하게 부합하도록영역별로 분리해서 사용하도록 한다 .
Dbgapi.h 헤더 파일은 DBGPARAM 구조체와 디버깅 매크로를 정의한다 . 이러
한 매크로가 dpCurSettings 로 이름 지어지고 , 미리 정의된 DBGPARAM 변수
를 사용하기 때문에 , 다음 코드 일부와 같이 , 사용자의 소스 코드에서 동일한 이
름으로 사용한다는 것은 중요하다 .
#include <DBGAPI.H>
// A macro to increase the readability of zone mask definitions #define DEBUGMASK(n) (0x00000001<<n)
// Definition of zone masks supported in this module#define MASK_INIT DEBUGMASK(0) #define MASK_DEINIT DEBUGMASK(1) #define MASK_ON DEBUGMASK(2) #define MASK_FAILURE DEBUGMASK(13) #define MASK_WARNING DEBUGMASK(14) #define MASK_ERROR DEBUGMASK(15)
// Definition dpCurSettings variable with the initial debug zone state // set to Failure, Warning, and Error.DBGPARAM dpCurSettings = { TEXT("ModuleName"), // Specify the actual module name for clarity! { TEXT("Init"), TEXT("Deinit"), TEXT("On"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Failure"), TEXT("Warning"), TEXT("Error") }, MASK_INIT | MASK_ON | MASK_ERROR};
// Main entry point into DLL BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ){ if(ul_reason_for_call == DLL_PROCESS_ATTACH) { // Register with the Debug Message service each time // the DLL is loaded into the address space of a process. DEBUGREGISTER((HMODULE)hModule); } return TRUE;}
154 제 4장 디버깅 및 시스템 테스트
Debug Zones 정의위에 있는 예제 코드는 모듈에 대한 6 가지 Debug Zone 의 등록과 디버깅 메크
로에 대한 조건문을 보여준다 . 다음 코드는 이와 같은 일을 하는 예를 보여준다 .
DEBUGMSG(dpCurSettings.ulZoneMask & (0x00000001<<(15)),
(TEXT("Error Information\r\n")));
만일 디버그 영역이 MASK_ERROR 로 현재 설정되어 있다면 , 조건식의 값이
TRUE 이기 때문에 디버그 출력 스트림에 출력하게 된다 . 그러나 코드의 가독성
을 높이기 위해 밑에 예시된 코드와 같이 Dbgapi.h 에 DEBUGZONE 매크로를
정의해서 사용해야 한다 . 무엇보다도 Debug Zone 을 논리적 연산자인 AND 나
OR 에 의한 간단히 정의 사용할 수 있게 한다 .
#include <DBGAPI.H>
// Definition of zone flags: TRUE or FALSE according to selected debug zone.
#define ZONE_INIT DEBUGZONE(0)
#define ZONE_DEINIT DEBUGZONE(1)
#define ZONE_ON DEBUGZONE(2)
#define ZONE_FAILURE DEBUGZONE(13)
#define ZONE_WARNING DEBUGZONE(14)
#define ZONE_ERROR DEBUGZONE(15)
DEBUGMSG(ZONE_FAILURE, (TEXT("Failure debug zone enabled.\r\n")));
DEBUGMSG(ZONE_FAILURE && ZONE_ WARNING,
(TEXT("Failure and Warning debug zones enabled.\r\n")));
DEBUGMSG(ZONE_FAILURE || ZONE_ ERROR,
(TEXT("Failure or Error debug zone enabled.\r\n")));
Debug Zone 활성화 및 비활성화DBGPARAM 필드의 ulZoneMask 는 모듈의 현재 Debug Zone 을 설정할수 있
게하는 중요한 요소다 . 사용자는 전역 변수인 dpCurSett ings 변수의
ulZoneMask 값을 직접 변경하는 방법을 통해 모듈의 Debug Zone 을 변경하면
서 사용할 수 있다 . 다른 방법은 디버거 안에서 설정한 중단점에 의해 프로그램
수행이 멈췄을 때 Watch 윈도우에서 ulZoneMask 의 값을 직접 변경하는 것이다 .
사용자는 또한 다른 어플리케이션의 Debug Zone 을 SetDbgZone 함수를 사용
하여 설정하거나 변경 할 수 있다 . 실행중에 사용가능한 다른 방법은 그림 4-2
와 같이 Debug Zone 대화 상자를 사용하는 방법이다 . Debug Zone 대화 상자
는 비주얼 스튜디오에 있는 플랫폼 빌더에서 Target 메뉴에 있는 CE Debug
Zones 메뉴를 사용하여 이용할 수 있다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 155
그림 4-2 플랫폼 빌더에서 디버그 영역 설정
Name 항목은 디버그 영역을 지윈하는 타겟 장치에서 실행하는 모듈을 보여준다 .
선택한 모듈이 디버그 메시지 서비스를 등록하였다면 16 가지의 Debug Zone 이
표시되는 것을 볼 수 있다 . 그 이름들은 선택된 모듈의 dpCurSettings 정의한 것
과 동일하다 . 사용자는 Debug Zone 이름을 선택하여 Debug Zone 을 활성화 시
키거나 비활성화 시킬 수 있다 . dpCurSetting 변수에 설정된 Debug Zone 은 기
본적으로 활성화 되고 체크 상태로 표시된다 . 디버그 메시지 서비스를 등록하지
않은 모듈은 Debug Zone 표시에서 비활성화 되고 Debug Zone 설정을 할 수 없
다 .
운영체제 시작시 Debug Zone 설정윈도우 임베디드 CE 는 응용 프로그램이 시작하거나 DLL 을 프로세스로 로드할
때 dpCurSettings 변수에 설정된 값으로 Debug Zone 을 설정하게 된다 . 이때는
사용자가 중단점에 의해 멈춰진 상태에서 Watch 윈도우에서 ulZoneMask 값을
바꾸지 않는한 Debug Zone 을 바꾸는 것은 불가능하다 . 하지만 CE 는 좀더 간
편하게 레지스터리 설정을 변경하는 방법으로 Debug Zone 을 변경하는 방법을
지윈한다 . 로드되는 드라이버에서 다른 Debug Zone 을 활성화 시키기 위해서는
REG_DWORD 형식의 레지스터리를 만들어서 Registry 이름에는 해당 모듈
(lpszName 에 지정된 이름 ) 의 이름을 지정하고 값에는 활성화 시키고자 하는
Debug Zone 의 값 (dpCurSettings 변수에 지정된 값 ) 을 지정하면 된다 . 이 레
지스트리 값은 개발용 워크스테이션이나 타겟 장치를 변경함으로써 이용할 수 있
다 . 개발용 워크스테이션에 있는 레지스트리를 변경하는 장점은 PC 의 레지스터
리 변경 후 타겟 장치를 재 시작하는 것으로 대상 모듈에 대한 Debug Zone 변경
156 제 4장 디버깅 및 시스템 테스트
을 할 수 있지만 타겟 장치에 있는 레지스트리를 변경하는 것은 런타임 이미지를
다시 빌드해야 하는 단점이 있다 . 표 4-3 은 ModuleName 로 불리는 샘플 모듈
로 구성하는 예를 설명한다 . 항목이름은 실행가능한 EXE 파일이나 DLL 의 실제
이름이어야 한다 .
자세한 정보 페가수스 레지스트리 키
페가수스 이름은 1996 년 마이크로소프트사가 핸드헬드 개인용 컴퓨터와 다른 소비자 전자제품을 위해 출시된 첫 번째 윈도우 CE 버전의 코드 이름으로 알려졌던 이름이다 .
최상의 방법디버그 메시지를 이용하여 개발 작업을 한다는 것중 명심해야 할 것은 디버그 메
시지를 많이 출력하게 하면 코드 실행 속도가 늦어진다는 것이다 . 더욱 중요한
문제는 시스템은 디버그 출력 작업을 직렬화 하게 되고 , 이것은 의도되지 않는
쓰레드의 동기화 문제를 초래한다는 것이다 . 예를 든다면 , 다중 쓰레드 환경에
서 비동기적으로 동작하던 시스템이 릴리스 빌드에서는 문제가 없다가 디버그 빌
드에서는 문제를 일으키는 경우가 있다 .
표 4-3 시작 레지스트리 매개변수 예제
위치 개발용 워크스테이션 타겟장치
레지스트리 키 HKEY_CURRENT_USER₩Pegasus₩Zones
HKEY_LOCAL_MACHINE₩DebugZones
항목 이름 ModuleName ModuleName
유형 REG_DWORD REG_DWORD
값 0x00000001 - 0x7FFFFFFF 0x00000001 - 0x7FFFFFFF
코멘트 개발용 워크스테이션에서 디버깅 하는 모듈에 대한 Debug Zone 레지스터리 정보를 얻을 수 없을때 ( 개발용 워크스테이션이 없거나 레지스트리가 설정되지 않았을 때 ) 는 타겟에 설정된 레지스터리 정보를 이용해 Debug Zone 을 설정하게 된다 .
참고 모든 디버그 영역의 활성화
윈도우 임베디드 CE 는 응용프로그램 디버깅 목적을 위하여 디버그 영역의이름을 정의하고 REG_DWORD 값의 하위 16 비트를 사용한다 . 커널에 의해예약된 최상위 비트만 제외하고 남아 있는 비트들은 지정되지 않은 DEBUGZONE 을 위해 사용할 수 있다 . 그러므로 , 사용자는 모듈의 디버그 영역 값을 0XFFFFFFFF 로 설정해서는 안 된다 . 최대 값은 0X7FFFFFFF 이다 . 이미지정되어 있거나 지정되지 않은 DEBUG ZONE 으로 사용할 수 있다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 157
디버그 메시지 및 Debug Zone 을 사용하여 작업할 때 다음과 같은 방법을 사용
할것을 제안한다 .
■ 조건문 Debug Zone 에 대한 조건문을 사용하는 디버그 매크로를 사용하
라 . DEBUGMSG(TRUE) 를 사용하지 않는다 . 또한 조건문 없는 리테일
MSG(TRUE)같은 리테일 매크로를 사용하는 것을 피한다. 비록 일부 model
device driver (MDD)/ platform dependent driver (PDD) 드라이버는 이
기술을 사용하고 있다 .
■ 릴리스 빌드로 부터 디버깅 코드 제한 사용자가 단지 디버그 빌드에서 디
버그 영역을 사용한다면 , #ifdef DEBUG #endif 안에 전역 변수인
dpCurSettings 와 Debug Zone 값을 정의해야 한다 . 그래서 DEBUGMSG
와 같은 디버그 매크로 및 Debug Zone 을 제한해야 한다 .
■ 릴리스 빌드에서 리테일 매크로 사용 사용자가 또한 릴리스 빌드에서 디버
그 영역을 사용하는 것을 윈한다면 #ifndef SHIP_BUILD #endif 안에 전역
변수인 dpCurSetting 와 Debug Zone 값을 정의해야 한다 . 그리고 디버그
빌드에서 사용했던 DEBUGREGISTER 대신 릴리스 빌드에서는 리테일
REGISTERZONES 을 사용해야 한다 .
■ 모듈 이름을 명확하게 지정 가능하면 , 그 모듈의 파일 이름으로
dpCurSettings.lpszName 값을 설정한다 .
■ 기본값으로 중복 제한 드라이버의 기본 Debug Zone 은 ZONE_ERROR 나
ZONE_WARNING 을 사용하라 . 새로운 새로운 플랫폼을 동작시킬때는
ZONE_INIT 을 사용한다 .
■ 복구할 수없는 문제의 오류 디버그 영역 제한 ZONE_ERROR 는 모듈이나
중요한 기능이 잘못된 설정이나 다른 이슈로 문제가 될 때만 사용하라 . 복
구 가능한 문제를 위해 ZONE_WARNING 를 사용한다 .
■ 가능한 모든 오류 및 경고 제거 모듈은 ZONE_ERROR 이나
ZONE_WARNING 메시지 없이 로드 될 수 있어야 한다 .
Target Control 명령Target Control 서비스는 타겟 장치로 파일을 옮기고 응용프로그램을 디버그 하
기 위해서 디버거의 명령 쉘에 대한 접근을 제공한다 . 그림 4-3 과 같은 타겟 제
어 쉘은 비주얼 스튜디오내의 플랫폼 빌더 메뉴 Target 메뉴에서 Target
Control option 메뉴를 통해 표시할 수 있다 . Target Control 쉘을 사용하기 위
해서는 플랫폼 빌더와 타겟 장치와 KITL 을 통해 연결되어 있어야 함을 명심해
야 한다 .
158 제 4장 디버깅 및 시스템 테스트
도표 4-3 Target Control 쉘
다른 것들 중에서 , Target Control 쉘은 사용자가 다음의 디버깅 작업을 수행할
수 있게 한다 .
■ 디버깅 모드로 진입 (break 명령 ).
■ 메모리 내용 덤프를 디버그 창에 출력하기 (dd 명령 ) 나 파일로 저장하기 (df
명령 ).
■ 커널 (mi kernel 명령 ) 또는 전체 시스템 (mi full 명령 ) 을 위한 메모리 사용
량 분석 .
■ 프로세스 목록 출력(gi proc 명령), 쓰레드 (gi thrd 명령), 그리고 쓰레드 우
선순위 (tp 명령 ), 뿐만 아니라 시스템에 모듈을 로드 (gi mod 명령 ).
■ 프로세스 시작 (s 명령 ) 그리고 프로세스 종료시키기 (kp 명령 ).
■ 프로세스 힙 덤프 (hp 명령 ).
■ 시스템 프로파일러를 사용 또는 비사용 (prof 명령 ).
참고 Target Control 명령
TARGET CONTROL 명령의 전체 명령 설명은 MICROSOFT MSDN ® 웹사이트에 있는 http://msdn2.microsoft.com/en-us/library/aa936032.aspx 에서 윈도우 임베디드 CE 6.0설명서의 “TARGET CONTROL 디버깅 명령” 섹션을 참조한다 .
CEDebugX기본 내장된 디버거 명령 이외에 , Target Control 서비스는 커널과 응용프로그
램 디버깅의 효율성을 증가시키기 위해 CEDebugX 를 제공한다 . 이 확장 디버거
명령은 메모리 누수 , 교착 상태 , 그리고 시스템의 전반적인 동작상태를 분석하
는 부가적인 기능을 제공한다 . 부가적인 명령은 Target Control 쉘을 통해 접근
할 수 있고 느낌표 (!) 로 시작한다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 159
CEDebugX 명령을 사용하기 위해서는 Target Control 쉘에서 Break 명령이나
Break All 명령을 사용하여 디버거 모드로 진입해야 한다 .
힙 손상 , 교착 상태 , 또는 메모리 부족과 같은 잠재적인 문제의 윈인을 찾기 위
해서는 !diagnose all 명령을 사용하여 분석한다 . 그림 4-4 와 같이 정상적인 시
스템에서는 CEDebugX 에서 어떠한 문제도 나타나면 안된다 .
그림 4-4 CEDebugX 로 런타임 이미지 분석
!diagnose all 명령은 다음과 같은 진단을 실행한다 .
■ Heap 잠재한 콘텐츠 손상을 식별하기 위해 시스템의 모든 프로세서의 모
든 힙 객체를 진단한다 .
■ Exception 시스템에서 발생한 예외에 대해 진단하고 자세한 정보를 제공
한다 . 프로세스나 쓰레드의 ID, PC 주소 , 예외가 발생한 시간 등이다 .
160 제 4장 디버깅 및 시스템 테스트
■ Memory 잠재한 메모리 손상과 메모리 부족 상태를 식별하기 위해 시스템
메모리를 진단한다 .
■ Deadlock 쓰레드 상태 진단 및 시스템 객체를 분석한다 . ( 쓰레드를 동기
화에 대한 자세한 내용은 제 3 장 참조 ). 이것은 시스템 객체의 목록과 교착
상태가 발생한 쓰레드 ID 를 제공할 수 있다 .
■ Starvation 잠재한 쓰레드 자윈 부족을 식별하기 위해 쓰레드와 시스템 객
체를 진단한다 . 자윈부족은 높은 우선순위의 쓰레드를 처리하기 위해서 스
케줄러가 더 이상 다른 쓰레드를 스케줄 할 수 없을 때 발생한다 .
고급 디버거 도구Target Control 쉘과 CEDebugX 명령은 실행중인 시스템이나 CE dump 파일 (
만일 사용자가 post-mortem 디버깅으로 CE 덤프 파일 리더를 선택한다면 ) 의
완전한 분석을 수행할 수 있게 한다 . 그러나 사용자가 커맨드라인 인터페이스에
제한되지는 않는다 . 플랫폼 빌더는 효율적인 디버깅 목적으로 몇 가지의 그래픽
툴들을 포함하고 있다 . 이러한 툴들은 비쥬얼 스튜디어의 Debug 메뉴의
Windows 명령을 통해 사용할 수 있다 .
플랫폼 빌더 통합 개발 환경은는 다음의 고급 디버거 도구를 포함한다 .
■ Breakpoints 시스템에 설정된 중단점 목록을 나열하고 중단점에 대한 속
성을 표시 , 관리한다 .
■ Watch 지역 , 전역 변수에 대한 읽고 / 쓰기 기능을 제공한다 .
■ Autos Watch 윈도우와 비슷한 변수 관리 기능을 제공한다 . Watch 윈도
우의 경우 사용자가 변수를 직접 등록해야 하지만 Autos 는 디버거가 동적
으로 변수 목록을 등록하게 된다 . 함수에서 전단되는 인자의 값을 검사하는
것 같은 작업에서 유용하다 .
■ Call Stack 시스템이 중단점에 멈췄을 때만 사용 가능하다 . 시스템에서 동
작중인 프로세서와 쓰레드의 목록을 표시해 준다 .
■ Thread 시스템에서 실행되고 있는 쓰레드에 대한 목록을 제공한다 . 이 정
보는 동적으로 검색되고 언제든지 갱신될 수 있다 .
■ Module 시스템에서 로드되거나 로드 되지 않은 모듈에 대한 정보를 제공
한다 . 로드된 모듈의 메모리 주소 정보를 제공한다 . 이 기능은 실제로 드라
이버 DLL 이 로드 여부를 확인하는 데 유용하다 .
■ Process 프로세스 - 쓰레드와 비슷한 기능 , 시스템에서 실행되고 있는 프
로세스의 목록을 제공해 준다 . 프로세서를 종료시킬 수 있는 기능을 제공해
준다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 161
■ Memory 장치의 메모리에 대해 직접 접근할 수 있는 기능을 제공한다 . 메
모리의 주소나 변수의 이름으로 메모리의 내용을 볼수 있게 해준다 .
■ Disassembly 현재 실행중인 코드에 대한 어셈블리 코드를 보여준다 .
■ Register 특정한 코드의 라인을 수행할 때 CPU 레지스터 값을 볼수 있게
해준다 .
■ Advanced Memory 메모리에서 특정 내용을 찾거나 , 메모리 일부분을 다
른 영역으로 옮기기 , 특정 패턴으로 메모리 채우기와 같은 기능을 제공한다 .
■ List Nearest Symbols 지정한 메모리 주소에서 가장 근접한 심볼을 찾을
때 사용한다 . 심볼을 포함하고 있는 파일에 대한 완전한 경로 정보를 제공
한다 . 이 도구는 예외가 발생한 함수를 찾는데 유용하다 .
주의 메모리 손상
메모리와 고급 메모리 도구는 메모리 내용을 수정할 수 있다 . 이 도구를 잘못 사용하는 것은 시스템손상을 발생시킬 수 있고 타겟 장치에 있는 운영체제를 손상시킬 수 있다 .
Application Verifier ToolCETK 에 포함된 어플리케이션의 잠재적인 호환성 , 안정성 , 소스레벨 문제를 검
증하는 도구는 응용프로그램 검증 도구이다 . 이도구는 그렇지 않으면 독립형 장
치에서는 발생하는 문제점을 파악하기 힘든 어플리케이션이나 DLL 에 연결하여
문제점을 분석할 수 있다 . 응용프로그램 검증 도구는 개발용 워크스테이션에 반
드시 연결해서 사용해야 하는 것은 아니다 . 시스템 구동시 드라이버나 시스템 어
플리케이션을 검증할 수 있다 . 또한 CETK 내의 사용자 인터페이스를 통하거나
수동으로 시작할 수 있다 . 사용자가 CETK 의 응용프로그램 검증 도구를 외부에
서 사용하는 것을 윈한다면 , 사용자는 릴리스 디렉터리 안으로 모든 필수 파일을
복사하기 위해 Getappverif_cetk.bat 파일을 사용해야 한다 .
참고 Application Verifier Tool 설명서
사용자 정의 테스트나 테스트 함수의 테스트 방법 변경을 하는 확장 DLL 사용 방법에 대해서나 ,APPLICATION VERIFIER TOOL 에 대한 자세한 내용은 MICROSOFT MSDN 웹 사이트 http://msdn2.microsoft.com/en-us/library/aa934321.aspx 의 윈도우 임베디드 CE 6.0 의 설명서에 있는“APPLICATION VERIFIER TOOL”섹션을 참고한다 .
CELog 이벤트 추적 및 처리윈도우 임베디드 CE 는 사용자가 성능 문제를 진단하기 위해 런타임 이미지에 포
함할 수 있는 확장 가능한 이벤트 추적 시스템을 포함한다 . CELog 이벤트 추적
162 제 4장 디버깅 및 시스템 테스트
시스템은 사전 정의된 커널과 뮤텍스 , 이벤트 , 메모리 할당과 다른 커널 객체와
관계된 일련의 coredll 이벤트를 기록한다 . CELog 이벤트 추적시스템의 확장 가
능한 아키텍처는 또한 사용자가 사용자 정의된 이벤트를 추적하기 위해 사용자
지정 필터를 구현할 수 있게 한다 . KITL 을 통해 개발용 워크스테이션에 연결된
플랫폼을 위해 이벤트 추적 시스템은 표 4-4 에 요약된 것처럼 ZoneCE 레지스
터리를 이용하여 선택적으로 기록할 수 있도록 선택할 수 있다 .
CELog 이벤트 추적 시스템을 사용하여 타겟 장치의 램 영역에 저장되어 있는 로
그 정보를 수집하고 이용할 수 있다 . 수집된 로그 데이터는 윈격 커널 트랙커를
사용하거나 Readlog 와 같은 도구를 이용하여 분석할 수 있다 . CELogFlush 도
구를 사용하여 주기적으로 파일로 저장하고 이용할 수 있다 .
참고 CELog 와 ship 빌드
운영체제 최종 빌드시에는 CELOG 시스템을 포함시키지 말아야 한다 . CELOG 의 동작으로 인해 시스템성능과 가용 메모리의 감소 효과를 가져오기 때문이다 . 또한 악의적인 사용자의 시스템에 대한 공격시도를 줄이기 위해서다 .
Remote Kernel Tracker
Remote Kernel Tracker 도구는 사용자가 타겟 장치 시스템의 프로세서와 쓰레
드의 활동을 모니터 할 수 있게 한다 . 이 도구는 KITL 을 통해 타겟 장치로부터
얻은 정보를 실시간으로 화면에 표시할 수 있을 뿐만 아니라 CELog 파일을 이용
한 오프라인 분석도 가능하다 . 사용자는 3 장의 “시스템 프로그래밍 실행” 에
서 Remote Kernel Tracker 도구에 대한 더 많은 정보를 발견할 수 있다 . 그림
4-5 는 커널 트랙커를 이용하여 타겟 장치의 쓰레드 활동의 정보를 수집하는 것
을 보여준다 .
표 4-4 이벤트 로그 영역을 위한 CELog 레지스트리 매개 변수
위치 HKEY_LOCAL_MACHINE₩System₩CELog
레지스트리 항목 ZoneCE
항목 유형 REG_DWORD
값 <Zone IDs>
설명 기본값으로 모든 영역은 기록된다 . 모든 가능한 영역 ID 값 목록은 , 윈도우 임베디드 CE 6.0 설명서에 있는 “CELog Zones” 영역을 참조한다 . 이것은 마이크로소프트 MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa909194.aspx 에서 이용할 수 있다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 163
그림 4-5 커널 트랙커에서 쓰레드 정보
CELogFlush 도구
CELogFlush 도구는 타겟장치의 RAM 에 저장되어 있는 CELog 이벤트 자료를
.clg 형태의 파일로 저장하기 위해 사용한다 . 이 파일은 RAM 파일 시스템 , 저장
장치 , 또는 개발용 워크스테이션에 있는 릴리스 파일 시스템에 위치할 수도 있다 .
버퍼오버런으로 인한 자료 손실을 최소화 하기 위해 , 사용자는 더 큰 RAM 버퍼
를 지정할 수 있고 CELog 버퍼를 출력하는 주기를 증가시킬 수 있다 . 사용자가
반복된 파일 열고 닫는 작업을 회피하고 느린 영구적 저장 매체 대신 RAM 파일
시스템에서 파일을 저장하도록 설정해 놓는다면 좀 더 성능 향상을 기대할 수 있
다 .
참고 CELogFlush 구성
CELOGFLUSH 도구를 레지스터리를 설정을 통하여 구성하는 방법에 대한 자세한 내용은 윈도우 임베디드 CE 설명서의 “CELOGFLUSH 레지스트리 설정” 섹션을 참고한다 . 이것은 마이크로소프트 MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa935267.aspx 에서 이용할 수 있다 .
Readlog 도구그래픽 Remote Kernel Tracker 응용프로그램 이외에 %_WINCEROOT%
₩Public₩Common₩Oak₩Bin₩i386 폴더에 위치한 Readlog 툴을 이용하여
CELog 자료 파일을 처리할 수 있다 . Readlog 툴은 윈격 커널 트랙커에 의해 나
164 제 4장 디버깅 및 시스템 테스트
타나지 않는 디버그 메시지나 부트 이벤트등의 정보를 처리하고 화면에 보여주
는 커맨드 라인 도구이다 . 초기에 윈격 커널 트랙커를 이용하여 시스템을 분석하
는 것은 매우 유용한 방법이다 . 분석후 확인된 프로세서나 쓰레드를 Readlog 툴
을 이용하여 분석을 하게 된다 . CELogFlush 툴에 의해 저장된 .clg 파일은 영역
별로 정리가 되어 있기 때문에 특정한 정보를 정리 분석하기에 유용하다 . 사용자
는 또한 그 자료를 필터 할 수 있고 사용자 지정 이벤트 콜렉터를 통해 수집한 사
용자 지정 자료를 처리해서 확장 DLLs 에 기반하는 필터링 능력을 확장할 수도
있다 .
가장 유용한 Readlog 시나리오의 하나는 Remote Kernel Tracker 에서 시스템
분석을 용이하게 하기 위해서 CELog 자료파일에 있는 쓰레드의 시작 주소
(CreateThread 호출로 전달되는 함수 ) 를 실제 함수의 이름으로 교체하는 것이
다 . 이 기능을 사용하기 위해서는 -fixthreads 매개변수를 사용하여 Readlog 를
시작해야 한다 ( 즉 , readlog -fixthreads). Readlog 는 .map 파일에 있는 심볼
의 정보를 살펴보고 쓰레드 함수의 시작주소와 일치시켜 함수의 이름으로 정리
된 새로운 CELog 파일을 생성하게 된다 .
그림 4-6 CELog 데이터 파일이 readlog -fixthreads 명령에 의해 처리되고 윈격 커널 트랙커에 의해 열린 그림이다 .
제 1 과 : 소프트웨어 관련 오류 찾아내기 165
그림 4-6 은 Remote Kernel Tracker 에서 CELogFlush 도구를 이용하여 .clg
파일로 저장하고 , Readlog 툴을 -fixthreads 옵션을 사용하여 로그 파일을 처리
하고나서 Kernel Tracker 에서 처리된 .clg 파일을 분석하여 보여주는 것이다 .
실제 함수명이 나오기 때문에 분석이 좀더 용이하다 .
참고 참조 이름 일치 개선시키기
CELOG 이벤트 추적 시스템은 커널 프로파일러 기능을 설정하고고 환경변수에서 IMGPROFILER=1 로 설정해서 런타임 이미지를 재빌드 했을 때 사용 가능하다 . CELOG 이벤트 추적 시스템은 커널 프로파일러가 가지고 있는 쓰레드 함수 찾아보기 기능을 이용하고 있다 . 그러나 CELOG 는 런타임 이미지에 내장된 프로파일링의 심볼만 검색할 수 있다 . SOFTWARE DEVELOPMENT KIT(SDK) 에 기반하여 개발된 응용프로그램의 심볼은 CELOG 이벤트 추적시스템을 사용할 수 없다 .
요점 정리운영체제와 응용프로그램의 디버깅은 CE 시스템 그리고 플랫폼 빌더와 CETK
가 포함된 양쪽 모두의 지식이 요구된다 . 가장 중요한 디버깅 툴들은 시스템 디
버거 , 디버그 메시지 기능 , 그리고 CE 는 타겟 제어 쉘이다 . 디버그 메시지 기능
이 코드 실행을 방해하지 않고 시스템 구성요소와 응용프로그램을 분석하는 기
능을 제공하는 동안 , 시스템 디버거는 사용자가 중단점을 설정하고 커널과 응용
프로그램 코드를 단계적으로 실행시키면서 디버깅하는 기능을 가능하게 한다 .
디버그와 리테일 매크로의 다양성은 타겟장치에서 화면표시 구성요소 여부와 상
관 없이 디버깅 정보의 출력은 사용 가능하다 . 시스템과 응용프로그램이 잠재적
으로 대량의 디버그 메시지를 생성시킬 수 있기 때문에 , 사용자는 디버깅 정보의
출력을 제어하기 위해 디버그 영역을 이용해야 한다 . 디버그 영역의 중요한 장점
은 사용자가 런타임 이미지를 리빌드 하지 않고도 동적으로 디버그 정보의 출력
설정을 변경할 수 있다 . 또 한 편으로는 , 타겟 제어 쉘은 사용자가 Break 명령으
로 디버그 모드에 진입한 후 전반적인 시스템 상태를 확인할 수 있는 CEDebugX
의 기능중의 하나인 !diagnose all 명령어를 사용하여 분석한다 .
이 코어 디버깅 도구와는 별도로 , 사용자는 전형적인 CE 구성과 응용프로그램
검증 도구와 잠재한 응용프로그램 호환성과 안정성 문제를 식별하기 위해서 그
리고 프로세스 , 쓰레드 , 그리고 시스템 성능을 분석하는 Remote Kernel
Tracker 같은 도구를 사용할 수 있다 .Remote Kernel Tracker 는 CELog 이벤
트 추적시스템에 의존한다 . 타겟 장치의 메모리에 기록된 로그 데이터는
CELogFlush 도구를 이용하여 파일로 출력한다 . 분석하려는 모듈의 심볼 파일
을 가지고 있다면 Readlog 도구를 이용하여 로그 파일에 있는 쓰레드의 시작 주
소를 실제 함수의 이름으로 변경하여 새로운 로그 파일로 생성할 수 있다 .
Remote Kernel Tracker 를 이용해 이 로그 파일을 좀더 편리하게 사용할 수 있
게 한다 .
166 제 4장 디버깅 및 시스템 테스트
디버깅 가능한 런타임 이미지 구성윈도우 임베디드 CE 의 디버깅 기능은 개발용 워크스테이션 구성요소와 타겟 장
치에 의존한다 . 그리고 특정한 설정과 하드웨어 지윈을 요구한다 . 개발용 워크
스테이션과 타겟 장치 사이의 연결 없이 정보를 교환하거나 디버깅 할 수 없다 .
만약 타겟 장치의 디버깅 모듈을 언로드 하지않고 통신 연결이 끊어진다면 개발
워크스테이션에 있는 디버거는 멈출 것이다 . 또한 타겟 장치는 사용자의 입력에
무응답 할 것이다 . 그 이유는 디버거가 코드의 재 실행을 지시할때까지 대기 상
태가 되기 때문이다 .
이 과정을 마치면 , 사용자는 다음을 할 수 있다 .
■ 런타임 이미지를 위한 커널 디버거 활성화 .
■ KITL 요구사항의 확인 .
■ 디버깅 컨텍스트에 커널 디버거 사용 .
예상 학습 시간 : 30 분 .
커널 디버거 활성화 위와 같이윈도우 임베디드 CE 6.0 을 위한 개발 환경은 개발자가 CE 타겟 장치
에서 코드 실행과 코드를 순차적으로 실행하도록 제어할 수 있는 커널 디버거를
포함한다 . 이 디버거는 사용자가 타겟 장치와 개발용 컴퓨터 사이에 커널 선택과
통신 계층을 설정할 것을 요구한다 .
OS 디자인 설정디버깅을 위한 OS 설계를 활성화하게 하기 위해 , 플랫폼 빌더가 KdStub 라이브
러리를 포함하고 런타임이미지를 구축할 때 Board Support Package(BSP) 에
있는 KITL 통신 계층을 사용하게 하도록 환경 변수 IMGNODEBUGGER 과
IMGNOKITL 를 해제한다 . 비주얼 스튜디오에서 , 플랫폼 빌더에서는 메뉴를 통
하여 보다 손쉽게 설정할 수 있는 방법을 제공한다 . 그 방법은 OS desing project
를 선택하여 오른쪽 마우스 버튼을 누르고 , Properties 를 선택한다 . Build
Options 창에 Enable Kernel Debugger 와 Enable KITL 을 선택한다 . 1 장 “운
영 체제 설계의 사용자 지정” 에서 더 많은 OS Design 속성 페이지 대화 상자세
부사항을 논의한다 .
디버거 선택
런타임 이미지를 위해 KdStub 와 KITL 을 사용 가능하게 하면서 , 타겟 장치에
대한 통신 매개변수에서 타겟 장치 위에 시스템을 분석하기 위해 디버거를 선택
디버깅 가능한 런타임 이미지 구성 167
할 수 있다 . 이 매개변수를 구성하기 위해 , 2 장 “런타임 이미지 빌드 및 배포”
에서 설명한 대상 메뉴를 열고 , Connectivity Options 을 선택함으로써 비주얼
스튜디오에서 타겟 장치 연결 선택 대화 상자를 화면 표시한다 .
어떠한 디버거도 연결 옵션에는 선택되어있지 않다 . 다음과 같은 디버거 중 선
택해야 한다 .
■ KdStub 이것은 커널과 응용프로그램이 시스템 구성요소 , 드라이버 , 그리
고 타겟 장치에서 실행하는 응용프로그램을 디버그 하는 소프트웨어 디버거
이다 . KdStub 는 플랫폼 빌더와 통신하기 위해 KITL 을 요구한다 .
■ CE Dump File 플랫폼 빌더는 Dump 파일을 캡쳐하기 위한 옵션을 제공한
다 . 이 덤프 파일은 CE 덤프 파일 리더를 사용하여 불러 올 수 있다 . Dump
파일은 시스템의 특정한 상태를 살펴볼 수 있게 하는 유용한 도구다 .
■ Sample Device Emulator eXDI 2 Driver -KdStub 는 커널이 로드 되기 전
의 코드들은 디버깅 할 수 없다 . 디버깅 라이브러리는 소프트웨어에 의한 중
단점을 사용하기 때문에 인터럽트 처리 루틴 (ISR) 은 디버깅 할 수 없다 .
하드웨어 장치를 통한 디버깅을 위해 플랫폼 빌더에서는 joint test action
group(JTAG) 을 통하여 디버깅 할 수 있는 장비에 대한 샘플 eXDI 드라이
버를 제공한다 .
참고 하드웨어 -지윈 디버깅
하드웨어 - 지윈 디버깅에 관한 상세한 정보 는 윈도우 임베디드 CE 6.0 설명서의 “하드웨어 - 지윈디버깅” 섹션을 참고한다. 이것은 마이크로소프트MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa935824.aspx 에서 이용할 수 있다 . .
KITL이장의 시작 부분에서 그림 4-1 에서 볼 수 있듯이 KITL 은 개발용 컴퓨터와 타
겟 장치 사이에 필수적인 통신 계층이고 커널 디버거 지윈을 위해 사용하게 해야
한다 . 이름이 암시하는 것과 같이 , DMA 와 같게 KITL 은 완전하게 하드웨어와
독립적이다 . 네트워크 연결 , 시리얼 케이블 , 범용 직렬 버스 (USB), 또는 DMA
(DMA) 같은 기타 지윈하는 통신 메커니즘 위로 작동 한다 . 유일한 필요는 양 쪽
( 개발용 컴퓨터와 타겟장치 ) 모두 같은 인터페이스를 지윈하고 사용해야 한다 .
4-7 그림과 같이 장치 에뮬레이터를 위한 가장 일반적이고 빠른 KITL 인터페이
스는 DMA 이다 . 지윈된 이더넷 칩을 가지는 타겟 장치가 네트워크 인터페이스
를 사용하는 것은 일반적으로 가장 바람직하다 .
168 제 4장 디버깅 및 시스템 테스트
그림 4-7 KITL 통신 인터페이스의 구성
KITL 은 다음과 같은 두 가지 작업 방법을 지윈한다 .
■ Active Mode 기본값에 의해 , 플랫폼 빌더는 부팅 프로세스 동안 개발용 컴
퓨터에 연결하기 위해 KITL 을 구성한다 . 이 설정은 소프트웨어 개발 주기
동안 커널과 응용프로그램 디버깅에 대해서 유용하다 .
■ Passive Mode Device Boot에 활성화 KITL확인란을 선택 취소함으로써 수
동 모드로 KITL 을 구성할 수 있다 . 윈도우 임베디드 CE 는 KITL 인터페이
스를 초기화하는 것을 의미하나 KITL 은 구동 프로세스 동안 연결을 설정하
지 않는다. 예외가 발생하면, 사용자가 JIT 디버깅을 수행할 수 있도록 KITL
은 개발용 컴퓨터로 연결을 만들기 위해 시도한다 . 수동 모드는 구동할 때
개발용 컴퓨터로의 물리적 연결을 가지고 있지 않는 이동하기 쉬운 장치를
개발할 때 가장 유용하다 .
디버깅 가능한 런타임 이미지 구성 169
참고 KITL 모드와 부트 인자
장치부트 설정에 있는 ACTIVE KITL은 플랫폼 빌더가 부트 로더를 위해 구성하는 부트 인자(BOOTARGS)이다 . BSP 개발 프로세스 동안 부트 로더와 그들의 장점에 대한 더 많은 정보는 윈도우 임베디드 CE설명서의 “부트로더” 섹션을 참조한다 . 이것은 마이크로소프트 MSDN 웹사이트 HTTP://MSDN2.MICROSOFT.COM/EN-US/LIBRARY/AA917791.ASPX 에서 이용할 수 있다 .
타겟장치 디버깅하기개발자 - 측과 대상 - 측 디버거 컴포넌트는 각 각 독립적으로 실행된다는 것을
아는 것이 중요하다 . 예를들면 , 커널 디버거는 유효한 타겟장치 없이 플랫폼 빌
더와 함께 비주얼 스튜디오비주얼 스튜디오에서 실행하는 것이 가능하다 . 만일 ,
디버그 메뉴를 열고 시작을 클릭하거나 F5 키를 누르면 , 커널 디버거 (Kernel
Debugger) 는 타겟 장치에 연결을 기다리는 출력 창에서 시작과 동시에 정보를
알려준다 . 다른 한편으로는 , 이 장에서 언급한 바와 같이 만일 디버거에 유효한
KITL 연결 없이 디버깅 - 가능 런타임 이미지를 실행 하고 예외가 발생 한다면 ,
런타임 이미지는 시스템이 멈춤으로 말미암아 끈어지게 (hang) 되며 , 디버거로
부터 제어 요청을 기다린다 . 이러한 이유때문에 디버깅 - 가능 타겟 장치에 연
결할 때는 디버거는 일반적으로 자동으로 시작된다 . F5 를 눌러서 디버깅 세션
을 시작하는 대신에 대상 메뉴에서 (Target menu) 부착 장치 (Attach Device)
를 사용한다 .
중단점 활성화하기와 관리하기 Enabling and Managing 플랫폼 빌더의 디버깅 기능들은 Windows 의 데스크 탑 응용프로그램의 디버거
와 마찬가지로 그 기능을 제공 한다 . 그림 4-8 에서 서술한 바와 같이 중단점을
설정하거나 , 코드의 한 줄씩 따라하거나 , 조사식 창 (Watch window) 을 사용하
여 변수의 값과 개체 특성을 변경하거나 볼 수있다 . 기억 하여야 할 것은 , 그러
나 , 런타임 이미지에서 중단점 사용 능력은 KdStub 라이브러리의 존재함에 따
라 달려있다 .
중단점을 설정하기 위해서는 , 비주얼 스튜디오비주얼 스튜디오의 디버그 메뉴
에서 중단점 전환 옵션을 사용하여 설정 한다 . 다른 방법으로는 , F9 을 눌러 현
재의 입력란에서 중단점을 설정하거나 코드 입력란의 왼쪽 여백을 클릭한다 . 선
택한 것을 보면 , 디버는 중담점을 인스턴스화 하거나 하지 못하는지에 대하여 플
랫폼 빌더는 중단점을 빨간 점이나 윈으로 표시한다 . 빨간 윈은 인스턴스화 하지
못하는 중단점을 나타낸다 . 만일비주얼 스튜디오 인스턴스가 대상 코드 (targe
code) 와 연결이 되어 있자 안을 경우 인스턴스가 없는 중단점이 발생되며 , 중단
점은 설정이 되었지만 로드가 안된 상태이며 , 디버거는 사용 불능 상태이며 , 디
버거는 사용불능이거나 , 디버거가 실행중이나 코드 실행이 멈추지 않은 상태에
170 제 4장 디버깅 및 시스템 테스트
서 발생된다 . 만일 디버거가 실행중일때에 중담점을 설정하면 , 장치는 반드시 디
버거가 중단점을 인스턴스화 하기전에 먼저 디버거로 진입하여야 한다
그림 4-8 Hello World 응용프로그램 (application) 디버깅 하기
플랫폼 빌더와 함께비주얼 스튜디오 에서 중단점을 관리하기 위한 옵션은 다음
과 같다 .
■ 소스 코드 , 스택 (Call Stack) 호출 과 창 분리 (Disassembly windows) 상
황에 맞는 메뉴 (context menu) 에서 중단점을 삽입 / 삭제를 선택하거나 디
버그 메뉴에서 전환 중단점을 선택하거나 또는 F9 을 누름으로서 중단점을
설정 , 삭제 , 사용가능 , 사용불능으로 전환 할 수 있다 .
■ 새 중단점 대화 창 (New Breakpoint dialog box) 이 대화상자는 디버그 메
뉴에서 새 중단점 아래 있는 하위 메뉴로 표시 할 수 있다 . 새 중단점은 대
화상자는 중단점의 위치와 조건을 설정 할 수 있도록 하여 준다 . 디버거는
반복 계산이나 특별히 지정된 값이 조건 중단점의 조건 값이 TRUE 일때만
멈추게 된다 .
디버깅 가능한 런타임 이미지 구성 171
■ 중단점 창 (Breakpoints window) 디버그 메뉴에서 윈도우 하위 메뉴에 있
는 중단점을 클릭하거나 Alt+F9 를 누름으로서 중단점 창을 표시 할 수 있
다 . 중단점 창은 설정된 중단점 대화상자를 중단점과 중단점 속성 설정을
가능케하는 목록을 나열한다 . 예를들면 , 위치 정보를 수동으로 지정하는
새 중단점 대화상자를 사용하는 대신 , 윈하는 중단점을 소스 코드에 직접 설
정한 후 조건 매개변수를 정의하기 위한하여 중단점 창의 특성을 표시한다 .
팁 중단점이 많은 경우
연습으로 중단점을 사용하기 . 너무 많은 중단점을 설정하거나 계속해서 재 실행을 선택 할 경우 디버깅의 효과에 영향을 미칠 수 있으며 , 시스템의 한개의 시점에 초점을 마추기가 어렵다 . 필요 함에 따라 중단점을 비활성화 하거나 재 활성화하는 것을 고려 해보아야 한다 .
중단점 제한새 중단점 대화상자 또는 중단점 창에서 중단점의 속성을 구성 할때 , 하드웨어
중단점 또는 소프트웨어 중단점을 설정 할 수 있는 하드웨어 단추를 발견 할 수
있다 . OAL 코드나 인터럽트 처리기 (interrupt handlers) 에서는 소프트웨어 중
단점은 사용 할 수 없는데 , 왜냐하면 중단점은 시스템의 실행을 완전히 멈추게
하면 안되기 때문이다 . 다른 시스템 프로세스 사이에서 , KITL 연결은 유효화 되
어 있어야하는데 . 이는 개발 워크스테이션에서 유일하게 이 연결을 통하여 통신
할 수 있기때문이다 . OAL 과 함께 KITL 인터페이스는 커널의 인터럽트 기반
(interrupt-based) 통신 방식을 사용한다 . 만일 , 인터럽트 처리기 기능 ( 함수 )
에서 한 개의 중단점을 설정 한다면 , 중단점에 다다르면 인터럽트 처리는 단일
스레드와 무인터럽트 기능 ( 함수 ) 임으로 시스템은 더 이상 통신할 수 없게된다 .
만일 인터럽트 처리기를 디버그하여야 한다면 , , 디버그 메시지나 하드웨어 중단
점을 사용 할 수 있다 . 그러나 , 하드웨어 중단점은 프로세스의 디버그 등록기에
인터럽트를 등록하기 위해서는 eXDI 준수 디버거 (JTAG Probe 과 같은 ) 를 필
요로 한다 . 일반적으로 , 한 개의 하드웨어 디버거 만이 프로세스 중 사용 가능 한
데 , 그럼에도 불구하고 JTAG 는 다수의 디버거를 사용 할 수 있다 . 하드웨어 지
윈 디버깅을 하기 위해서 KdStub 라이브러리를 사용 할 수는 없다 .
하드웨어 중단점을 구성하기 위해서는 다음 단계를 따라하면 된다 .
1. 디버그 메뉴를 열고 중단점을 클릭함으로써 중단점 창을 연다 .
2. 중단점 목록에서 중단점을 선택하고 오른쪽 마우스 버튼을 클릭한다 .
3. 중단점속성을 대화상자를 표시하기 위하여 중단점 속성을 클릭한 다음 하드
웨어 단추를 클릭한다 .
172 제 4장 디버깅 및 시스템 테스트
4. 하드웨어 확인 버튼을 선택한 다음 모든 대화 상자를 닫기 위해 확인을 두
번 클릭한다 .
그림 4-9 하드웨어 중단점 설정하기
학습 요약만일 , 런타임 이미지에서 KITL 과 디버거 라이브러리를 포함 시키면 플랫폼 빌
더 IDE 에서 디버거를 사용 가능케 하는 구성 단계는 간단해진다 . 타겟 장치 연
결 옵션 (Target Device Connectivity Options) 대화상자를 표시한 후 , 적합한
디버거와 전송을 선택한다 . 일반적으로 , 전송은 DMA 나 이더넷 (Etherne) 을 사
용하는데 , USB 나 시리얼 케이블을 사용하여 타겟장치에 워크스테이션을 연결
할 수 도 있다 .
플랫폼 빌더는 윈도우 바탕화면에서 찾아 볼 수있는 디버거들 같은 디버깅 기능
을 제공한다 . 중단점의 설정은 코드의 줄에서 줄의 단계로 , Watch 창을 사용하
여 변수의 값과 개체 속성의 변경과 보기를 설정 함으로 할 수 있다 . 플랫폼 빌더
역시 지정한 기준에 의하여 코드 실행을 중지 할 수 있는 조건 중단점을 지윈한
다 . 소프트웨어 디버깅을 위한 디버거의 선택은 KdStub 인데 , 그럼에도 불구
하고 , 다른 하드웨어 디버거나 JTAG 프로브 (Probe) 상에서 하드웨어 - 지윈 디
버깅 기반을 위한 플랫폼 빌더와 함께 eXDI 드라이버를 사용 할 수 있다 . 하드
웨어 - 지윈 디버깅은 커널에 로딩 하기전 시스템의 루틴을 분석하거나 OAL 컴
포넌트 와 인터럽트 처리기 기능을 소프트웨어 중단점이 사용 할 수 없는 위치에
서 사용 가능케 한다 .
학습 3 : CETK 를 사용하여 시스템 테스트하기 173
학습 3 : CETK 를 사용하여 시스템 테스트하기자동화된 소프트웨어 테스트는 지윈 비용과 개발 비용을 낮추고 제품의 질을 향
상시키는데 중요한 역활을 한다 . 이 것은 , OAL 코드를 구현하거나 , 새 장치 드
라이버를 추가하거나 , 타겟 장치를 위한 사용자화된 BSP 를 생성 할 때 특히 중
요하다 . 시스템의 새로운 시리즈를 프로덕션에 릴리스 하기전에 , 기능테스트 ,
단위테스트 , 스트레스테스트와 다른 종류의테스트를 통하여 시스템의 각 부분과
을 검증 하는 것과 일반 상태에서 타겟장치가 안정적으로 실해이 되는지를 실행
하여 보는 것이 매우 중요하다 . 시스템이 개발 중 일때 테스트 도구 와 스크립트
를 생성하거나 , 타겟 장치를 사용자의 환경과 비슷한 환경으로 작업하는 도중 결
함이 발견 되었을때 수정 하는 것 보다 제품이 시장에 도달한 후에 수정하는 것
은 더 많은 비용이 들 수 가 있다 . 시스템 테스트는 마케에 도달하기 전에 실행
되어져야한다 . 소프트웨어 개발 기간중효과적으로 시스템 테스트를 하기 위해서
는 CETK 를 사용 할 수 있다 .
이 학습을 마친 후 , 다음과 같은 것을 할 수 있음 :
■ CETK 검사 도구를 위한 일반적인 사용 시나리오 기술 .
■ 사용자 정의된 CETK 테스트를 생성 .
■ 타겟 장치에서 CETK 테스트를 실행 .
예상 학습 시간 : 30 분 .
윈도우 임베디드 CE 테스트 키트 개요CETK 은 분리된 테스트이며윈도우 임베디드를 위한 플랫폼 빌더를 포함 한 응
용프로그램으로서 응용프로그램의 안정성 검증과 CE 테스트 목록에서 자동화
된 테스트 구성의 시리즈에 기반을 둔 장치 드라이버를 포함한다 . CETK 은 주
변기기의 여러 드라이버 카테고리를 위한 여러 기본 테스트를 포함하며 , 특정한
필요에 따라 사용자화 테스트를 생성 할 수 있다 .
참고 CETK 검사
CETK 에 포함된 기본 테스트 목록을 위해서는 마이크로소프트 MSDN 웹사이트 ht tp : / /msdn2.microsoft.com/en-us/library/aa917791.aspx 에 있는 윈도우 임베디드 CE 6.0 문서의“CETK테스트”섹션을 참조 하면 된다 .
CETK 아키텍처 (Architecture)그림 4-10 에서 서술 한바와 같이 , CETK 응용프로그램은 타겟 장치의 개발 컴
퓨터 상에서 실행되는 컴포넌트의 클라이언트 / 서버 (client/server) 솔루션이다 .
174 제 4장 디버깅 및 시스템 테스트
개발 컴퓨터는 타겟장치가 클라이언트 - 측 응용프그램 (Clientside.exe), 테스트
엔진 (Tux.exe), 테스트 결과 로거 (Kato.exe) 를 실행하는 동안 워크스테이션 서
버 응용프로그램 (CETest.exe) 을 실행한다 . 다른 것들 사이에서 , 이 아키텍처
는 개발 워크스테이션에서 다수의 서로 다른 장치상에서 동시에 여러 테스트들
을 실행할 수 있게하여준다 . 워크스테이션 서버와 클라이언트 - 측 응용프로그
램은 KITL, ActiveSync ® , 또는 윈도우 소켓 (Winsock) 의 연결을 통하여 통신
한다 .
그림 4-10 CETK 클라이언트 / 서버 아키텍처
CETK 응용프로그램은 다음과 같은 컴포넌트를 포함한다 .
■ 개발 워크스테이션 서버 (Development workstation server) CETest.exe
는 CETK 테스트를 실행하거나 관리 할 수 있도록 GUI(Graphic User
Interface) 를 제공한다 . 이 응용프로그램은 서버 설정과 매개변수 연결을
설정 할 수 있으며 , 타겟 장치에도 연결 할 수 있도록 하여준다 . 장치 연결
을 설정 하기 위해서 워크스테이션 서버는 클라이언트 쪽 응용프로그램을
자동으로 다운로드하고 시작하며 , 테스트 검사 요청을 제출하고 , 표시하기
위하여 실시간으로 캡쳐 로그 에 기반을 둔 테스트의 결과 를 컴파일 한다 .
■ 클라이언트 쪽 응용프로그램(Client-side application) 워크스테이션 서버
응용프로그램의 Clientside.exe 인터페이스는 테스트 엔진을 제어 하는 것
과 서버 응용프로그램에 테스트 결과를 반환한다 . 만일 , Clientside.exe 가
타겟장치상 에서 사용 할 수 없을 경우 , 워크스테이션 서버는 타겟장치에
통신 스트림 (stream) 을 설치 할 수 없다 .
학습 3 : CETK 를 사용하여 시스템 테스트하기 175
■ 테스트 엔진(Test engine) CETK 테스트는 대상 장치에서 Tux.exe 가 로
드되고 실행되는 DLL 내에서 구현된다 . 일반적으로 , 테스트 엔진은 워크
스테이션 서버와 클라이언트 쪽 응용프로그램을 통하여 윈격으로 시작 할
수 있고 , Tux.exe 를 로컬에서 실행 할 수 있으며 , 워크스테이션 서버의 필
요 없이 독립으로 실행 할 수 있다 .
■ 테스트 결과 로거 (Test results logger) Kato.exe 는 로그 파일에 있는
CETK 의 결과를 추적한다 . Tux DLLs 은 이 로거를 사용하여 테스트의
성공 여부와 여러 사용자 정의된 출력 장치로 출력이 라우팅이 되었는지에
대한 추가 정보를 제공한다 . 이유는 모든 CETK 테스트는 동일한 로거와
형식을 사용하는데 , 특정 요구사항 에 의한 자동 결과 진행을 위한 사용하
거나자화 로그 파일 파서를 구현하거나 또는 기본 파일 파서 (parser) 를 사
용하는 것이 가능 하기 때문이다 .
참고 관리 코드를 위한 CETK (CETK for managed code)
CETK 의 관리 버전은 네이티브 (NATIVE) 와 관리 코드의 유효성을 확인 하기 위하여 사용이 가능하다 .관리 버전에 관한 자세한 사항은, MICROSOFT MSDN 웹사이트http://msdn2.microsoft.com/en-us/library/aa934705.aspx 의 WINDOWS EMBEDDED CE 6.0 문서에 있는 “TUX.NET TEST HARNESS”의 섹션을 참조하라 .
CETK 사용하기타겟 장치에서 여러 연결 옵션을 지윈하기 위하여 CETK 테스트 를 실행 할 수 있
다 . 타겟 장치에서 연결하기 위해서는 , KITL, Microsoft ActiveSync, 또는 TCP/
IP 를 사용 하여 타겟 장치를 연결하고 , 대상 쪽의 CETK 컴포넌트를 다운로드
하고 , 윈하는 테스트를 실행하고 , 개발 워크테이션 상에서 GUI 내에서 결과를
볼 수 있다 . 다른 한편으로는 , 타겟 장치가 이 연결 옵션들을 지윈하지 않을 경
우 , 테스트를 적합한 커맨드 라인과 옵션과 함께 로컬에서 실행하여야 한다 .
CETK 워크스테이션 서버 응용프로그램 사용하기 (CETK 워크스테이션 서버 응용프로그램 )워크스테이션 서버 응용프로그램으로 작업 하기 위해서는 , 개발 컴퓨터의윈도우
임베디드 CE 6.0 프로그램 그룹에 있는윈도우 임베디드 CE 6.0 테스트 키트를
클릭한 후 , 연결 메뉴를 열고 , 시작 클라이언트 (Start Client) 명령을 선택한다 .
설정 버튼을 클릭함으로 전송을 구성한다 . 만일 , 타겟 장치가 전환되어개발 워
크스테이션으로 연결 되었을 경우 , 연결을 클릭한 후 , 윈하는 타겟 장치를 선택
한 후 , 표시하기 위하여 필요한 바이너리와 통신 채널을 설정하기 위하여 확인
버튼을 클릭한다 . CETK 응용프로그램은 이제 타겟장치 상에서 테스트를 실행
할 준비가 되었다 .
176 제 4장 디버깅 및 시스템 테스트
그림 4-11 에서 서술한 바와 같이 , CETK 응용프로그램은 자동으로 사용 가능
한 장치 드라이버를 찾아내고 , 테스트를 실행 할 수 있도록 간편한 방법을 제공
한다 . 한 가지 방법으로는 CETK 가 감지한 모든 컴포넌트를 테스트를 할 수 있
도록 테스트 메뉴에 있는 시작 / 멈춤 테스트 아래 있는 장치 이름을 클릭한다 . 다
른 방법으로는 , 테스트 목록 노드 (Test Catalog node) 를 오른쪽 마우스 버튼을
클릭하여 시작 테스트 (Start Tests) 명령을 선택하는 방법이 있다 . 단일 컴포넌
트를 테스트 하기 위해서는 개개의 컨테이너를 확장하거나 , 개인 장치를 마우스
의 오른쪽 버튼으로 클릭하거나 , 빠른 시작 (Quick Start) 을 클릭한다 . 장치 노
드를 마우스의 오른쪽 버튼을 클릭하거나 도구의 하위메뉴를 열어 워크스테이션
서버 응용프로그램은 응용프로그램 검증도구 (Application Verifier), CPU 모니
터 , 리소스 사용 (Resource Consume), 윈도우 임베디드 CE 스트레스 도구
(Stress tool) 등의 액세스를 제공한다 .
그림 4-11 CETK 응용프로그램의 그래픽 사용자 인터페이스 (GUI)
테스트 도구모음 생성 (Create a Test Suite)모든 테스트를 한 번에 실행하는 것으로 부터 또는 개별적으로 빠른 테스트를 실
행하는 것으로 부터 벗어나려면 , 소프트웨어 개발 주기에서 반복적으로 실행할
수 있는 테스트의 사용자화 계열을 포함한 테스트 도구모음을 생성하면 된다 .
새 테스트 도구모음을 생성하기 위해서는 워크스테이션 서버의 테스트 메뉴 상
태에 있는 테스트 도구모음 편집기를 사용하여 생성한다 . 테스트 도구모음 편집
기는 그래픽 도구로서 도구모음에 있는 테스트를 편리하게 선택할 수 있게 하여
준다 . 테스트 키트 도구 모음 (.tks) 의 형식에서 테스트 도구모음 정의 를 내보
내기 할 수 있고 , 모든 워크스테이션 서버 응용프로그램이 테스트의 같은 세트를
학습 3 : CETK 를 사용하여 시스템 테스트하기 177
실행하기 위하여 이 파일들을 추가 개발 컴퓨터로 가져오기 할 수 있다 . 이 .tks
파일들은 테스트 정의 아카이브를 위하여 기준으로 제공된다 .
기본 테스트 사용자화하기 (Customizing Default Tests)그래픽 사용자 인터페이스는 커맨드라인을 사용자화 함으로서 , 워크스테이션 서
버 응용프로그램이 테스트를 실행하기 위하여 테스트 엔진 (Tux.exe) 으로 전송
한다 . 테스트의 매개변수를 수정 하기 위해서는 , 테스트 목록안에 테스트를 오
른쪽 마우스 버튼으로 클릭하고 , 수정 명령 옵션 (Edit Command Line option) 을
선택한다. 예를들면, 저장 장치 블럭 드라이버 벤치마크 테스트(Storage Device
Block Driver Benchmark Test) 는 장치의 모든 섹터에 데이터를 읽고 쓰기 함
으로서 저장 장치의 성능을 분석한다 . 이 의미는 저장 장치에 현존하는 모든 데
이터를 지워버릴 수 있다는 것을 의미한다 . 데이터를 읽어버리는 것을 방지하기
위해서는 , 저장 장치 블럭 드라이버 벤치마크 테스트는 기본 테스트를 건너뛴다
. 저장 장치 블럭 드라이버 벤치마크 테스트를 성공적으로 실행하기 위해서는 커
맨드라인 수정과 특수 매개변수인 -zorch 를 명시적으로 추가하여야 한다 .
지윈되는 커맨드라인 매개변수는 개개의 CETK 테스트 구현에 의존한다 . 테스
트는 여러개의 구성 매개변수를 필요로 하거나 지윈할 수 도 있는데 , 테스트를
위한 장치 드라이버를 인식하기 위한 색인 번호나 또는 테스트를 실행하기 위한
추가 등이다 .
참고 CETK 테스트를 위한 커맨드라인 매개변수
커맨드라인 매개변수와 같은 CETK 테스트의 모든 목록의 추가정보를 위해서는 , MICROSOFT MSDN 웹사이트의 http://msdn2.microsoft.com/en-us/library/ms893193.aspx , 윈도우 임베디드 CE 6.0 문서에 있는 “CETK 테스트”를 참조하라 .
수동으로 Clientside.exe 실행하기
만일 런타임 이미지에윈도우 임베디드 CE 테스트 키트 목록 항목을 포함 시켰거
나 , 워크스테이션과 서버와 함께 CETK 컴포넌트를 다운로드 하였거나 , 파일 뷰
어 윈격 도구를 사용하여 개발 워크스테이션에서 컴포넌트를 내보내기를 하거나 ,
Clientside.exe 를 타겟장치 상에서 시작하여 워크스테이션 서버에 수동으로 연결
을 설치한다 . 만일 , 타겟장치가 이 목적을 위하여 실행 대화상자를 제공하지 않
을 경우 , 플랫폼 빌더 IDE (Platform Builder IDE) 에서 대상 메뉴를 열고 , 프로
그램 실행을 선택한 후 , Clientside.exe 를 선택한 다음 실행을 선택한다 .
Clientside.exe 는 특정 워크 스테이션 서버 응용프로그램에 연결 하거나 , 설치
된 드라이버를 감지하고 , 자동으로 테스트를 실행하도록 다음과 같은 매개변수
를 지윈한다 .
178 제 4장 디버깅 및 시스템 테스트
Clientside.exe [/i=<Server IP Address> | /n=<Server Name>] [/p=<Server Port Number>] [/a]
[/s] [/d] [/x]
Wcetk.txt file 또는 HKEY_LOCAL_MACHINE/Software/Microsoft/CETT 레
지스트리 키에서 이 매개변수를 정의 할 수 있는 것을 아는 것이 중요한데 , 그럼
으로 명령을 매개변수없이 Clientside.exe 로 시작 할 수 잇다 . 이 경우 ,
Clientside.exe 는 루트 디렉터리에서 Wcetk.txt 를 검색한 후 , 타겟 장치상의 윈
도우 디렉터리에서 검색한 후 , 개발 워크스테이션상에서 디렉터리를 릴리스 한
다 . 만일 , Wcetk.txt 가 이 위치상에서 존재하지 않는다면 , CETT 레지스트리
키를 검색한다 . 표 4-5 는 Clientside.exe 매개변수를 요약한 것이다 .
표 4-5 Clientside.exe 시작 매개변수
Command
Line
Wcetk.txt CETT Registry Key Description
/n SERVERNAME ServerName (REG_SZ)
호스트 서버 이름 지정 . /i 를 동시에 사용 못 함 과 해상도를 위한 . 시스템 도메인 이름 (DNS) 필요
/i SERVERIP ServerIP (REG_SZ) 호스트 IP 주소 지정 /n/i 를 동시에 사용하지 못 함
/p PORTNUMBER PortNumber (REG_DWORD)
워크스테이션 서버 인테페이스로 구성 할 수 있는 서버 포트 지정 .
/a AUTORUN Autorun (REG_SZ) (1) 로 설정되면 , 연결이 설치된 후 장치는 자동으로 테스트를 시작한다
/s DEFAULTSUITE DefaultSuite (REG_SZ)
실행하기 위한 기본 테스트 도구모음의 이름을 지정
/x AUTOEXIT Autoexit (REG_SZ) (1) 로 설정되면 , 테스트가 완료되면 응용프로그램은 자동으로 종료된다 .
/d DRIVERDETECT DriverDetect (REG_SZ)
(0) 로 설정되면 장치의 드라이버 감지는 비활성화 된다 .
학습 3 : CETK 를 사용하여 시스템 테스트하기 179
독립 모드에서 CETK 테스트 실행Clientside.exe 는 개발 워크스테이션에서 CETest.exe 로 연결되며 , 연결을 사
용할 수 없는 장치에서 유용하게 CETK 테스트를 연결없이 실행 할 수 있도록
하여준다 . 만일 , 런타임 이미지에윈도우 임베디드 CE 테스트 키트 카탈로그 항
목을 포함 시키려고 하면 , 로그 파일에서 테스트 결과를 추적 할 수 있는 Kato
로깅 엔진 (Kato.exe) 을 암시적으로 시작할 수 있도록 테스트 엔진 (Tux.exe)
을 시작한다 . 예를들면 , 마우스 테스트 (mousetest.dll) 를 실행하고 결과를
test_results.log 라는 파일에서 추적하기 위해서는 다음과 같은 커맨드라인을
사용 할 수있다 .
Tux.exe -o -d mousetest -f test_results.log
참고 Tux 커맨드 라인 매개변수
TUX.EXE 커맨드라인 매개변수를의 모든 목록을 위해서는 MICROSOFT MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa934656.aspx 의 윈도우 임베디드 CE 6.0 문서에 있는“TUX커맨드라인 매개변수” 섹션을 참조 한다 .
사용자화된 CETK 도구 테스트 솔루션 생성하기CETK 은 여러 테스트를 포함하고 있는데 , 기본 테스트는 테스팅에 필요한 모든
사항을 내포하고 있지는 않다 . 특별히 사용자화된 장치 드라이버를 BSP 에 추
가하려면 , 사용자화된 장치 드라이버를 위한 사용자 - 정의된 테스트를 구현하
는 옵션을 제공하기 위해서는 CETK 는 Tux 프레임워크에 의존한다 . 플랫폼
빌더는 몇 번의 마우스 클릭으로 골격 Tux 모듈을 생성하기위한 WCE TUX DLL
템플릿을 포함하고 있다 . 드라이버를 실행하기 위해서 로직 (logic) 을 구현 할
때 , 현재의 테스트 구현의 소스 코드를 컴토하여 보는 것이 용이하다 . CETK 는
소스코드를 포함하는데 , 윈도우 임베디드 CE 공유 소스 (Shared Source) 를 위
한 설정 마법사에서 윈도우 임베디드 CE 공유 소스의 일부분으로 설치 할 수있
다 . 기본값은 %_WINCEROOT%₩Private₩Test 이다 .
사용자화된 Tux 모듈 생성하기Tux 프레임워크에 반응하는 사용자화된 테스트를 생성 하려면 , 런타임 이미지
의 OS 설계에 하위프로젝트를 추가 함으로서 윈도우 임베디드 CE 하위프로젝
트를 시작하고 WCE TUX DLL 템플릿을 선택한다 . 이 것으로 말미암아 Tux
마법사는 드라이버가 요구하는 골격을 생성하는데 사용자화 할 수있다 .
골격 Tux 모듈을 사용자화 하기위해서는 다음과 같은 파일들을 편집하여야만
한다 .
180 제 4장 디버깅 및 시스템 테스트
■ 헤더 파일 Ft.h 한 개의 함수 표 헤더와 함수 표 입력을 포함한 TUX
Function Table (TFT) 를 정의한다 . 테스트 로직을 포함한 함수 표는 함
수의 테스트 ID 와 연결한다 .
■ 소스 코드 파일Test.cpp 테스트 함수를 포함한다. 골격 Tux모듈은사용자
화된 테스트를 Tux DLL 에 추가 할 수 있는 단일 TestProc 를 포함한다 .
사용자화된 드라이버를 로드하거나 실행하기 , Kato 를 통하여 로그 작업 ,
테스트가 완료 되었을 때 Tux 테스트 엔진에 적절한 상태 코드를 반환 하기
위해서 샘플 코드로 변경한다 .
CETK 테스트 응용프로그램에서 사용자화 테스트 정의하기 골격 Tux 모듈은 완전 작동되며 , 코드 수정없이도 솔루션을 컴파일 하거나 런타
임 이미지를 빌드 할 수 있다 . 타겟 장치에서 새 테스트 함수 ( 기능 ) 를 실행하
기위해서는 , CETK 워크스테이션 서버 응용프로그램에서 사용자 - 정의된 테스
트를 구성하여야 한다 . 이 목적을 위하여 , 테스트 메뉴에서 사용자 정의된 명령
을 클릭함으로서 시작할 수 있도록 CETK 는 사용자 - 정의된 테스트 마법사를
포함한다 . 그림 4-12 는 골격 Tux 모듈을 실행하기 위하여 사용자 - 정의된 테
스트 마법사를 구성하는 것을 보여준 것이다 .
그림 4-12 사용자 -정의된 테스트 마법사에서 사용자화된 테스트 구성하기
사용자화 테스트 디버깅하기Tux 테스트는 Tux DLLs 에서 코드와 로직 구현에 의존함으로 테스트 코드를 디
버그 할 필요가 있다 . 한 가지 문제점을 집고 넘어가야 할 것은 테스트 루틴에
학습 3 : CETK 를 사용하여 시스템 테스트하기 181
서 중단점을 설정 할 수 있으나 , 코드 실행이 중단점을 멈추게 할 경우 , 워크스
테이션 서버 응용프로그램 (CETest.exe) 과 클라이언트 쪽 응용프로그램
(Clientside.exe) 사이의 연결을 잃어 버리게 된다 . 중단점 대신 디버그를 사용
하는 것을 고려 해볼 필요가 있는데 , 만일 , 디버깅 하는 동안 중단점을 꼭 사용
하여야 한다면 , 이 학습에서 언급한 바와 같이 타겟 장치상에서 독립모드
(Clientside.exe) 를 실행한다 . 오른쪽 마우스 버튼을 클릭한 다음 커맨드라인 편
집 (Edit Command Line ) 을 선택함으로 워크스테이션 서버 응용프로그램에서
필요한 커맨드라인을 표시할 수 있다 .
CETK 테스트 결과 분석하기CETK 는 골격 Tux 모듈에서 보여준것과 같이 , Kato 를 사용하여 테스트 결과
를 로그 하여야 한다 .
g_pKato->Log(LOG_COMMENT, TEXT("This test is not yet implemented."));
워크스테이션 서버 응용프로그램은 Clientside.exe 를 통하여 이 로그들을 자동
적으로 재개하며 , 개발 워크스테이션에 저장 할 수 있다 . 다른 도구를 사용하여
이 로그 파일들을 액세스 할 수 있다 . 예를들면 , 독립모드에서 CETK 을 사용한
다고 하면 , 파일 보기 윈격 도구를 사용하여 개발 워크스테이션에 로그파일을 가
져오기 할 수 있다 .
그렘 4-13 에서 서술한 것과 같이 CETK 는 C:₩Program Files₩Microsoft
Platform Builder₩6.00₩Cepb₩Wcetk 폴더에 위치한 가져오기 로그 파일을
편리하게 보기위한 일반 CETK 파서 (Cetkpar.exe) 를 포함한다 . 일반적으로 ,
이 파서는 워크스테이션 서버 응용프로그램에서 오른쪽 마우스 버튼을 클릭하고
결과 보기를 선택함으로서 시작 하거나 직접 Cetkpar.exe 를 실행하여 시작 할
수 있다 . PerfLog.dll 에 기반을 둔 특정한 성능 테스트는 쉼표로 구분된 값 (CSV)
의 형식으로 파스 할 수있으며 , 성능 테이타를 요약하기 위하여 스프레드시트에
연다 .
이 목적을 위하여 , CETK 는 한 개의 PerfToCsv 파서 도구를 포함하며 , 특수
분석 시나리오를 위하여 사용자화된 파서를 개발 할 수도 있다 . Kato 로그 파일
은 일반 문자 형식을 사용 한다 .
182 제 4장 디버깅 및 시스템 테스트
그림 4-13 CETK 테스트 결과 분석
학습 요약윈도우 임베디드 CE 테스트 키트는 확장 할 수 있는 도구로서 , 타겟 장치상에서
드라이버와 응용프로그램을 연결 모드와 독립모드에서 테스트 할 수 있게 하여
준다 . 만일 , 타겟장치가 KITL, ActiveSync, 또는 TCP/IP 연결을 지윈하지 않
을 경우 , 독립 모드에서 CETK 도구를 실행하는 것이 매우 용이하다 . 대개 , 일
반적으로 , 개발자는 타겟장치의 BSP 에 테스트 드라이버를 추가하기 위하여
CETK 를 사용한다 .
CETK 는 Tux 테스트 엔진에 의존하는데 , 이 것은 모든 테스트 DLLs 의 공통
후레임워크를 지윈한다 . Tux DLLs 은 실제의 테스팅 로직을 내포하며 , 타겟장
치에서 로드하거나 드라이버를 실행한다 . Tux DLLs 은 로그 파일에서 테스트
의 결과를 추적하기 위하여 Kato 와 인터페이스 하는데 , 사용자화된 파서나 스
프래드시트와 같은 다른 도구에서 진행하거나 , CETK 테스트 응용프로그램에서
직접 액세스 할 수 있다 .
학습 4: 부트 로더 (Boot Loader) 테스트하기 183
학습 4: 부트 로더 (Boot Loader) 테스트하기부트 로더의 일반 작업은 메모리에 커널이 로드한 후 , 장치가 전윈이 켜진 후에
OS 시작 루틴을 호출 하는 것이다 . 특별히윈도우 임베디드 CE 상에서 부트 로
더는 BSP(Board Support Package) 의 일부분일부분이며 , 핵심 하드웨어 플랫
폼 , 런타임 이미지 다운로드 , 커널 시작등을 초기화하는 것을 관리한다 . 최종
제품에 부트 로더를 포함하거나 런타임 이미지에 부트 스트랩을 하지 출시한다
해도 , 부트 로더는 개발 주기중 유용하게 쓰일 수 있다 . 또 다른 바로는 , 부트 로
더는 복잡한 런타임 이미지의 배포를 간단히 하는데 도움을 줄 수도 있다 . 부트
로더는 이더넷 , 시리얼 케이블 , DMA, 또는 USB 연결로 런타임 이미지를 다운
로드 할 수있도록 개발자의 컴퓨터를 연결함으로 개발시간을 절약 하게 하여주
는 편리한 기능이다 . 윈도우 임베디드 CE 6.0 을 위한 플랫폼 빌더에 포함된 소
스 코드를 기반으로 하여 새 하드웨어 기능을 지윈하기위한 사용화된 부트 로더
를 개발 할 수 있다 . 예를들면 , 부트 로더를 사용하여 런타임 이미지를 RAM 으
로 부터 플래시 메모리로 복사 할 수 있으며 , 이 방법은 또 다른 플래시그림 메
모리 프로그래머나 IEEE 1149.1- 호환 테스트 액세스 포트와 영역 - 스캔 기술
을 필요로하지 않는다 . 그러나 , 디버깅과 테스트 부트 로더는 복잡한 작업을 하
는데 , 커널이 로드되기 전에 실행되는 코드를 작업하기 때문이다 .
이 학습을 마친 후 , 다음과 같은 것을 실행 할 수 있다 .
■ CE 부트 로더 아키텍처 설명 .
■ 부트 로더를 위한 공용 디버깅 기술 나열 .
에상 학습 시간 : 15 분 .
CE 부트 로더 아키텍처 (Boot Loader Architecture)모호한 부트 로더에 관한 기능을 굳이 나열하자면 , 부트 로더는 직선 , 기억장치
의 불휘발성 (nonvolatile), CPU- 액세스할 수 있는 메모리에서 pre-boot 루틴
과 함께 작은 프로그램을 Bootstrap 하는 것이다 . 메모리 주소의 타겟 장치에서
부트 로더 이미지 설치는보드 제작사가 제공하는 JTAG 프로브에 의하여 설치되
어 있는 모니터 프로그램을 통하여 CPU 는 코드를 불러오기 시작하고 , 부트 로
더는 전윈을 켜거나 시스템을 재 설정 할때 실행 된다 . 일반적으로 부트 로더 작
업은 이 단계에서 Central Processing Unit (CPU) 를 초기화 , 메모리 제어기 ,
시스템 시계 , Universal Asynchronous Receiver/Transmitters (UARTs), 이
더넷 제어기 , 사용 가능한 다른 하드웨어 장치 , 런타임 이미지 다운로딩과 이것
을 바이너리 이미지 빌더 (BIB) 레이아웃에 의하여 RAM 에 런타임 이미지를 복
사 , 하는 것과 StartUp 함수 ( 기능 ) 로 커너 뛰는 것을하는 것을 포함 한다 . 마
184 제 4장 디버깅 및 시스템 테스트
지막 런타임 이미지는 기록은 이 기능 ( 함수 ) 의 시작 주소를 포함한다 . StartUp
함수는 커널 초기화 루틴을 호출 함으로서 부트 프로세스를 계속 진행한다 .
그림 4-14 에서 서술한 바와 같이 여러 부트 로더가 실행하는 작업 과 복잡한 다
른 작업을 이행 함에 도 불구하고 , 부트 로더 개발을 용이하게 하기 위하여 공통
적인 특성을 윈도우 임베디드 CE 가 정적인 라이브러리에서 커버한다 . 부트 로
더의 아키텍처에 관한 영향은 어떻게 부트 로더 코드를 디버그 하느냐에 달려있
다 . 부트 로더 개발에 관한 자세한 사항은 제 5 장 , “보드 지윈 팩키지 사용자
화 하기” 에서 찾아 볼 수 있다 .
그림 4-14 윈도우 임베디드 CE 부트 로더 아키텍처
윈도우 임베디드 CE 부트 로더는 다음과 같은 코드 부분과 라이브러리에 아키
텍처 기반을 두고 있다 .
■ BLCOMMON 빠른 실행을 위하여 플래시 메모리에서 RAM으로 부트 로더
를 복사하기 , 이미지파일 내용 디코딩하기 , checksums 를 확인하기 , 로드
진행을 추적하기 위한 기본 부트 로더를 구현 . BLCOMMON 는 지정된 하
드웨어 사용자화를 처리하기 위하여 잘 정의된 OEM 함수를 진행토록 호출
한다 .
■ OEM code 이 코드는 BLCOMMON 라이브러리를 지윈하기 위하여 , 하드
웨어 플랫폼을 구현하여야 한다 .
■ Eboot 이더넷 연결을 통해 런타임 이미지를 다운로드 할 수 있는
Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer
Protocol (TFTP), 과 User Datagram Protocol (UDP) 서비스를 제공한다.
■ Bootpart 부트 로더가 바이너리 ROM 이미지 파일 시스템 (BinFS) 분할을
생성하고 같은 저장 장치에서 다른 파일 시스템 분할을 할 수 있는 저장 분
할 루틴을 제공한다 . Bootpart 역시 부트 매개변수를 저장하기 위한 부트
분할을 생성할 수 있다 .
학습 4: 부트 로더 (Boot Loader) 테스트하기 185
■ Network drivers 기본 설치를 캡술화하여 여러 일반 네트워크 제어 장치
의 프리미티브 (primitives) 를 액세스할 수 있다 . 라이브러리를 위한 인터
페이스는 일반 인터페이스인데 , 그럼으로 , 부트 로더와 OS 는 인터페이스
를 사용 할 수 있다 . 부트 로더는 런타임 이미지를 다운로드 하기 위하여 인
터페이스를 사용하고 OS 는 인터페이스를 사용하여 플랫폼 빌더에 KITL 연
결을 구현한다 .
부트 로더를 위한 디버깅 기술부트 로더는 일반적으로 두 개의 구분된 부분으로 구성되어 있다 . 처음 부분은
어셈블리 언어로 되어있고 C 언어로 쓰여있는 두 번째 부분으로 건너뛰기 전에
시스템을 설치한다 . 만일 , 4-14 에서 서술한 바와 같이 BLCOMMON- 에 기반
을 둔 아키텍처를 사용한다면 , 어셈블리 코드를 디버그 할 필요는 없다 . 만일 장
치가 UART 를 장착하고 있으면 , C 코드에서리테일 MSG 매크로를 사용하여
테이타를 시리얼 출력 인터페이스를 사용하여 사용자가 표시 할 수 있도록 전송
할 수 있다 .
경우에 따라서 어셈블리 또는 C 코드를 디버그 하기위해서는 , 다음과 같은 서로
다른 디버깅 기술이 사용 가능하다 .
■ Assembly code 처음 시작 코드를 위한 일반 디버깅 기술은 LEDs 에 의존
하는데 , 시리얼 통신 인터페이스를 위한 7- 세그먼트 LEDs 와 UARTs 디
버깅 보드와 같은 것에 의존 하는데 , 왜냐하면 상대적으로 간단하게 일반 목
적 입력 / 출력 (General Purpose Input/Output (GPIO)) 를 액세스 할 수 있
고 , 한 개의 입력 / 출력 줄의 상태를 등록 하거나 수정 할 수 있기때문이다 .
■ C Code C-코드 수준에서 디버깅은 훨씬 쉬운데, 왜냐하면, 사용자는 고급
통신 인터페이스와 디버깅 매크로를 액세스 할 수 있기때문이다 .
■ Assembly and C code 만일 하드웨어 디버그 (JTAG probe) 가 사용 가능
되어있으면 , 플랫폼 빌더를 사용하여 eXDI 드라이버와 접속함으로서 부트
로더를 디버그 할 수 있다 .
시험 팁
인증 시험에 합격하기 위해서는 , 부트로더 , 커널 , 장치 드라이버 , 응용프로그램을 디버그하는 여러가지 기술들을 알아야한다 .
186 제 4장 디버깅 및 시스템 테스트
학습 요약부트 로더를 디버깅 하는 것은 매우 복잡한 작업이므로 , 하드웨어 플랫폼에 관하
여 깊은 이해가 필요하다 . 만일 , 하드웨어 디버그가 사용이 가능하다면 , 하드
웨어지윈 디버깅을 위하여 eXDI 와 함께 플랫폼 빌더를 사용 할 수 있다 . 그렇
지 않으면 , C 코드에서 시리얼 통신 인터페이스를 통해 디버깅 어셈블리 코드와
C 스타일 매크로의 디버그 메시지를 출력하기 위하여 LED 보드를 사용하는 것
을 고려해 보는 것도 좋을 것이다 .
학습 4: KITL, Debug Zones, 와 CETK 도구를 사용하여 시스템 디버깅과 테스팅하기 187
학습 4: KITL, Debug Zones, 와 CETK 도구를 사용하여 시스템 디버깅과 테스팅하기
이 학습에서 , Device Emulator BSP 상에 있는 OS 디자인에 디버그 콘솔 응용
프로그램을 하위프로젝트로 추가한다 . 디버깅을 사용하기 위해서는 , 런타임 이
미지에 KdStub 와 KITL 를 포함 시키고 , 해당 타겟 장치 연결 옵션을 설정한다 .
디버그 영역을 지윈하기 위한 구현을 위해 콘솔 응용프로그램의 소스 코드를 수
정하고 , Pegasus 레지스트리 키에서 유용하게 실행 할 수 있는 디버그 영역을
지정하고 , 비주얼 스튜디오 의 출력 창에 서 디버그 메시지를 검토하기 위하여
커널 디버거를로 타겟 장치에 연결한다 . 후 반에는 , CETK 를 사용하여 런타임
이미지에 포함되어 있는 마우스 드라이버를 테스트 한다 . 비주얼 스튜디오 에
서 기본 OS 디자인을 생성하기 위해서는 , 학습 1 에 요약되어 있는 “OS 디자인
생성 , 구성 , 빌딩” 의 프로세스를 따라한다 .
참고 상세한 단계별 지침
이 학습에서 보여준 진행을 성공적으로 습득하기 위해서는 이 책의 부록 “학습 4 를 위한 상세한단계별 지침” 문서를 참조하라 .
� KITL 활성화와 디버그 영역 사용하기
1. 학습 1에서비주얼 스튜디오 에서 생성한 OS design project를 연 후, OS 디
자인 속성을 편집하기 위하여 OSDesign 이름을 마우스의 오른쪽 버튼으로
클릭하고 Properties 를 선택한다 . 구성된 Properties 를 선택한 후 옵션을
빌드한다 . 런타임 이미지를 위한 Enable KITL 확인란을 선택한다 .
2. OS 디자인 속성 페이지대화 상자에서 커널 디버거 기능을 활성화 하고 , 변
경을 적용하고 대화 상자를 닫는다 .
3. 현재의 디버그 빌드 구성 작업에서 이전의 단계에서 유효화한 커널 디버거
와 KITL 컴포넌트가 빌드 이미지에 포함 되어있는지 확인한다 .
4. 빌드 메뉴에서 고급 빌드 명령 (Advanced Build Commands) 아래있는 현
재 BSP 재 빌드 (Rebuild Current BSP) 와 하위프로젝트를 선택하여 OS
디자인을 빌드한다 ( 만일 다음 단계에서 오류가 발생 할 경우 Clean Sysgen
를 실행한다 ).
5. 대상 메뉴를 열고 타겟장치 연결 옵션 대화상자를 표시하기 위한 연결 옵션
을 클릭한다 . 다음과 같은 설정을 한 후 확인을 클릭한다 .
188 제 4장 디버깅 및 시스템 테스트
6. 하위프로젝트를 OS 디자인에 추가 한 후 WCE 컨솔 응용프로그램 템플릿
(WCE Console Application template) 을 선택한다 . 프로젝트를
TestDbgZones 로 명명한 후 하위프로젝트 마법사에 있는” A Typical
Hello World Application” 옵션을 선택한다 .
7. 하위프로젝트에 새로운 헤더 파일 DbgZone.h 를 추가한 후 다음과 같은 영
역을 정의한다 .
#include <DBGAPI.H>
#define DEBUGMASK(n) (0x00000001<<n)
#define MASK_INIT DEBUGMASK(0)
#define MASK_DEINIT DEBUGMASK(1)
#define MASK_ON DEBUGMASK(2)
#define MASK_ZONE3 DEBUGMASK(3)
#define MASK_ZONE4 DEBUGMASK(4)
#define MASK_ZONE5 DEBUGMASK(5)
#define MASK_ZONE6 DEBUGMASK(6)
#define MASK_ZONE7 DEBUGMASK(7)
#define MASK_ZONE8 DEBUGMASK(8)
#define MASK_ZONE9 DEBUGMASK(9)
#define MASK_ZONE10 DEBUGMASK(10)
#define MASK_ZONE11 DEBUGMASK(11)
#define MASK_ZONE12 DEBUGMASK(12)
#define MASK_FAILURE DEBUGMASK(13)
#define MASK_WARNING DEBUGMASK(14)
#define MASK_ERROR DEBUGMASK(15)
#define ZONE_INIT DEBUGZONE(0)
#define ZONE_DEINIT DEBUGZONE(1)
#define ZONE_ON DEBUGZONE(2)
#define ZONE_3 DEBUGZONE(3)
#define ZONE_4 DEBUGZONE(4)
#define ZONE_5 DEBUGZONE(5)
#define ZONE_6 DEBUGZONE(6)
#define ZONE_7 DEBUGZONE(7)
#define ZONE_8 DEBUGZONE(8)
#define ZONE_9 DEBUGZONE(9)
#define ZONE_10 DEBUGZONE(10)
#define ZONE_11 DEBUGZONE(11)
#define ZONE_12 DEBUGZONE(12)
#define ZONE_FAILURE DEBUGZONE(13)
매개변수 구성 설정
Download Device Emulator (DMA)
Transport Device Emulator (DMA)
Debugger KdStub
학습 4: KITL, Debug Zones, 와 CETK 도구를 사용하여 시스템 디버깅과 테스팅하기 189
#define ZONE_WARNING DEBUGZONE(14)
#define ZONE_ERROR DEBUGZONE(15)
8. TestDbgZones.c 파일의 include 에 DbgZone.h 헤더 구문을 추가 한다 .
#include "DbgZone.h"
9. 다음과 같이 _tmain 함수위의 디버그 영역을 위한 dpCurSettings 변수를
정의한다 .
DBGPARAM dpCurSettings =
{
TEXT("TestDbgZone"),
{
TEXT("Init"), TEXT("Deinit"), TEXT("On"), TEXT("n/a"),
TEXT("n/a"), TEXT("n/a"), TEXT("n/a"), TEXT("n/a"),
TEXT("n/a"), TEXT("n/a"), TEXT("n/a"), TEXT("n/a"),
TEXT("n/a"), TEXT("Failure"), TEXT("Warning"), TEXT("Error")
},
MASK_INIT | MASK_ON | MASK_ERROR
};
10. _tmain 함수의 첫 줄에 모듈의 디버그 영역을 등록한다 .
DEBUGREGISTER(NULL);
11. 리테일 MSG 와 DEBUGMSG 매크로를 사용하여 다음과 같이 디버그 영역
과 연결 하고 디버그 메시지를 표시한다 .
DEBUGMSG(ZONE_INIT,
(TEXT("Message : ZONE_INIT")));
³ÆÝÞ¿œMSG(ZONE_FAILURE || ZONE_WARNING,
(TEXT("Message : ZONE_FAILURE || ZONE_WARNING")));
DEBUGMSG(ZONE_DEINIT && ZONE_ON,
(TEXT("Message : ZONE_DEINIT && ZONE_ON")));
12. 응용프로그램을 빌드하고 , 타겟 장치에 연결한 다음 , 타겟 제어 창을 사용하
여 응용프로그램을 시작한다 .
13. 디버그 출력 창에서는 첫 디버그 메시지만 표시된다는 것을 명심 하여야한
다 .
4294890680 PID:3c50002 TID:3c60002 Message : ZONE_INIT
14. 남아있는 디버그 영역을 기본값으로 활성화하기 위하여 레지스트리 편집기
(Regedit.exe) 를 연다 .
15. HKEY_CURRENT_USER₩Pegasus₩Zones 키를 열고 REG_DWORD 값
을 생성하여 TestDbgZone(dpCurSettings 변수에서 모듈의 이름을 정의 )
를 호출한다 .
190 제 4장 디버깅 및 시스템 테스트
16. 32 비트 DWORD 값의 낮은 16 비트와 일치하는 16 개의 명명된 영역의 값
을 0xFFFF 값으로 설정하여 활성화한다 . ( 그림 re 4-15 참조 ).
17. 비주얼 스튜디오에서 , 응용프로그램을 재 실행하면 다음과 같은 출력을 볼
수 있다 .
4294911331 PID:2270006 TID:2280006 Message : ZONE_INIT
4294911336 PID:2270006 TID:2280006 Message : ZONE_FAILURE || ZONE_WARNING
4294911336 PID:2270006 TID:2280006 Message : ZONE_DEINIT && ZONE_ON
18. 비주얼 스튜디오의 출력 창에서 결과를 확인하거나 , 다른 디버그 영역을 활
성화 하거나 비활성화 하기 위하여 레지스트리에서 TestDbgZone 값을 변
경한다 .
그림 4-15 HKEY_CURRENT_USER₩Pegasus₩Zones: "TestDbgZone"=dword:FFFF
참고 플랫폼 빌더에서 디버그 영역을 활성화와 비활성화 하기
플랫품 빌더에서 TestDbgZone 모듈을 위하여 디버그 영역을 제어 할 수는 없는데 왜냐하면 , 이 모듈을 위한 응용프로그램 진행은 유효한 영역을 열거나 수정하기전에종료되기 때문이다 . 유일하게 디버그 영역을 관리 할 수 있는 방법은 그래픽 응용프로그램이나 DLL 을 위하여 플랫폼 빌더에 모듈을 로드하는 것이다 .
학습 4: KITL, Debug Zones, 와 CETK 도구를 사용하여 시스템 디버깅과 테스팅하기 191
� CETK 를 사용하여 마우스 드라이버 테스트 실행하기
1. 개발 컴퓨터상에서 시작 메뉴로 부터 Windows CE 테스트 키트 응용프로그
램을 연다 . ( 윈도우 임베디드 CE 6.0 메뉴를 연 후윈도우 임베디드 CE 테
스트 키트를 클릭한다 ).
2. 윈도우 임베디드 CE 테스트 키트 창에서 , 연결 메뉴를 열고 타겟장치에 연
결을 설치하기 위하여 클라이언트 시작 (Start Client ) 을 클릭한다 .
3. 연결을 클릭한 후 연결 관리자 창에서 장치를 선택한다 .
4. 그림 4-16 에서 보는 바와 같이 장치에 워크스테이션 서버 응용프로그램이
성공적으로 연결 되는지 확인 , 필요한 CETK 바이너리를 배포 , 사용가능 한
장치 드라이버 감지 , 계층적 트리에서 모든 컴포넌트의 목록을 표시하는지
확인한다 .
5. Windows CE 테스트 목록 노드를 마우스의 오른쪽 버튼으로 클릭한 후 모
든 테스트 해제를 클릭한다 .
6. 목록에서 개개의 노드를 열고 마우스 테스트 확인란을 선택한다 .
7. 테스트 메뉴를 열고 시작 / 멈춤 테스트를 클릭 함으로서 마우스 테스트를 실
행한다 .
8. 타겟 장치상에서 필요한 마우스 동작을 선택한다 .
9. 테스트가 종료되었으면 테스트 입력을 마우스의 오른쪽 버튼을 클릭하고 결
과 보기를 선택함으로서 테스트의 보고서를 액세스 할 수 있다 .
10. CETK 파서에서 결과를 검토함으로서 , 성공을 알림 , 건너뛰기 , 테스트 프로
시저를 검토 할 수 있다 .
그림 4-16 윈도우 임베디드 CE 테스트 키트 창의 장치 목록
192 이 장의 복습
이 장의 복습윈도우 임베디드 CE 를 위한 플랫품 빌더는 디버깅을 쉽게 이해 할 수 있는 세트
와 도구를 제품을 릴리스 하기전에 최종 시스템 구성 확인과 에러를 유발 시키는
윈인을 분석하고 제거할 수 있는 테스팅 도구를 포함하고 있다 . 디버깅 도구는
비주얼 스튜디오 와 융합되어 KITL 연결을 통하여 타겟장치와 통신한다 . 다른
방법으로는 , 메모리 덤프 (memory dump) 를 생성하여 CE Dump File Reader
를 사용하여 오프라인 모드에서 시스템을 디버그 할 수 있고 , 특정한 사후 디버
깅을 할때 매우 유용하다디버깅 환경은 확장 할 수 있는데 , 그 의미는 eXDI 드라
이버가 표준 커널 디버거의 한계를 뛰어 넘어 하드웨어 지윈 디버깅을 실행하는
것이다 .
커널 디버거는 커널 컴포넌트와 응용프로그램을위한 혼합된 디버거이다 . 만일
KdStub 와 KITL 을 활성화 하여 타겟장치에 연결한다면 , 디버깅은 자동으로 시
작된다 . 사용자는 타겟 제어 창을 사용하여 디버깅과 CEDebugX 명령들을 기반
으로 하는 고급 시스템 테스트를 실행하는 응용프로그램을 시작 할 수 있다 . 그
러나 , 명심 하여야 할 것은 이 레벨로 인하여 중단 처리기 또는 OAL 모듈에서 중
단점을 설정 할 수 없거나 , 커널은 단일 - 스레드 모드로 작동하고 , 만일 코드 실
행이 멈춤으로 되면 , 개발 워크스테이션과의 통신을 멈춘다 . 중단 처리기를 디
버그하기 위해서는 , 하드웨어 디버거 또는 디버그 메시지들을 사용한다 . 디버그
메시지 기능은 런타임 이미지를 재 빌드하지 않고 정보 출력을 제어 할 수있도록
디버그 영역을 지윈한다 . 디버그 메시지를 사용하여 부트 로더에서 C- 코드 부
분을 역시 디버그 할 수 있으며 , 어셈블리 코드 부분은 반드시 하드웨어 디버거
나 LED 패널을 사용하여야 한다
CETK 테스트 응용프로그램을 기반으로 한 시스템 테스팅을 중앙 처리화 하기
윈한다면 KITL 을 필요로 하는데 , 그럼에도 불구하고 CETK 테스트는 독립 모
드에서도 실행이 가능하다 . 만일 타겟장치를 위한 고급 BSP 를 개발하려고 한
다면 , CETK 를 사용하여 사용자화된 Tux DLLs 에서 자동 또는 반 - 자동 컴포
넌트 테스트를 실행할 수 있다 . 플랫폼 빌더는 특정한 테스트에 필요한 확장을
할 수 있는 골격 Tux 모듈 을 생성 할 수있는 WCE TUX Dynamic-Link Library
템플릿을 포함한다 . 사용자는 CETK 테스트 응용프로그램에서 사용자화된 Tux
DLL 을 구성 할 수 있고 , 각기 테스트를 실행하거나 큰 테스트 모음의 일부분으
로 실 행 할 수 있다 . 왜냐하면 , 모든 CETK 테스트는 동일한 로깅 엔진과 로그
파일 형식을 사용하기 때문인데 , 사용자는 같은 파서 (Parser) 도구를 사용하여
기본값과 사용자 - 정의된 테스트를 분석할 수 있다 .
이 장의 복습 193
주요 용어이 주요 용어가 무슨 뚯인지 아십니까 - 이 책의 끝 부분에 있는 단어장에서 용
어를 찾아봄으로써 답안을 검토 할 수 있다 .
■ 디버그 영역 (Debug Zones )
■ KITL
■ 하드웨어 디버거 (Hardware debugger)
■ dpCurSettings
■ DebugX
■ 타겟 제어 (Target Control)
■ Tux
■ Kato
추천 연습이 과에서 보여준 시험 요소들을 성공적으로 마스터하기 위해서 다음과 같은 작
업을 하여보자 .
메모리 누수 감지하기메모리 블럭을 할당하고 해제하지 않음으로 메모리 누수를 야기시키는 컨솔 응
용프로그램을 위하여 하위프로젝트를 OS 디자인에 추가한다 . 이 과에서 사용된
툴들을 사용하여 문제를 발견하고 정정한다 .
사용자화된 CETK 테스트WCE TUX Dynamic-Link Library 를 위하여 OS 디자인에 하위프로젝트를 추
가한다 . 윈도우 임베디드 CE 테스트 키트에 Tux DLL 을 빌드하고 이 것을 등록
한다 . CETK 를 실행하고 테스트의 결과를 확인한다 . Tux DLL 에서 중단점을
설정하고 독립 실행에서 CETK 테스트를 실행함으로써 코드를 디버그 한다 .