Sankim's Blog : Tools

Easy Transfer를 이용한 XP에서 Windows 7으로 마이그레이션

sankim — Mon, 01 Jun 2009 10:15:00 GMT

이전 ‘윈도우 XP, Vista에서 윈도우7으로 업그레이드’에서 말씀 드린바 대로 오늘은 Easy Transfer를 이용해 XP에서 Windows 7으로 마이그레이션 하는 방법을 설명 드리겠습니다.

마이그레이션이란 이전 윈도우(XP, Vista)에 있던 설정이나 데이타를 새로운 H/W 혹은 운영체제(Windows 7)로 옮기는 작업이라고 말씀 드렸는데요, Easy Transfer을 이용하면 기본 윈도우 설정 정보는 물론이고 이전 컴퓨터에서 사용하던 데이타를 옮길 수 있습니다. 그러나 설치 되어 있는 응용프로그램은 옮길 수 없으므로 마이그레이션 전에 새로 설치 해야 합니다.

Easy Transfer에서 전송 가능한 파일과 설정

파일 및 폴더
전자 메일 설정
연락처 및 메시지
프로그램 설정
사용자 계정 및 설정
인터넷 설정 및 즐겨찾기
음악
그림 및 비디오

Easy Transfer는 컨셉은 간단합니다, Easy Transfer를 이용해 윈도우 XP의 설정과 하드디스크의 데이터를 전용 USB 케이블을 이용해 바로 새로운 컴퓨터로 옮기거나 아니면 설정과 데이타를 하나의 .MIG 파일로 만들어 USB 같은 하드디스크에 저장한 뒤 그 MIG 파일을 새 컴퓨터에 옮겨 Easy Transfer를 이용해 풀어 놓는 방법입니다. 단순하게 보면 백업&복구와 유사한 컨셉으로 볼 수 있지만 윈도우 설정이나 프로파일까지 그대로 옮길 수 있다는 것이 다릅니다.

Easy Transfer로 데이터를 옮기는 방법 3가지

Easy Transfer USB cable을 이용한 방법

: Old 컴퓨터(XP, Vista)와 New 컴퓨터(윈도우 7) 사이에 Easy Transfer USB cable을 연결해서 마이그레이션을 하는 방법입니다. 별도의 Easy Transfer USB cable이 있어야 하는 방법입니다.

[그림 1] Easy Transfer USB cable

Network를 이용한 방법

: Old 컴퓨터와 New 컴퓨터 사이 마이그레이션 할 데이타를 네트워크를 통해 전송하는 방법 입니다. Old 컴퓨터와 New 컴퓨터 모두 네트워크에 공존하고 있다면 간단하게 사용할 수 있는 방법입니다. 그러나 네트워크에 영향을 줄 수 있으므로

외장 하드디스크를 이용한 방법

: USB 메모리 혹은 디스크나 네트워크 공유를 이용해 직접 마이그레이션 할 파일을 저장했다가 새로 설치된 Windows 7에서 저장된 데이타를 풀어 놓는 방식 입니다.

[1] Windows XP에서 Easy Transfer 마이그레이션 실행 (외장 하드디스크를 이용한 방법)

*Easy Transfer를 실행하기 위해서는 Windows 7 설치 CD에 있는 Support\Migwiz 폴더에 가시면 migwiz.exe를 실행 합니다.

[그림 2, 왼쪽] migwiz.exe를 실행한 모습 [그림 3, 오른쪽] 마이그레이션 할 방법을 선택 할 수 있습니다. 여기서는 ‘외부 하드 디스크 또는 USB 플래시 드라이브’를 선택해 진행하도록 하겠습니다.

[그림 4, 오른쪽] 전송할 항목을 확인 합니다.

[그림 5, 오른쪽, 그림 6, 왼쪽] 아래 그림에서처럼 고급을 클릭하시면 필요한 파일폴더를 추가로 마이그레이션 항목에 추가할 수 있습니다.

[그림 7, 오른쪽] 보안을 위해 MIG파일을 이용하기 위한 암호를 설정 합니다. [그림 8, 왼쪽] 파일을 저장하고 나면 ‘파일 전송’이 완료 됩니다.

[2] Windows 7으로 마이그레이션

[그림 9, 오른쪽] 새로운 컴퓨터에서 마이그레이션 ‘This is my new computer’를 선택합니다. [그림 10, 왼쪽] 저장된 MIG 파일로 마이그레이션 작업을 ‘Yes’를 선택합니다.

[그림 11, 오른쪽] 새 컴퓨터에 옮길 계정과 파일들을 선택합니다 [그림 12, 왼쪽] 마이그레이션 중

[그림 13] 마이그레이션이 끝난 뒤 리포트를 볼 수 있습니다.

[그림 14] 로그 오프하고 나니 XP에 있던 계정들이 나타났습니다.

*그리고 작업 전에는 중요한 데이타 백업은 빼먹지 않는 센스~ :)

[참고문서]
Step-by-Step: Windows 7 Upgrade and Migration
http://technet.microsoft.com/en-us/library/dd446674.aspx

4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트

sankim — Thu, 21 May 2009 04:29:00 GMT

지난 ‘Windows 메모리 FAQ’에서 Windows 메모리에 대한 이야기를 드렸는데요, 특히 Windows 클라이언트의 4GB 제한에 대해서 여러분들의 아주 뜨거운(?) 반응이 있었습니다. 그래서 지난 번에 약속 드린 ‘Easy Transfer를 이용한 마이그레이션’은 다음 포스팅으로 미루고 오늘은 ‘4GB 제한의 진실, 32비트 Windows 클라이언트‘라는 주제로 Q&A 형식으로 이야기를 나누도록 하겠습니다.

Q1) 왜 Windows 클라이언트는 4GB까지만 지원하나요?

1. Windows XP가 처음 출시된 초기만 해도 4 기가 바이트(GB) 메모리라는 게 서버에서도 거의 사용되지 않는 고사양의 메모리였으므로 4GB를 이상 지원을 고려할 필요가 없었습니다. (당시는 일반적으로 사용하는 서버의 메모리가 512MB 혹은 그 이하였던 시절 이였습니다, 64MB 서버도… ^^)

2. Windows XP SP2가 출시될 시점에 윈도우 클라이언트도 4GB 메모리 필요성의 조짐이 보였습니다, 그래서 당시 Windows 개발팀에서는 윈도우 클라이언트에서 4GB 이상 메모리 지원을 검토하였습니다.

3. 그런데 윈도우 클라이언트에서 4GB 이상의 메모리를 관리(Memory Management)하면 블루스크린(Crash), 시스템 행(System Hang), 부팅이 되지 않거나 혹은 비디오 카드 같은 장치의 드라이버 문제로 장치를 인식하지 못하는 문제가 빈번하게 발생하는 것을 볼 수 있었습니다. (대부분 Memory corruption)

4. 원인은 윈도우 클라이언트를 위해 만들어진 3'rd Party 디바이스 장치 드라이버(Driver)가 4GB 이상 메모리 환경을 고려하지 않고 만들어졌기 때문에 발생한 문제였습니다.

5. 이런 장치 드라이버 호환성 문제를 피하기 위해 윈도우 클라이언트(XP, Vista, 7)에서는 4GB까지만 메모리 관리(Memory Management)를 할 수 있도록 한 것 입니다.

Q2) 4GB메모리가 전부 보이지(인식)되지 않고 3(.xx)GB 정도로 보여요, 왜 그런가요?

