Media Log

위대한 해커이자 이제는 소설가(?)이기도한 윈도의 대가 마크 러시노비치의 처녀작이다.
책이 처음 나왔을 때부터 재미는 있으려나, 기술적으로 배울만한 것도 있을까 관심을 가지고 있었는데, 영어로 읽기는 싫으니 번역되는 날만을 기다렸다. 그런데 오늘 드디어 떴구나! 새해 선물인가.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
내 블로그에 프로세스 모니터 사용법이라는 검색어로 들어오는 사람들이 많아서 언젠가 한번 포스팅 해봐야겠다는 생각을 하고 있었다.
프로세스 모니터에 대해 궁금했던 사람들이 조금이라도 도움을 얻고 돌아가기를 바란다.

프로세스 모니터는 SysInternals에서 만든 수 많은 도구들 중 애플리케이션의 분석과 디버깅을 위한 가장 멋진 도구 중 하나이다.

나는 처음에 이 툴을 켜는 것을 무진장 싫어했다.
일단 실행하면 이상한 메세지들이 미친듯이 많이 내려와서 시스템을 엄청 느리게하는 것이 싫었기 때문이다.

하지만, 꾹 참고 얼마 동안만 사용하다 보면 이 툴이 왜 훌륭한지, 그리고 사용자를 충분히 많이 배려해서 만들었음을 깨닫게 될 것이다.

프로세스 모니터를 통해 그동안 너무 많은 문제를 해결했기 때문에, 나는 이제 이 툴의 신봉자가 되어버렸다.
마크 루시노비치는 그의 블로그의 한 포스트에서 스승이었던 데이비드 솔로몬이, "야 임마, 뭔가 의심가면 먼저 프로세스 모니터로 확인해 봐" 라고 말하곤 했었다 했다. 우습게도 지금 마크는 자신의 딸에게 똑같은 말을 한다고 한다.
"아빠, 이거 학교 숙제인데 잘 모르겠어요."
"그럼 프로세스 모니터로 확인해보거라."
ㅡ.ㅡㅋ

농담처럼 이야기 했지만, 정말로 이 말을 믿고 따라야한다.

  • 응용 프로그램이 내 컴퓨터에서만 오동작 할 때.
  • 프로그램 성능의 발목을 잡는 병목점이 어딘지 찾고 싶을 때.
  • 특정 프로그램이 도대체 내부에서 무슨 짓을 하는지 분석하고 싶을 때.
  • DLL이 로드되고 언로드 되는 것을 확인하고 싶을 때.

그리고 이 외 모든 이상하고 골치 아픈 문제들에 대해서 프로세스 모니터가 기꺼이 친구가 되어줄 것이다.
위 마크의 포스트에서도 시스템 부팅이 심하게 느린 원인을 프로세스 모니터를 통해 멋지게 밝혀낸 내용이 쓰여있다.

프로세스 모니터의 주요 5가지 기능은 다음과 같다.


좌측의 아이콘부터,
  • 레지스트리 활동 모니터링
  • 파일 시스템 활동 모니터링
  • 네트워크 활동 모니터링
  • 프로세스와 쓰레드 활동 모니터링
  • 이벤트 프로파일링

다섯가지 아이콘을 모두 클릭해서 프로세스의 모든 활동을 살펴 볼 수도 있지만, 로그가 너무 많아지면 문제에 집중하기 힘들기 때문에 원하는 특정 기능만을 활성화 시키면 된다.

하지만 레지스트리나 파일 시스템 둘 중 하나만 클릭해보더라도 얼마나 많은 로그가 쌓이는지 보고는 깜짝 놀라게 될 것이다. 아무 프로그램도 안 띄워놓고 있더라도 파일 시스템과 레지스트리는 눈에 안보이는 서비스나 백그라운드 애플리케이션들에 의해 항상 바쁘다.

이를 좀 더 편하게 추려내기 위해 프로세스 모니터는 강력한 필터링 기능을 또한 제공한다.


