※ Visual Studio를 이용하여 디버깅을 하는 법을 기본적으로 숙지하고 있다는 전제하에 글을 씁니다.
- 어째서 이런 글을 쓰는가.
- 일반 응용 프로그램은 디버거에 의해서 실행거나, 이미 실행중인 프로세스 ID를 알아내 디버가 달라붙는?(attach) 방식으로 디버깅을 합니다. 그러나 ISAPI Filter를 디버깅 하려면 IIS의 구조를 조금 더 알아야 가능 합니다.
- 디버깅 한다고 고생을 조금 했기 때문에 글로 기록을 남기고 싶어서.
- 준비물
- 디버거 (Visual Studio 를 이용했음)
- IIS 서버 (Windows vista의 IIS 7.0을 이용했음)
- ISAPI Filter (자체 개발중인 것을 이용함)
- ISAPI Filter는 디버깅은 어떻게 하나?
- IIS 서버는 직접적으로 ISAPI Filter를 호출하지 않는다. 때문에 현재 프로세스 목록을 뒤져보아도 실제 ISAPI Filter의 PID는 찾아 볼 수 없다.
- ISAPI Filter 를 불러다 쓰는 녀석은 IIS의 부 프로세스인 worker라는 녀석이다.
- %windir%\system32\inetsrv\w3wp.exe 라는 녀석이 worker.
- 나름 친절하게도 만들어져 있으므로 -debug 옵션을 주어 실행하면 디버그 모드로 실행하게 되어 있다. (ISAPI Filter를 디버깅 할 것이므로 이것은 중요하지 않은 듯.)
- 이제 일반적으로 사용하는 디버깅 방법(이녀석을 실행하거나 이 녀석에 attach)을 이 바이너리에 대해서 적용하면 된다.
- 알아야 할 사항
- IIS의 웹사이트 설정을 보면 worker 프로세스에 대한 작동 방식이 있다. 디버깅을 하는데에 이것과 연관이 있을 수도 없을 수도 있다.(자세히 생각해보지 않음.)
- IIS는 ISAPI Filter가 적용된 URL에 대해서 요청을 받지 않는 이상 worker 프로세스를 생성하지 않으므로 worker를 따로 만들지 않는 경우에는 브라우저로 한번 이상의 요청을 날려봐야한다.
- worker를 위의 실행파일을 실행하여 생성하는 경우에는 net stop w3svc 등의 명령으로 IIS의 web 서비스를 종료시켜야한다.