아래 그림은 제 Windows 7에서 시스템 정보(msinfo32.exe)를 실행시켜 얻을 결과입니다, 실제 설치된 메모리는 4GB지만 윈도우가 이용할 수 있는 실제 메모리는 3GB로 인식하고 있습니다.

하나 더 아래 그림은 작업 관리자에서 나타난 값입니다, 마찬가지로 실제 메모리를 3GB 정도만 인식하고 있는 것을 볼 수 있습니다.

결론부터 말씀 드리면 이 현상의 원인은 컴퓨터의 칩셋(Chipset)과 연결된 장치(비디오 카드, Lan 카드 같은)가 가지고 있는 메모리 때문에 실제 장착된 메모리보다 적게 나타나는 것입니다. 윈도우는 '실제 메모리'에 나타난 '전체' 크기 만큼의 메모리만 사용할 수 있므며(즉 위와 같은 경우에는 전체 4GB를 사용하지 못합니다) 이는 하드웨어 이슈 입니다. 이와 연관있는 디바이스 요소로는 System BIOS, Motherboard Resources (I/OxAPIC), Memory Mapped I/O, PCI Express Configuration Space, Additional PCI Device Memory (Graphics Aperture), VGA Memory 등이 있습니다.

[이유는 아래와 같습니다]

어려운 이야기가 될 수 있으니 쉬운 이해를 위해 먼저 아래 그림을 보시죠. 시스템이 시작할 때 Physical Address Map(이하 PAM)이라는 걸 만듭니다, PAM은 RAM과 각 장치들이 가지고 있는 메모리의 주소 정보로 일종의 '순서' 혹은 '차례'를 만들어 Windows에게 넘겨줍니다, 그러면 Windows는 PAM 범위의 메모리만 사용(Access) 할 수 있습니다.

그런데 PAM이 만들어 질때 메모리(RAM)만 가지고 만드는 것이 아니고 모든 종류의 장치가 가진 디바이스 메모리(비디오 카드, Lan 카드가 가지고 잇는 메모리를 칭함)까지 포함합니다, 처음에는 RAM만 가지고 PAM을 만들어 가다는 중간에 디바이스 메모리가 끼어들게 됩니다, 그러면 PAM 중간에 디바이스 메모리가 포함되고 다시 PAM에 추가되다만 나머지 RAM이 PAM에 추가 되는데 이때 추가된 RAM이 4GB 범위 밖에서 만들어집니다. x86 Standard Memory management Mode를 사용하는 32-bit Windows는 4GB 메모리 영역까지만 사용(Access) 할 수 있는데 디바이스 메모리 때문에 RAM이 4GB 범위 밖으로 밀려나 해당 범위의 메모리가 보이지 않게 되는 것입니다.

위 그림은 총 4GB메모리 환경에서 디바이스 메모리가 총 500MB이기 때문에 사용할 수 있는 총 메모리가 3.5GB로 줄어든 예입니다. 밀려난 500MB는 윈도우가 Access 할 수 없는 영역이기 때문에 사용할 수 없습니다. 이 이슈는 하드웨어에서 해결해야 할 이슈입니다. (이전에 사용한 '문제'라는 표현은 오해를 가져 올수 있어 '이슈'로 변경하였습니다, 여기서 하드웨어란 칩셋을 의미합니다 )

*참고로 32비트 Windows 서버 관련한 4GB 제한에 대한 이야기는 이전에 ‘누가 내 메모리를 훔쳤나?’라는 글로 포스팅한 적이 있습니다, 서버에 관심 있으신 분들은 참고로 읽어 보시기 바랍니다.

Q3) 정말 디바이스 장치들이 메모리 중간에 끼어 들어 메모리가 밀려났는지를 어떻게 해야 볼 수 있죠?

이전에 어떻게 해야 볼 수 있을까 고민 많이 했는데(디버거 봐야 하나.. 등등 ^^;) 의외로 장치 관리자(devmgmt.msc)에서 간단하게 보실 수 있었습니다. 아래 내용은 32비트 클라이언트뿐만 아니라 64비트와의 비교를 보여드리기 위해 제 테스트 머신에 듀얼 부팅으로 Windows Vista 32비트와 64비트를 설치해 테스트를 진행하였습니다.

32 비트 Windows 클라이언트

아래 그림은 32비트 Vista 작업 관리자(taskmgr.exe)에서 보이는 Physical Memory의 모습입니다, 4GB를 장착했지만 전체가 3.3GB정도가 나옵니다.

그렇다면 ‘작업 관리자’가 말하는 Windows가 실제 인식한 Physical Memory 범위는 어떤 모습일까요? 아래 그림은 Meminfo.exe를 이용하여 Windows가 실제 인식하는 Physical Memory 범위를 출력한 결과입니다. (meminfo는 전에 소개해 드렸던 Windows Internals 5’th Edition을 쓴 Alex Ionescu가 만들었습니다)

메모리를 표기할 때 16진수로 표현하고 이를 00000000~FFFFFFFF로(0MB에서 4GB)로 표현합니다. 위 결과를 보시면 Physical Memory 범위가 ‘00001000~0009F000’과 ‘00100000~CFDFF000’ 두 범위로 나눠져 있으며 대략 3.4GB 정도의 크기 입니다.

그럼 두 범위에 중간에 빠진 ‘0009F000~00100000’과’CFDFF000~FFFFFFFF’ 사이 영역은 왜 Windows에서 인식하지 못한 것 일까요? 앞에서 말씀 드렸듯이 디바이스가 해당 영역을 점유해 윈도우가 사용(Access)할 수 있는 메모리가 아니기 때문입니다.

디바이스가 점유한 모습은 ‘장치 관리자(devmgmt.msc)’를 통해 확인 하실 수 있습니다, ‘장치 관리자(devmgmt.msn) > 보기 > 리소스(연결별) > 메모리’를 선택합니다, 그러면 아래 그림과 같이 비디오 카드 Radeon X13000이 ‘D0000000~DFFFFFFF’(대략 268MB)과 ‘FE900000~FEAFFFFF’(대략 2MB) 영역, 즉 Physical Memory 범위에서 제외되었던 곳에 자리 잡고 있음을 확인 할 수 있습니다.

32비트에서는 4GB에서 밀려난 메모리를 볼 수 없습니다, 그럼 밀려난 나머지를 보기 위해 우리 64비트를 살펴보도록 하죠~

64비트 Windows 클라이언트

아래는 64비트 Vista 작업 관리자(taskmgr.exe)에서 보이는 Physical Memory의 모습입니다, 4GB 모두 보입니다.

Meminfo로 본 Physical Memory 범위입니다, 64비트라 Address 범위부터가 다르죠? Memory Address가 4GB를 넘고 메모리 또한 4GB 범위 모두 나타납니다.

장치 관리자에서 본 모습입니다.

32비트에서 본 것과 마찬가지로 위 빨간 박스의 부분은 268MB정도 되고 아래가 2MB정도가 됩니다. 중간에 비디오 카드가 끼어 들었지만 4GB 이후 주소인 '0000000100000000~000000012C000000(실제 메모리 5GB 쯤의 자리)'에서 나머지 720896KB(대략 720MB)를 인식한 것을 볼 수 있습니다. 즉 디바이스가 메모리를 4GB 영역 밖으로 밀어냈다고 해도 128GB까지 인식하는 64bit Addressing 때문에 문제없이 모든 Physical Memory가 보입니다.

처음에 드렸던 예로 이런 상황에서 64비트를 그림으로 표현 하면 아래와 같습니다.

Q4) 그럼 32비트 클라이언트가 4GB 이상을 사용(Access, Addressing)하려면 어떻게 해야 할까요?