처음 프로세스 모니터를 켜면 위와 같이 필터링 대화상자나 나타난다.
초록색 아이템은 관심있어 하는 내용이고, 빨강색 아이템들은 관심이 없으니 캡쳐 하지 말라는 뜻이다.
위 그림에서 처럼 프로세스 이름으로 필터링 할 수도 있고, 파일의 경로나 쓰레드 아이디, 어떤 특정한 동작을 하는지의 여부로도 필터링 할 수가 있다. 알고 싶은 내용에 대해서만 로그가 나오도록 필터링 옵션에 숙달되는 것이 프로세스 모니터를 사용하는데 있어서 가장 중요한 점이다.

또한 위 그림에서 맨 좌측에 있는 체크박스들은 꽤 근래에 생긴 편리한 기능이다.
자신이 자주 쓰는 옵션들로 필터들을 한번 넣어 놓은 뒤, 다음번 실행시에는 체크박스만 껐다 켰다 하면서 쉽게 제어할 수 있다.


메뉴의 필터 부분을 보면 방금 설명한 필터 기능을 제외하고, 주목할 기능이 3가지가 더 있다.


Enable Advanced Output을 켜면 파일 시스템 활동을 관찰할 때 Operation이 아래 그림처럼 나타난다.


커널 쪽에서 프로그래밍 경험이 있는 사람들이라면 각 디스패치 루틴들과 대응된다는 것을 알 수 있을 것이다.

Advanced Output 옵션을 사용하지 않는다면 아래 그림처럼 일반 응용 프로그래머들에게 좀 더 익숙한 Win32 인터페이스 이름으로 출력된다.

Advanced Output 이라고 해서 항상 좋은 것은 아니며, 자신이 어떤 부분에 관심이 있는지에 따라서 양쪽을 번갈아가면서 사용하면 된다.

Drop Filtered Events 라는 것은 역시 최근에 생긴 너무 반가운 기능이다.
기본적으로 프로세스 모니터를 켜고 나면, 필터를 아주 정교하게 설정해서 원하는 로그만 출력되게 했다고 할지라도, 화면에만 안 나올 뿐이지 다른 모든 내용들이 캡쳐된다.
이는 메모리를 몹시 많이 잡아먹고 시스템을 느려지게 하는데, 위 기능을 사용하면 관심없는 이벤트들은 캡쳐하지 않고 바로 버리게 된다.
하지만, 시스템이 조금 느려지더라도 모든 내용을 버리지 않고 간직하고 있는 것이 유용할 때가 종종 있다. 로그를 보는 도중 다른 아이디어가 생각나서 필터를 변경했을 때 예전 내용들을 다 가지고 있다면 곧바로 확인해 볼 수 있지만, Drop해버리면 프로세스 모니터를 껐다 켜서 다시 캡쳐해야한다. 기능을 잘 이해한 채 적절히 사용하면 된다.


Highlight 기능 역시 로그를 쉽게 보는데 도움을 준다.

위 그림은 윈도 탐색기가 수행하는 파일 오퍼레이션 중, 파일 생성/오픈 요청이 성공한 경우만을 하이라이팅 하는 것을 보여준다.
이 정도로 간단한 경우에는 프로세스 모니터의 하이라이팅도 편리하지만 조금 더 복잡해지면 설정하는 것이 꽤나 귀찮고 색깔도 하나라서 눈도 아프다.
그래서 그런 경우에 나는 로그를 통째로 vim에 붙여넣은 뒤 vim을 통해 여러 색깔로 하이라이팅해서 보고는 한다. 이 방법에 관심이 있다면 아래 글을 참고하면 된다.
로그 뷰어로써의 Vim, 멀티 하이라이팅


프로세스 모니터로 캡쳐한 내용을 파일로 저장할 수도 있다. 보통 PML이나 CSV 형식 중 하나로 저장하는데, 나는 PML 포맷으로 저장해서 프로세스 모니터로 열어보는 것을 선호한다. CSV로 저장한 뒤 엑셀 같은 프로그램으로 열어볼 수도 있다.

이 로그들을 처음부터 바로 파일로 저장할 수는 없을까 하는 생각이 들 수도 있다.
자신이 작성하고 있는 커널 쪽 코드에 오류가 있으면 블루스크린을 만나게 되거나, 시스템 전체가 멈춰버리는 경우가 생길 수 있는데, 이런 경우 프로세스 모니터를 켜놓고 있어도 시스템이 꺼져버리는 등 로그가 날라가기 때문에 내가 지정한 파일로 저장한다면 유용할 수 있다. 이것은 File 메뉴의 Backing Files 옵션에서 설정 가능하다.
바로 밑에서 설명할 프로세스 모니터에 커스텀 로그 출력하는 방법과 함께 사용하면 더욱 도움이 될 것이다.