정답은 32비트 클라이언트는 4GB 이상을 사용할 수 있는 방법이 없습니다, 4GB 이상 메모리의 사용이 필요하다면 64-bit Windows 클라이언트를 사용하십시오.

현재는 32-bit 환경에서 64-bit 환경으로 넘어가기 위해서는 우선 64비트로의 인식전환이 필요할 것입니다. 다음으로 64비트 전용 응용프로그램들이 많이 나와야 할 것 입니다, 32비트 응용프로그램을 에뮬레이션 하기 위한 WOW 64 Subsystem이 있기는 하지만 모든 응용프로그램에 호환성을 보장하지 않고 32비트 응용프로그램 구조상 64비트 Windows에서 실핼 할 때 64비트가 제공하는 무한(?)한 메모리를 이용할 수 없는 제한이 있습니다.

*64비트 윈도우와 응용프로그램에 대한 이야기는 예전에 포스팅 한 글이 있습니다, 읽어 보시고 추가적인 이해에 도움이 되셨으면 합니다.

Windows 64bit Computing에 대한 오해 혹은 잘못된 상식
http://blogs.technet.com/sankim/archive/2007/12/28/windows-64bit-computing.aspx

Q5) Windows XP를 보면 PAE를 지원하는데 이는 XP도 PAE를 사용하면 4GB 이상을 사용할 수 있다는 의미 아닌가요?

Windows XP SP2 부터 나온 DEP(Data Execution Prevention)를 사용하기 위해서는 기본적으로 PAE가 활성화(Enable)되어 있어야 합니다, 그래서 PAE 기능을 활성화 할 수 있도록 한 것입니다. 이는 Windows Kernel에서 32bit에서는 존재하지 않는 64bit PTE table의 field를 이용하기 때문입니다.

To use these processor features, the processor must be running in Physical Address Extension (PAE) mode. However, Windows will automatically enable PAE mode to support DEP. *해당 문서를 보시려면 여기를 클릭하세요.

참고로 PAE를 활성화 하는 경우와 반대의 경우 윈도우가 시작 시 로드하는 커널 파일은 아래와 같습니다.

CPU 수에 따른 환경	기본	PAE 활성
Uniprocess(단일 CPU)	Ntoskrnl.exe	Ntkrnlpa.exe
Multiprocess(다중 or 코어 CPU)	Ntkrnlmp.exe	Ntkrpamp.exe

Q6) 번 외 질문인데요, 도구마다 메모리 측정 결과가 각기 조금씩 다른 경우가 있어요 왜 그렇죠?

위 그림에서 작업관리자는 3.3인데 왜 meminfo는 3.4냐고 반문하실 수도 있습니다 또한 제가 종종 받는 질문 중 하나가 작업 관리자에서 ‘사용가능’ 항목과 성능 모니터에서 ‘Available %메모리%’의 값이 다르다는 것입니다. 이는 각 도구마다 메모리를 계산하기 위한 항목 수집 기준이 조금씩 달라서입니다, 크게 차이가 나는 것이 아니므로 이번 포스팅에서는 무시하셔도 좋습니다. 언제 작업 관리자에 나온 항목에 대한 자세한 설명을 드리겠습니다. (약속만 드리고 지키지 못하는 것들이 많지만 이번 약속은 꼭!!)

그럼 여러분 좋은 하루 되세요~

* 이전에 댓글에 추가로 명시 했습니다만 '장치 메모리', 혹은 'MMIO'라고만 명시 한것에 대해서 모호하다는 의견이 있어 본문 내용과 하단 부분에 함께 추가 합니다. ^^ 4GB 전체 사용하지 못하는 이슈에 영향을 끼치는 디바이스 요인으로 System BIOS, Motherboard Resources (I/OxAPIC), Memory Mapped I/O, PCI Express Configuration Space, Additional PCI Device Memory (Graphics Aperture), VGA Memory *등(헥헥헥..)이 있습니다. 그러나 말씀안드려도 이들 모두 '장치 메모리'의 범주 임을 알 수 있는 센스~!

[참고자료]
Pushing the Limits of Windows: Physical Memory, Written by Mark Russinovich *이번 포스팅의 대부분의 아이디어가 이 글에서 나왔습니다, 꼭 한번 읽어 보시기 바랍니다.
Windows Internals, Chapter 7 Memory Management
Intel 64 and IA-32 Architectures Software Developer’s Manual, Intel 64 and IA-32 Architectures

시스템 Live 상태에서 Memory dump 생성하기

sankim — Thu, 23 Oct 2008 08:48:23 GMT

시스템이 Live한 상태에서 liveKD를 이용하여 Memory dump를 생성하는 방법을 설명 드리겠습니다.

[1] 파일 다운로드

해당 작업을 하기 위해서는 Windbg를 다운 받아 설치합니다.

Install Debugging Tools for Windows 32-bit Version

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Install Debugging Tools for Windows 64-bit Version

http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx

공간이 충분한 하드디스크 드라이브에 symbols 폴더를 생성하여 주십시오.

예) d:\symbols

[2] LiveKD 설치

1. 첨부된 LiveKD를 Debugging Tools for Windows을 설치한 폴더에 압축 해제 후 복사.

2. CMD에서 Debugging Tools for Windows을 설치한 폴더로 이동 후 다음과 같은 명령어로 실행

livekd -y SRV*d:\symbols*http://msdl.microsoft.com/download/symbols

여기서 ‘d:\symbols’ 는 symbol을 다운 받을 경로입니다.

*위와 같이 LiveKD를 실행시켜놓은 상태로 놔두어야 합니다. LiveKD를 실행해둔 상태에서 서비스를 하다가 문제가 발생하면 ‘[3]덤프 생성하기’와 같은 방법으로 메모리 덤프를 생성합니다.

[3] 덤프 생성하기

3. LiveKD가 실행되고 나면 아래와 같이 입력하여 Dump를 수집 할 수 있습니다.

“ .dump /f /o G:\memory.dmp” (따옴표 제외)

G:\memory.dmp의 경로는 임의로 지정하시면 됩니다.

LiveKD Option

/f - Create a full dump

/m - Create a minidump (default)

/o - Overwrite any existing file

4. LiveKD 종료 시 ‘Q’ 를 입력합니다.

p.s. 요즘 흘러나오는 뉴스들이 마음을 무겁게 하네요, 어서 빨리 지나가길 바랍니다.

ADPlus로 유저모드 Crash & Hang dump 생성하기

sankim — Wed, 30 Jul 2008 07:03:47 GMT

이전 'Bye~ Bye~ Dr. Watson (drwtsn32.exe)!' 포스팅에서 Vista 이후에는 Dr. Watson 대신 ADPlus를 이용해 유저모드 Crash를 수집해야 한다고 말씀드렸었는데요, 이번 포스팅에서는 ADPlus로 Crash dump와 함께 Hang dump를 생성하는 방법을 설명 드리겠습니다.

[덤프 수집 목적]

-Crash Dump는 프로세스가 죽는(?) 순간 ADPlus가 감지해 그 당시 메모리에 있던 Crash된 프로세스 내용을 dump로 저장한 뒤 그 dump를 이용해 Crash 발생 원인을 찾기 위함 입니다.

-Hang Dump는 프로세스는 살아 있으나 더 이상 Running하지 못하는 상황에 사용자가 수동으로 시차를 두고 몇번의 Dump를 생성한 뒤 각 덤프를 비교해 공통 적으로 막혀(?)있는 부분을 찾아 Hang이 발생 원인을 찾기 위함 입니다.

[ADPlus dump 수집]

1. Windbg 설치

Crash/Hang dump를 수집 하기 위해서는 기본 적으로 문제 발생하는 컴퓨터에 Windbg를 설치 해야 합니다.

아래 링크 “Download the Debugging Tools for Windows”에서 [Current Release Version]을 다운로드 하여 설치하시기 바랍니다.

32Bit 버전: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

64Bit 버전: http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx

2. Crash Dump 수집 방법

문제가 발생하는 Process가 running중인 상태에서 아래 작업을 순차적으로 진행해 주시기 바랍니다, 단 Crash 덤프는 한번만 설정해 놓으면 문제가 재현됨과 동시에 자동으로 Dump를 생성합니다. Hang 덤프 수집은 아래 '3. Hang Dump 수집 방법'을 참조 하십시오.

1) [시작] - [실행] - cmd 를 입력

2) Adplus.vbs가 설치된 folder로 이동합니다. 설치당시, 경로를 변경하지 않았다면, default path로 이동합니다. (Default path: %ProgramFiles%\Debugging Tools for Windows)

3) Crash의 경우 덤프를 생성하기 위해 아래 명령을 수행합니다

방법1

CScript adplus.vbs -crash -pn %Processname% (%Processname%는 해당 프로세서 명을 의미 합니다)

예) CScript adplus.vbs -crash –pn Test.exe

방법2

CScript adplus.vbs -crash -p %PID% (PID는 해당 프로세서의 Process ID를 의미 합니다)

예) CScript adplus.vbs -crash –p 1044

*화면중앙에 Message box가 두 번 나올 것이므로, 확인 버튼을 두 번 눌러주시기 바랍니다.

4) 문제의 현상을 재현 시킵니다, 혹은 재현 될때까지 해당 명령 콘솔을 놔둡니다.

Crash 덤프의 경우 문제가 발생하면 자동으로 dump가 발생합니다,

5) 문제가 발생하고 나면, Adplus.vbs가 설치된 경로(default path참조)에 "Crash_Mode_*"로 시작하는 폴더로 이동하셔서 아래 사항을 확인합니다.

- 확장자가 *.dmp라는 파일이 존재해야 한다.

- Crash Dump의 경우 *.dmp파일의 이름중에 "*_2nd_chance_*"라는 이름으로 된 file이 존재해야 합니다, 또 *.dmp파일의 이름중에 "*_1st_chance_process_shutdown_*"이라는 이름이 존재하는 경우는 사용자가 임의로 해당 user process를 종료한 경우이므로, 다시 2번 작업부터 시작해야 합니다.

3. Hang Dump 수집 방법

1) [시작] - [실행] - cmd 를 입력

2) 문제의 현상을 재현될 때 아래 명령을 실행 합니다.

Crash 덤프와 마찬가지로 프로세스를 지정하는 방법이 두가지 있습니다, 둘중 하나를 선택해 실행 하십시오. Hang 덤프는 Hang이 발생한 상태에서 1~2 분 간격으로 최소 3번 이상 덤프를 생성해야 합니다.

방법1

CScript adplus.vbs -hang-pn %Processname% (%Processname%는 해당 프로세서 명을 의미 합니다)

예) 아래와 같이 동일한 명령을 1분에 2~3번 정도 생성합니다.

CScript adplus.vbs -hang –pn Test.exe (한번 생성, 덤프가 생성이 되면 두번째 명령 실행)

CScript adplus.vbs -hang –pn Test.exe (두번째 dump 생성, 세번째 명령 실행)

CScript adplus.vbs -hang –pn Test.exe (세번째 dump 생성)

방법2

CScript adplus.vbs -hang-p %PID% (PID는 해당 프로세서의 Process ID를 의미 합니다)

예) 아래와 같이 동일한 명령을 1분에 2~3번 정도 생성합니다.

CScript adplus.vbs -hang –p 1044 (한번 생성, 덤프가 생성이 되면 두번째 명령 실행)

CScript adplus.vbs -hang –p 1044 (두번째 dump 생성, 세번째 명령 실행)

CScript adplus.vbs -hang –p 1044 (세번째 dump 생성)

3) 문제가 발생하고 나면, Adplus.vbs가 설치된 경로(default path참조)에 확장자가 *.dmp라는 파일이 존재하는지 확인 합니다.

[관련문서]
ADPlus를 사용하여 "중지"와 "충돌" 문제를 해결하는 방법
http://support.microsoft.com/kb/286350/ko

이 더운 여름에 몇일 무리해서 운동을 했더니 몸이 더 무거워진 느낌이네요 (더위 먹었나?.. ㅜㅜ)

여러분 모두 몸 관리 잘하시고 아직 한달 더 남은 여름 무리 없이 넘기시길 빕니다 ^^

Windows 2003 Failover Cluster 백업(Backup) 하기

sankim — Wed, 16 Jul 2008 08:35:17 GMT

백업의 중요성은 100번을 강조해도 아깝지 않겠죠? 이상하게 데이타나 시스템 백업은 신경쓰시면서 Cluster 백업은 조금 외면(?) 하시는 경향이 있더군요, 그래서 이번 포스트에서는 Windows Server 2003 Failover Clustering 백업 방법에 대해서 이야기 하겠습니다.

클러스터 데이터 백업

서버 클러스터에는 클러스터의 원활한 동작에 필수적인 네 가지 데이터 그룹인 클러스터 디스크의 디스크 서명과 파티션, 클러스터 쿼럼 데이터, 클러스터 디스크 데이터 및 개별 클러스터 노드 데이터가 있습니다.

클러스터 디스크 서명과 파티션

*Cluster는 Disk를 각 Disk 마다 가지는 고유 Signature를 가지구 분간합니다. 만약 디스크 변경작업으로 인해 Signature가 변경되면 Cluster는 디스크를 인식하지 못해 fail이 되버립니다 그래서 dumpcfg.exe를 이용하여 클러스터 디스크 signature에 대한 정보를 백업합니다.

            dumpcfg.exe > dumpcfg01.txt

*Dumpcfg는 Windows 2000 Resource Kit에 있지만 인터넷에서 검색해보시면 쉽게 찾아 다운로드 받으실 수 있습니다.

클러스터 쿼럼 데이터

서버 클러스터 노드의 데이터를 백업할 때 클러스터 쿼럼도 백업해야 합니다. 클러스터 쿼럼에는 현재 클러스터 구성, 응용 프로그램 레지스트리 검사점 및 클러스터 복구 로그가 포함되어 있어 중요합니다. 클러스터 서비스가 실행 중인 노드에서 시스템 상태 백업을 수행하는 경우 백업 마법사를 사용하여 클러스터 쿼럼 데이터를 백업할 수 있습니다.

클러스터 쿼럼을 백업하려면

1. 클러스터 관리자를 엽니다.

2. 콘솔 트리에서 클러스터 노드를 클릭합니다.

3. 파일 메뉴에서 속성을 클릭하고 백업 중인 노드에서 클러스터 서비스가 실행되고 있는지 확인합니다.

4. NTBackup을 실행합니다.

5. 백업 또는 복원 마법사에서 고급 모드를 클릭합니다.

6. 백업 탭을 클릭한 다음 백업할 드라이브, 폴더 또는 파일의 확인란에 표시하십시오에서 시스템 상태(System State)를 Check 합니다.

이렇게 하면 클러스터 쿼럼 데이타가 시스템 상태 데이터와 함께 백업됩니다.

클러스터 디스크의 데이터

데이타가 들어 있는 클러스터 디스크를 모두 백업하려면 해당 노드에서 NTBackup.exe를 수행하여 전체 백업을 수행합니다.