응용 프로그램이나 드라이버가 프로세스 모니터를 통해 자신들만의 로그 메세지를 출력하는 것도 가능하다.
이렇게 할 때의 장점은 여러가지가 있다.

  • 프로세스 모니터가 캡쳐하는 파일이나 레지스트리 작업들과 함께 내 커스텀 로그 메세지를 한 눈에 볼 수 있다. 물론 순서가 뒤죽박죽 되지 않도록 프로세스 모니터가 잘 동기화 해준다.
  • 프로세스 모니터가 시간, 프로세스 이름, 쓰레드 번호 등의 부가 정보를 다 기록해주기 때문에 자신의 Logger에서 이런 것들을 구현할 필요가 없다.
  • 프로세스 모니터의 강력한 필터링과 하이라이팅 기능도 공짜로 이용할 수 있다.
  • 프로세스 모니터를 켜야만 로그를 쓰는 작업에 대한 오버헤드가 생긴다. 즉, 프로세스 모니터가 꺼져있으면 프로세스 모니터로 로그를 전송하지 않기 때문에 응용 프로그램의 속도 저하가 발생하지 않는다. -디바이스를 한번 오픈해보는 오버헤드는 있다.

프로세스 모니터로 커스텀 로그를 출력하는 자세한 방법은 아래 글에서 확인해볼 수 있다.
프로세스 모니터에 디버깅 메세지를 인젝션하기

얼마전에 소개했던 filetest 프로그램과 프로세스 모니터는 환상의 짝궁이기도 하다. filetest.exe 프로세스만을 캡쳐하도록 필터링해 놓은 뒤 원하는 I/O를 시도해보고 프로세스 모니터의 반응을 살펴보면 파일 시스템이 어떻게 동작하는지 쉽게 배울 수 있다.

위에서 설명한 사용법 들에 익숙해지면 프로세스 모니터를 통해 직접 문제를 해결할 수 있을 것이고, 또 이를 여러번 시도 할수록 자신만의 문제 해결 기법 아이디어을 갖게 될 것이다.

이런 몇몇 참신한 기법들에 대해서는 -위에 나왔던 시스템 부팅이 느린 현상을 해결한 포스트처럼- 이미 마크 루시노비치의 블로그나 Sysinternals의 세미나 자료를 통해서 많이 공개되어 있으니 부지런히 찾아다니면서 익혀두면 피가 되고 살이 될 것이다.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Softwares' 카테고리의 다른 글