클러스터 디스크 백업하기

1. NTBackup을 실행합니다.

2. 백업 또는 복원 마법사에서 고급 모드를 클릭합니다.

3. 백업 탭을 클릭한 다음 백업할 클러스터 드라이브를 선택하고 백업을 실행합니다.

개별 클러스터 노드의 데이터

한 노드의 클러스터 쿼럼 디스크를 백업했으면 나머지 클러스터 노드의 쿼럼은 백업할 필요가 없습니다. 그러나 나머지 클러스터 노드의 클러스터링 소프트웨어, 클러스터 관리 소프트웨어, 시스템 상태 및 응용 프로그램 데이터는 백업이 필요할 수 있습니다.

개인적으로 시스템 드라이브(보통 C:\)를 통째로 백업 하실것을 권장합니다.

백업만큼 중요한게 복구라는거 아시죠?. 백업은 했는데 복구를 할줄 모른다면 난감하겠죠? ^^;

꼭 가상머신에서 백업/복구 테스트로 연습해보시기 바랍니다.

문제 분석을 위한 로그를 한번에 수집 한다 MPSReport!

sankim — Mon, 30 Jun 2008 10:12:23 GMT

시스템이나 응용프로그램에 문제가 발생하면 문제 해결을 위해서 로그를 수집한 뒤에 그 로그 분석을 통해 문제를 해결 하게 됩니다.

만약 원격에 있는 시스템에 문제가 발생한다면?

[상황극]

전화: 띠리링 띠리링~

고객: 안녕하세요? XX서버 있죠? 그 서버에 올라간 서비스가 갑자기 이상하네요, 어떻게 하죠?

나: 아 그래요? 그럼 먼저 관련 로그부터 봐야 알겠네요, 먼저 이벤트 로그 보내주세요. 시작 가셔서 실행에 eventvwr.exe 실행 하시고 시스템 로그 오른쪽 클릭하신 다음에 ‘다른 이름으로 저장’하고… 어쩌고 저쩌고

고객: 아, 예~ 알겠습니다, 보내드리겠습니다.

(잠시후)

나: Tcp/IP 정보 확인 하게 ipconfig /all 정보 보내 주세요. 명령 프롬프트 실행하시고 ipconfig /all > ipinfo.txt로 저장하시고… 어쩌고 저쩌고

고객: 예~ 보내드리지요.

(잠시후)

나: 네트워크 문제 같기도 하네요 네트워크 연결들을 확인해야 해서 그러는데 netdiag.exe 실행해서 결과 보내 주세요. netdiag 실행하려면 Support tool 설치해서..... 어쩌구 저쩌구

고객: 네.

(잠시후)

나: 참! Repadmin.exe 결과도 봐야 할것 같네요, 실행해서 결과 보내 주세요. 그건 어디있냐면도.. 어쩌구 저쩌구

고객: 네... (짜증)

(잠시후)

나: 죄송한데... 뭘 좀 봐야 할 것 같은데… 어쩌구 저쩌구

고객: ... 네.... (속으로: XX, 로그만 보내 주다 하루 다 보내겠다)

(잠시후)

나: 저 마지막으로 xx로그를 봐야 할 것 같은데..

고객: ㅆ ㅑ ㅇ!

위와 같은 경험 한번쯤 있으시죠? 이 로그 달라 저 로그 달라 요청하는 것도 눈치 보일 뿐더러 로그 수집해 보내는 사람도 힘들기는 마찬가지 입니다.

이런 문제를 해결해 줄 수 있는 도구가 바로 MPSReport 입니다.

MPSReport는 각 제품/시나리오 별로 필요한 모든 로그를 수집할 수 있도록 구성 되어 있습니다. 일반적인 Troubleshooting 분석을 위해 필요한 로그는 모두 수집한다고 보시면 됩니다. 마이크로소프트 엔지니어들도 가장 먼저 시작하는 일중에 하나가 바로 MPSReport에서 수집된 로그를 분석하는 것입니다.

MPSReport는 설치 파일로 Install 되지 않습니다, 즉 프로그램 추가/제거에 등록되는 프로그램이 아닙니다. 대신 각 MPSRPT_xxx.exe를 실행하면 로그 수집에 필요한 도구를 %systemroot%\MPSReports\%MPSReport Name%\binary에 압축을 해제 한 뒤에 MPSReport 실행에 필요한 Script를 실행 하게 됩니다.

[그림] MPSReport로 로그 수집하는 중

실행 후 모든 로그 수집 결과는 %systemroot%\MPSReports\%MPSReport Name%\Reports\Cab 폴더에 %COMPUTERNAME%_MPSReports.CAB 파일로 모든 결과를 압축합니다. 원격에서 MPSReport의 결과값이 필요하다면 이 cab 파일만 전송 받으면 됩니다. 꼭 원격에서뿐만 아니라, 문제의 시스템 앞에 있다 하더라도 정리된 로그를 한번에 받아 확인 하고 싶은 분이시라면 MPSReport 로 정리된 로그를 즉석에서 확인 할 수도 있습니다.

꼭 시간 나실 때 꼭 한번 실행해 보시고 어떤 로그들이 있는지 그 의미가 무엇인지 찾아 보시기 바랍니다.

[MPSReport 개요]

Overview of the Microsoft Configuration Capture Utility (MPS_REPORTS)

http://support.microsoft.com/default.aspx?scid=kb;en-us;818742

[각 MPSReport 다운로드]

Microsoft Product Support's Reporting Tools

http://www.microsoft.com/downloads/details.aspx?FamilyId=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

ProcessExplorer를 이용한 Troubleshooting

sankim — Fri, 25 Jan 2008 10:32:55 GMT

이전 포스트에 이어 무엇으로 ProcessExplorer을 이용한 Troubleshooting을 보여드릴까 고심 하던 중 제 Laptop에서 ProcessExplorer를 사용해 문제해결을 한 예가 있어 여러분들께 보여 드릴까 합니다. 한가지 말씀드릴 것은 여기서 말씀 드리는 방법은 ProcessExplorer를 사용하는 하나의 예제이며 더 낳은 다른 방법이 있을 수 있습니다.

ProcessExplorer 다운로드

[문제내용]

IE에서 특정 사이트에 접속한 뒤 IE를 다른 URL로 이동하거나 종료버튼을 누르면 IE에서 프로그램 응답 없음(Hang) 상태가 발생한다.

그림. 응답 없는 Internet Explorer

[해결과정]

위와 같은 문제 상황에서 가정을 세워 봅니다

‘IE는 문제가 없다, 그렇다면 IE 실행 시 환경적인 요인이 IE에 문제를 일으키는 것은 아닐까?’

대부분 IE에서 문제가 발생하는 원인이 ActiveX혹은 툴바(Tool bar)같은 3’rd party 제품이 IE에 붙어 실행되면서 나타나므로 문제 사이트에 접속했을 때 어떤 것들이 IE와 함께 로드 되는지를 확인 하고 그것을 Disable하여 문제가 발생하는지 확인 합니다. 특정 컴포넌트를 Disable하고 문제가 재발하지 않았다면 해당 컴포넌트의 문제 가능성이 높습니다.

여기서 핵심은 ProcessExplorer을 이용해 문제가 발생했을 때 어떤 컴포넌트(DLL)이 로드 되었는지 확인 하는 것입니다

그럼 한번 제 컴퓨터에서 문제를 일으키는 그것(?)을 찾아보도록 합시다.

1) 먼저 ProcessExplorer로 실행하고 IE 실행 시 로드 되는 DLL을 확인 하기 위해서 그림에서와 같이 View를 설정합니다. 그러면 하단에 해당 Process 실행시 로드되는 DLL을 확인 할 수 있습니다.

그림 1. ProcessExplorer에서 환경 설정

2) 문제 상태와 정상 상태에서 로드 되는 Process와 DLL을 비교 하기 위해 IE에서 정상일 때 로드 되는 Process와 DLL 리스트를 저장합니다.

a. IE를 실행합니다.

b. 상단 panel에서 iexplorer.exe를 선택합니다.

c. File > Save As로 화면에 나타난 리스트를 저장합니다. (예. 1.txt)

그림 2. 문제 발생 전 상태

3) 이제 IE에서 문제의 사이트로 이동해 로드되는 로드 되는 Process와 DLL 리스트를 저장합니다.

a. 문제 사이트로 이동시 하단에 새로 로드 되는 DLL이 잠깐 하이라이트 되어 나타납니다, 이것들이 이 문제를 일으키는 주범일 가능성이 높습니다.

b. File > Save As로 화면에 나타난 리스트를 저장합니다. (예. 2.txt)

c. 문제가 발생하는지 닫기 혹은 다른 사이트로 이동해 봅니다.

그림 3. 문제 사이트에서 로드 되는 DLL들

4) 문제 전/후에 로드 된 DLL을 비교하여 어떤 DLL이 문제를 일으켰는지 추정합니다, 텍스트 내용을 눈 빠져라 비교할 수도 있지만 windiff.exe라는 도구를 이용하면 쉽게 텍스트간의 차이점을 확인 할 수 있습니다.

a. Windows 설치 CD에 있는 Windows Support라는 폴더에서 Windows support tool을 설치하면 windiff를 사용할 수 있습니다.

b. Windiff.exe를 실행하고 File > Compare Files를 실행합니다.

c. Select First File에서는 Step3번에서 저장한 1.txt파일을 선택하고 Select Second File에서는 Step4에서 저장한 2.txt파일을 선택합니다.

d. 그림에서와 같이 두 파일 텍스트 간에 서로 다른 내용을 확인 할 수 있습니다(노란색으로 표시되는 부분). Windiff에서 보면 두번째 텍스트 파일에 처음 문제 발생전과 다른 새로운 BGM.DLL이 로드 됨을 확인 할 수 있습니다.

그림 4. Windiff로 확인한 IE에 로드된 DLL

5) BGM.DLL이 어떤 파일인지 알기 위해 파일 속성을 확인 할 수도 있고 그림에서와 같이 string을 확인하는 방법이 있습니다.

a. ProcessExplorer의 하단에서 BGM.DLL를 더블 클릭합니다.

b. Strings 탭으로 이동합니다.

c. DLL 내부에 있는 String 중에 어떤 ActiveX인지를 알 수 있는 문자를 확인 할 수 있습니다.

그림 5. String 내용

6) IE에서 BMGCtrl이라는 ActiveX를 Disable 합니다.

a. IE > 도구 > 인터넷옵션 > 프로그램 > 추가 기능 관리

b. String에서 확인 했던 BGMCtrl Clasee가 보입니다. 이것을 선택 합니다.

c. 하단에 ‘사용 안 함’을 선택한 뒤에 ‘확인’을 클릭합니다.

d. IE를 재 시작 한 후에 문제가 발생하지 않음을 확인 합니다.

그림 6. IE에서 해당 ActiveX를 Disable

사실 위와 같은 경우는 꼭 해당 ActiveX 만의 문재라기 보다는 또 다른 변수와 복합된 문제의 가능성이 있습니다, 그러나 처음 말씀 드렸듯이 ProcessExplorer의 예제를 보여드리기 위함임을 다시 한번 말씀 드립니다.

이번 포스트에서 설명 드린 방법 이외에도 ProcessExplorer을 이용할 수 있는 방법은 무궁무진 합니다. 다음에도 제 Laptop에 ProcessExplorer의 도움이 필요한 문제가 생기면 또 한번 포스트 해보도록 하겠습니다. ^^

Windows의 슈퍼 작업관리자 ProcessExplorer

sankim — Thu, 17 Jan 2008 07:13:14 GMT

Windows 어드민의 축복 ProcessExplorer

ProcessExplorer는 윈도우 작업관리자(Task manager)를 뛰어 넘는 슈퍼 작업 관리자 라고 할 수 있습니다. 과거 Sysinternals의 Mark Russinovich가 만들었으며 2006년 마이크로소프트에 Technical Fellow로 입사하면서 마이크로소프트 홈페이지에서 다운로드 할 수 있게 되었습니다. *Mark Russinovich는 Inside Windows 2000, Windows Internals의 공동저자입니다.

보통의 경우 엔지니어들이 사용하는 작업관리자는 Process의 Processor와 Memory 사용률을 확인 하는데 사용하는 것이 대부분입니다. 이 자체만으로도 효용이 있다고 할 수 있으나 실제 Troubleshooting을 위한 Detail한 정보를 얻기에는 조금은 부족합니다. 단순한 리소스 사용을 측정하는 것을 넘어 좀더 Advanced한 Troubleshooting을 위한 정보를 얻기 위해서는 Debugger나 기타 시스템 리소스 관련 도구를 이용해 정보를 수집(혹은 노가다)이 필요했습니다.

ProcessExplorer는 작업관리자에서 보여 주는 단순한 정보를 뛰어 광범위한 정보를 하나의 툴에서 볼 수 있도록 해주며 작업관리자(Taskmgr.exe)가 할 수 있는 작업 이외에 추가적인 작업이 가능합니다.

ProcessExplorer를 실행해 보면 아래 그림1과 같이 현재 실행 되고 있는 process가 사용하고 있는 파일, Handle, Object 그리고 Process에서 로드 한 DLL 등 여러 가지 정보를 실시간으로 보여 줍니다. 상단 pane에서는 각 Process에 대한 정보, 하단 Pane에서는 해당 Process의 Handle 혹은 Dll 관련 정보를 보여 줍니다.

그림 1

위 그림1에서 Outlook.exe 관련 Process 정보 그리고 하단 Pane에서는 DLL 관련 정보를 보여 주는 것을 볼 수 있습니다.

그림 2

View > Select Column을 실행하면 그림 2와 같이 상단 Pane에서 볼 수 있는 여러 가지 Column 들을 선택 할 수 있습니다.

그림3과 같이 Process 관리&테스트를 위한 여러 기능들을 가지고 있습니다.

그림 3

작업 관리자에 없는 기능이 특정 Process를 Suspend(중지) 시킬 수 있는 기능인 Suspend, Process와 관련 파일들의 종속성을 볼 수 있는 Launch Depends(Dependency Walker가 실행됩니다) 그리고 해당 Process가 어떤 Process인지 인터넷으로 자동으로 검색 할 수 있는 Search Online와 같은 기능이 있습니다.

Properties를 클릭하면 아래 그림4처럼 Process의 여러 Detail한 정보 확인이 가능합니다.

그림 4

또 그림5에서와 같이 Replace Task Manager를 실행 하면 윈도우 작업 관리자를 실행하면 Taskmgr.exe가 실행 되는 대신 ProcessExplorer이 실행됩니다.

그림 5

그림6은 View > System Information으로 변경한 모습입니다. 작업 관리자와 유사하죠? Symbol path를 설정하면 Page, Non-page Limit 값도 보실 수가 있습니다.

그림 6