리눅스 3.0 시대  (0) 2011.05.25
ACE 6.0 static build  (2) 2011.03.06
프로세스 모니터 사용법  (6) 2011.01.14
2010년 분야별 최고의 오픈소스들  (5) 2011.01.09
파일 조작 테스트를 위한 훌륭한 도구 소개  (4) 2010.12.27
VirtualBox 4.0 베타  (0) 2010.12.07
  1. Favicon of http://nyolong.egloos.com BlogIcon 뇨릉 at 2011.01.19 14:04 신고 [edit/del]

    얼마전에 FileMon을 받으려더 Process Monitor와 통합이 되어서 저도 이툴 한번 써봤었는데요. ㅋ
    전 간단히 파일모니터하는데만 썼었는데 참 괜찮은 툴 같습니다 ^^

    Reply
  2. BlogIcon tack at 2011.01.24 16:08 신고 [edit/del]

    전 크롬을 사용중인데 이상하게 Highlight 기능 역시... 아래 그림이 안나오네요 :(
    헌데 Explorer.exe에 대한 내용이 원래 이렇게 많나요? ㅎㅎ

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2011.01.24 17:14 신고 [edit/del]

      에 정말요? 저도 크롬쓰는데 잘 나오는데.
      다른 장소에서도 잘 나오고요. 용량이 조금 크긴 한데 다른 문제가 있는건지 모르겠네요.

submit
SysInternals의 대부분의 유틸리티들은 하나의 실행파일로 배포된다.

프로세스 모니터 같은 도구는 시스템 내에서 일어나는 모든 I/O등을 잡아채서 보여주는데 이 역시 EXE 파일 하나로 배포된다. 그렇다면 마크 러시노비치가 이것들을 유저모드 애플리케이션에서 구현했다는 말인가? 아니, 심지어 이런 것들을 유저모드에서 구현할 수나 있는 것일까?
물론 그렇지는 않다. 프로세스 모니터는 파일 시스템 레이어 상위에 장착되는 필터 드라이버와 응용 프로그램으로 구성되어져 있다. 아마도 필터 드라이버가 열심히 I/O를 엿본 다음에 그 정보를 잘 정리해서 응용 프로그램에게 전달한 뒤 응용 프로그램이 GUI로 출력하도록 구현되어져 있을 것이다.

그렇다면 프로세스 모니터의 드라이버 이미지는 어디에 숨어있는 것일까?
드라이버는 바로 EXE 파일 내의 리소스에 있다.


응용 프로그램 내에 커스텀 리소스를 하나 만들어서 그 곳에 바이너리 파일을(여기서는 프로세스 모니터 드라이버 이미지) 쑤셔 넣어둔다.
응용 프로그램이 처음 실행되면 FindResource, LoadResource, LockResource, SizeofResource 함수들을 사용해서 이 리소스를 읽어 오고 CreateFile과 WriteFile 같은 함수를 통해서 새로운 파일을(바로 그 프로세스 모니터 드라이버) 디스크 상에 만들어낸다.
이런 식으로 말이다.
HRSRC h = FindResourceW(0, MAKEINTRESOURCEW(IDR_BIN), L"BIN");
HANDLE hRes = LoadResource(0, h);
CONST CHAR* p = (CONST CHAR*)LockResource(hRes);
HANDLE hFile = CreateFileW(L"D:\\bin", GENERIC_ALL, 0, 0, CREATE_ALWAYS, 0, 0);
DWORD cb = SizeofResource(0, h);
DWORD dw;
WriteFile(hFile, p, cb, &dw, 0);
UnlockResource(hRes);
너무 간단하지 않은가?

이제 드라이버 파일이 생겼으므로 응용 프로그램 코드에서는 CreateServiceStartService 함수들을 통해서 드라이버를 설치하고 구동시킬 수 있다.
응용 프로그램이 종료 될 때는 물론 드라이버를 잘 멈추고 제거하고 파일을 지워버리는 등의 작업 또한 해주어야 할 것이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 관우 at 2011.01.05 23:15 신고 [edit/del]

    너무 궁금했는데 이렇게 간단할 줄은 몰랐네요. ㅎㅎ 잘 배워 갑니다.

    Reply

submit
이제는 마이크로소프트에 흡수된 구 Sysinternals가 만든 여러 유용한 툴 중 Process Monitor는 내가 가장 좋아하는 툴이다.
많은 사람들이 Process Explorer만을 사용하는데, 아마도 Process Explorer의 직관적인 사용자 인터페이스 덕분이리라.
Process Monitor는 잘 사용하려면, 툴에도 익숙해져야 하지만 Windows API를 많이 알고 있어야 하기 때문에 개발자가 아닌 QA팀 같은 곳에서는 사용하기 힘들다.
하지만 프로세스가 수행하는 모든 동작들을 잡아채서 보여주기 때문에 어떤 응용프로그램을 분석할 때 유용한 많은 정보들을 얻어 낼 수 있다.

DbgView 또한 우리 개발자들이 디버깅 할 때 많이 사용하는 애플리케이션 중 하나다. 응용프로그램이나 디바이스 드라이버에서는 OutputDebugString이나 DbgPrint 같은 함수로 로그를 작성한 후 이 툴을 통해서 프로그램의 상태를 추적하고는 한다.

파일 시스템 필터드라이버를 만들게 되면 이 두가지를 같이 병행하고 싶은 경우들이 생길 수 있다.
응용프로그램들이 어떤 Irp를 보내는지를 모니터하고, 내 필터 드라이버는 어떤 동작을 하는지를 함께 보고 싶은 것이다.

두가지 툴을 번갈아 가면서 쳐다보는 일은 순서를 제대로 예측하기가 어렵기 때문에 정말 열받는 일인데, 이번에 프로세스 모니터에서 이런 기능을 해결하기 위한 인터페이스가 하나 추가되었다.

이 아이디어는 디버깅 애플리케이션으로 유명한 존 로빈스생각해내고 제안했는데, 현재 MS 최고의 프로그래머 중 하나인 마크 루시노비치를 자신의 꼬붕 프로그래머라고 농을 치는 것이 너무 웃긴다.

What I really wanted was for my trace statements to be part of the Process Monitor viewing so that way it would be trivial mapping the I/O activity to operations in my code. Fortunately, I have a personal developer at my disposal that is keen to tackle these kinds of challenges. He’s a very nice guy named Mark Russinovich who happens to be the author of Process Monitor. Mark is always eager to hear feature requests for his tools and I think he’s implemented at least 30 features in Sysinternals tools over the years that I thought would be great to have. Don’t hesitate to email Mark with feature ideas so he can be your personal developer as well.

존 로빈스의 유머 감각은 정말 끝내주는데 그의 디버깅 애플리케이션만큼 웃기는 컴퓨터 책을 아직도 만나보지 못했다.
이런 멋진 해커이자 명저자가 다시는 책을 안쓰기로 결정한 것은 정말 슬픈 일이다.

어쨌거나 마크는 콘트롤 코드를 하나 추가해서 DeviceIoControl 함수를 통해 인터페이스 할 수 있도록 기능을 제공해주었고, 최신버전의 프로세스 모니터를 보면 도움말에서 아래 코드를 찾아볼 수 있다.

#define FILE_DEVICE_PROCMON_LOG 0x00009535
#define IOCTL_EXTERNAL_LOG_DEBUGOUT (ULONG) CTL_CODE( FILE_DEVICE_PROCMON_LOG, 0x81, METHOD_BUFFERED, FILE_WRITE_ACCESS )

int main( int argc, char * argv[] )
{
  HANDLE hDevice = CreateFile( L"\\\\.\\Global\\ProcmonDebugLogger", 
                       GENERIC_READ|GENERIC_WRITE,
                       FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
                       NULL,
                       OPEN_EXISTING,
                       FILE_ATTRIBUTE_NORMAL,
                       NULL );

  if ( hDevice != INVALID_HANDLE_VALUE ) {
    WCHAR text[] = L"Debug out";
    DWORD textlen = (_wcslen(text)+1) *sizeof(WCHAR)
    DWORD nb = 0;

    BOOL ok = DeviceIoControl( hDevice,
               IOCTL_EXTERNAL_LOG_DEBUGOUT, text, textlen, NULL, 0, &nb, NULL );

    if ( ok ) {
      printf( "wrote %d\n", i );
    } else {
      printf( "error 0x%x\n", GetLastError() );
    }
  } else {
    printf( "error %d opening Process Monitor\n", GetLastError() );
  }
  return 0;
}
존 로빈스는 .NET과 C/C++에서 좀 더 편하게 사용할 수 있는 Wrapper 코드를 만들어서 올려놓았다.
커널 드라이버에서 사용하고 싶다면,
ZwDeviceIoControl
ZwDeviceIoControlFile 함수를 통해서 직접 Wrapper를 작성해야 한다. 존도 이제는 늙어서 커널 코드는 만들어주기가 귀찮은가보다.


이런 식으로 애플리케이션이나 드라이버에서 프로세스 모니터에게 직접 디버그 메세지를 보낼수가 있다.

기존에 OutputDebugString이나 DbgPrint로 찍은 함수를 Process Monitor가 잡아채서 찍어주는 것이 아니고, 우리가 직접 커스텀 함수를 호출해야만 로그 메세지를 보낼 수 있는 것에 주의하자.
즉, 꽁짜로 얻을 수 있는 것은 아니고 기존에 사용하던 애플리케이션이나 드라이버의코드를 고쳐야 한다는 것.(래퍼 함수를 작성하고, 필요한 곳에서 호출하는 만큼의 비용은 지불해야 한다.)

저작자 표시 비영리 동일 조건 변경 허락
신고

submit