여러분들도 한번 사용해 보시면 정말 훌륭한 도구임을 느끼실 수 있으실 거라 믿습니다. 꼭 ProcessExploere의 세계에 빠져드시길 바랍니다.

ProcessExplorer 다운로드

다음 포스트에서는 실제 ProcessExplorer를 이용한 간단한(?) Troubleshooting 예제를 보도록 하겠습니다.

Autoruns와 함께 Windows 부팅 중에 자동으로 시작되는 프로그램으로 인한 문제를 해결 해 보자!

sankim — Thu, 30 Aug 2007 12:54:00 GMT

오늘은 Autoruns라는 도구를 소개해 드리겠습니다.

Field에서는 부팅 중 자동으로 시작되는 프로그램이 말썽을 일으켜서 찾아서 제거해야 할 경우가 생기는데, 아주(?) 예전에는 시작 폴더나 시작과 관련된 모든 레지스트리를 뒤져야 했습니다, 그러다 Windows XP에서 msconfig.exe가 나와 수고는 좀 덜었지만 그래도 충분한 정보를 보여주지 못했기 때문에 추가적으로 레지스트리를 또 뒤져야 했습니다. (바이러스나 악성코드를 수동으로 검색해서 제거할 때 몇 시간이고 이 노가다 했던 서글픈 추억이 ㅜㅜ)

이 노가다를 해방 시켜줄 수 있는 도구가 바로 Autoruns입니다. Autoruns를 이용하면 Windows 부팅 할 때 자동으로 시작되는 모든 프로그램이나 구성요소들을 찾아낼 수 있습니다.

Autoruns는 처음 sysinternals를 통해 소개 되었고 지금은 마이크로소프트 사이트에서 다운로드가 가능합니다.

다운로드

어떤 경우에 Autoruns가 필요할까요?

[시나리오]

1. 로그온 시간이 갈수록 길어져 시작 시 어떤 프로그램이 로딩되는지 확인이 필요하다.

:부팅시 어떤 프로그램이 문제인지 확인 하기 위해서 임시로 다음 부팅시 로딩되지 않도록 설정할 수 있습니다.

2. Malware를 수동으로 검색해서 제거 할 때 어떤 프로그램(프로세스)가 자동 시작 되는지 확인이 필요하다.

: Autoruns를 통해서 로드 된 exe 중에 악성 코드라고 판단 되면 Delete 할 수 있습니다.

3. 부팅에 문제가 생기는데 어떤 Service, Network Provider, Driver, Extension 등이 로드 되는지 확인 해야 한다.

: Autoruns의 각 탭에서 다양한 정보를 확인 할 수 있습니다.

다운로드 받으신 후 Autoruns.exe를 실행하시면 아래와 같이 실행 되고 시작 프로그램 등 정보를 수집하게 됩니다.

각 탭을 보시면 시작 중에 로드 되는 구성을 확인 할 수 있습니다.

로드된 구성중에 시나리오 1과 같이 임시로 Disable이 필요한 경우 해당 프로그램을 그림에서 처렴 Uncheck 합니다.

시나리오 2에서 처럼 삭제가 필요하다면 Delete를 실행합니다.

무엇인지 확인이 필요한 내용에 대해서는 아래 같이 편리하게 바로 검색기로 연결해서 확인 할 수 도 있습니다.

말씀 드린 것 이외에도 많은 기능을 사용하실 수 있습니다, 세부사항까지 자세히 쓸까 하다가 한번만 써보시면 많은 부분 응용(?)이 가능 하실거라 믿어 여기까지 쓰도록 하겠습니다.

문제가 생겨 급조해서 쓰시기 보다는 꼭 한번 사용(경험)해 보시기 바랍니다. (아마 Troubleshooting을 해야 하는 엔지니어라면 Autoruns한번쯤은 꼭 쓰실 일이 있으실겝니다..)

AutoRuns for Windows
http://www.microsoft.com/technet/sysinternals/utilities/Autoruns.mspx

커널 라이브 디버깅을 위한 Remote Live Debugger 설정 하기

sankim — Mon, 20 Aug 2007 09:35:00 GMT

이번 Post는 바로 원격에서 커널 디버깅을 할 수 있는 Remote Live Debugger 설정하기 입니다. 지금까지 자료들은 많은(?)데 실질적으로 Setting에 어려움을 격으신 분들이라면 많은 도움이 되실것이라 믿습니다.

Windows Server 2003을 기준으로 작성하였습니다.

[용어정리]

Target: 문제가 발생하여 라이브 디버깅이 필요한 컴퓨터를 Target 컴퓨터라 부릅니다.

Host: 원격에서 문제의 컴퓨터를 디버깅 하기 위한 컴퓨터를 Host 컴퓨터라 부릅니다.

Null Modem Cable: Target과 Host 컴퓨터 간의 통신을 위해 매개가 되는 Cable입니다.

WinDbg: Kernel 라이브 디버깅을 하기 위한 소프트웨어 입니다. 최신 버전은 http://www.microsoft.com/whdc/devtools/debugging/default.mspx 에서 확인 하십시오.

그림 1 Null Modem Cable

[사전준비사항]

1. Target 컴퓨터에 연결하여 Debug를 하기 위한 별도의 컴퓨터가 준비 되어야 합니다.

2. Null Modem Cable이 준비 되어야 합니다.

3. 두 컴퓨터에 사용할 수 있는 Com 포트가 있어야 합니다.

4. Debug를 실시할 Host 컴퓨터는 WinDbg가 설치 되어야 하며 Symbol 파일이 있어야 합니다. 그렇지 않으면 인터넷에 연결하여 Web Symbol Server와 연결되어야 합니다.

사전 준비 작업

1. Target과 Host 컴퓨터의 장치 관리자에서 사용가능 한 Com Port 번호를 확인 합니다.

그림 2 Com Port 확인

2. Target, Host 컴퓨터의 Com port에 Null Modem Cable를 연결합니다.

[Kernel Live Debuger 설정 방법]

1. Target 컴퓨터에서 아래와 같이 설정 합니다.

a. 아래 명령을 C:\에서 실행합니다.

attrib -s -h -r c:\boot.ini

b. C:\boot.ini에서 아래와 같은 옵션을 추가 합니다.

/debug /debugport=com1 /baudrate=115200

/debugportㅇ에서 옵션에서 사용가능 한 Com Port를 확인하고 설정합니다.

그림 3 Boot.ini 편집

2. Host 컴퓨터에서 아래와 같이 설정합니다.

1. WinDbg(디버깅 도구)를 설치 합니다.

a. http://www.microsoft.com/whdc/devtools/debugging/default.mspx에서 환경에 맞는 WinDbg를 다운로드 하여 설치 합니다.

2. WinDbg에 Symbol 경로를 설정합니다.

a. Windbg를 실행합니다.

b. File > Symbol File Path를 선택합니다.

c. Symbol path에 아래와 같은 Text를 입력하고 OK 버튼을 클릭합니다.

SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

그림 4 Web Symbol 설정

[라이브 디버깅 시작하기]

a. Host 컴퓨터의 WinDbg에서 File > ‘Kernel Debug…’를 클릭합니다

b. ‘Baud rate’ 값에 115200, Port에는 Host 컴퓨터의 Com Port 번호를 설정하고 ‘확인’ 버튼을 클릭합니다.

그림 5 Com Port 설정하기

c. WinDbg 화면에서 ‘Waiting to reconnect...’ 메시지가 나타나면 Target 컴퓨터를 재부팅 합니다.

그림 6 Waiting to reconnect 상태

d. ‘그림 7’과 같은 상태에서 Ctrl + Break 키를 눌러 Control을 Host 컴퓨터로 가져 옵니다.

그림 7 Control을 가져오기 전 상태

그림 8 Control을 가져온 상태

위 상태에서 라이브 디버깅이 가능합니다.

[Target 컴퓨터에서 Memory dump 생성]

‘0> kd’에서 ‘.crash’를(따옴표 빼고) 입력하면 원격의 Target 컴퓨터에서 블루스크린이 발생하면서 Memory dump를 생성합니다. 생성된 Memory dump는 Target 컴퓨터의 C:\%Systeomroot%\

그림 9 Crash 실행

[Exception 발생시 Action 설정]

라이브 디버깅을 설정하면 일반적인 First Exception에도 사용자의 Action이 필요할 수 있습니다. 이를 막기 위해 아래와 같은 방법으로 Exception 발생시 어떤 Action을 취할 지 설정 할 수 있습니다.

SXD: Exception 발생시 Break into하여 특정 명령을 실행 할 수 있습니다.

e.g) SXD -c "kb;.time;g" -c2 "kb;.time;g" *

SXN: Exception 발생시 Break into를 하지 않고 메시지 정보 만을 Debuger에 Display합니다.

e.g) SXn -c "kb;.time;g" -c2 "kb;.time;g" *

그림 10 SX* 설정 방법

[관련 문서]

How to Set Up a Remote Debug Session Using a Modem

http://support.microsoft.com/?id=148954

파일, 널 모니터링 하겠어! [Process Monitor for filemon]

sankim — Thu, 14 Jun 2007 10:53:00 GMT

앞으로 Troubleshooting을 위한 내용을 진행할 예정입니다,

그 첫번째로 File에서 어떤 일들이 일어나는지를 모니터 하여 Troubleshooting에 이용할 수 있는 방법을 말씀드리겠습니다.

엔지니어 분들이 실제 필드에서 파일을 모니터링 해야 할 경우은 언제 일까요? 아래와 같은 시나리오들이 되지 않을까요?.

[시나리오]

1. 저장해 둔 testfile.txt 파일이 몇 차례나 반복적으로 삭제되는 현상이 발생했다, 어떤 프로세스가 삭제 했는지 알고 싶다.

2. 특정 명령을 실행하면 몇 개의 파일이 생성되는데 어떤 파일들이 어디에 생성되는지 확인 하고 싶다.

3. 특정 폴더에 계속해서 이상한(?) 파일들이 생성된다, 어떤 프로세스가 생성하는지 확인 하고 싶다.

시나리오 1의 경우 특정 백신 프로그램이 txt를 malware로 인식하고 삭제한 경우입니다. 누구도 백신이 멀쩡한 txt를 삭제할거라고 생각하지 못하겠지요. (실제로 txt는 아니고 어떤 백신프로그램이 PPT 파일을 몽땅 삭제해버린 문제가 있었습니다), 어떤 프로세스가 txt를 삭제하는지 모니터링이 필요할 것 입니다.

시나리오 2의 경우 명령을 실행하면서 나도 모르는 파일이 생성된다면 ‘혹시 나 몰래 엉뚱한 파일이?’ 하는 의심이 들 수 있지요. 어디에 어떤 파일이 생성되는지 확인 해 봐야 할 것입니다.

시나리오 3의 경우 3’rd party 응용프로그램이 잘못된 로그를 무한대로 생성하면서 발생한 문제입니다. 이런 경우 동물적 감각(?)을 이용하지 않으면 웬만해서는 찾기 어렵습니다. 이때는 폴더에 대한 모니터링이 필요할 것 입니다.

위 시나리오들은 실제 제가 진행했던 Case를 기반으로 나열한 것인데 그 이외에도 Troubleshooting이나 특정한 목적을 위해 파일을 모니터링 해야 하는 시나리오가 많이 있을 것입니다. 이런 경우 감사 정책을 설정할 수 있으나 무겁기도 하고 그리 효율적이지 못합니다. 이럴 때는 좋은 방법이 무엇이 있을까요?

정답은 Process Monitor for filemon을 이용하는 것입니다.

Process Monitor v1.12 (클릭하시면 process monitor을 다운받을 수 있는 페이지로 이동합니다 )

이전에는 Filemon이라는 도구로 파일을 모니터 했습니다만 이 기능을 Process monitor에 추가함으로써 Process Monitor 안에서 파일 모니터링이 가능합니다, 또한 각 tool이 가진 기능을 합쳐져서 더욱 강력한 모니터링 기능을 제공합니다.

원래 두 도구 모두 Mark Russinovich의 Sysinternals에서 무료로 다운로드 받아 사용할 수 있도록 만든 도구였는데 Mark가 작년 가을에 MS로 입사하면서 MS 사이트에서 다운로드 받을 수 있게 되었습니다, 물론 지금도 무료로 사용할 수 있습니다 :) .

그럼 ‘시나리오1’을 예로 한번 어떤 프로세스가 특정 파일을 삭제하는지 직접 보여드리겠습니다.

1. 먼저 Process monitor을 다운로드 받아 실행합니다, 실행하면 그림과 같은 콘솔이 나타납니다. 기본적으로 File 모니터 기능뿐만 아니라 Process, registry 모니터링 기능까지 모두 활성화 되어있기 때문에 여러 정보들이 정신 없이 스크롤 되는 것을 보실 수 있을 것입니다.

2. 필요한 정보만을 확인 하기 위해서 먼저 그림에서와 같이 가운데 Filemon(왼쪽부터 regmon, filemon, processmon)기능을 제외하고 모두 비활성화로 설정합니다.

3. Filemon만 활성화 해도 파일시스템에서는 우리가 모르는 엄청난 많은 일들이 발생하기 때문에 계속해서 작업내용이 스크롤 되는 것을 볼 수가 있습니다. 이때 Filter를 설정해서 좀더 쉽게 볼 수 있는 방법이 있습니다. 모니터링 하기 위한 파일이 C:\TEMP\testfile.txt라면 상단에 Filter > Filter를 클릭하고 그림에서와 같이 path를 선택한 뒤에 해당 파일 경로를 선택하고 add를 누른 뒤 적용할 수 있습니다, 그러면 testfile.txt에서만 일어나는 일들을 보실 수 있습니다. 필터 방법은 상황에 따라 여러 가지로 적용할 수 있으니 응용해 보시기 바랍니다.

4. 아래 그림을 보니 파일이 삭제되자 파일에 액세스한 프로세스 그리고 시간 등이 나타나는 것을 볼 수가 있습니다. 삭제한 프로세스가 Explorer.exe이 군요, 이것은 제가 테스트를 위해 탐색기(Explorer.exe)로 삭제했기 때문입니다 만약 다른 프로세스가 삭제 했다면 어떤 프로세스가 삭제 했는지 알 수 있었을 것입니다.

5. 기본으로 나타나는 컬럼 이외에 다른 여러 가지 컬럼을 선택하여 다양한 정보를 확인 할 수 있습니다.

지금까지 설명 드린 내용으로 Filemon 사용방법이나 필요한 시나리오를 이해하셨을테니 나머지 시나리오에 대한 해결방법은 제가 설명 드리지 않아도 잘 응용(?)해서 답을 얻으실거라 믿습니다.

개인적으로 어떤 상황에 어떤 Tool을 효과적으로 사용해야 하는지를 아는 것이 중요하다고 생각합니다. 맨손으로 못을 박는것보다는 망치가 있으면 좋듯이..

다음 Troubleshooting에서는 레지스트리 모니터링에 대한 방법을 설명 드리겠습니다.