윈도우 오류 보고
- Windows Server 2008
윈도우 오류 보고 (Windows Error Reporting)는 유저모드 프로세스 크래시와 커널모드 시스템 크래시 모두를 자동으로 전송한다.
윈도우 오류 보고는 제어판에서 [문제 보고서 및 해결 방법 – 설정 변경]에서 또는 [시작-실행]에서 Wercon.exe 명령으로 구성 할 수 있다.
Windows Error Reporting Service 서비스가 실행 중이어야 한다.
디폴트로 구성된 시스템에서는 오류 보고서(미니덤프와 프로세스 내에 로드된 DLL 버전 번호 같은 여러 세부 정보를 가진 XML 파일)가 마이크로소프트 온라인 크래시 분석 서버로 전송 된다. WER 서비스는 문제에 대한 해결책을 통지 받으면 사용자에게 문제 해결을 위해 취해야 할 단계를 알려주는 툴팁을 표시 한다.
인터넷에 연결되지 않은 시스템이거나 관리자가 마이크로소프트에 보낼 오류를 관리하는 시스템환경인 경우 오류 보고서의 목적지를 내부 파일 서버로 구성할 수 있다. 이 툴셋은 윈도우 오류 보고 시스템에 의해 생성된 디렉터리 구조를 이해하고 관리자에게 선택적인 오류를 보고 할 수 있는 옵션을 제공해 마이크로소프트로 오류를 보낼 수 있는 기능을 갖추고 있다.
윈도우 비스타 이전까지는 여태껏 기술한 모든 동작은 크래시 스레드의 컨텍스트내(초기에 설정된 미처리 예외 필터의 일부로서)에서 이뤄져야 했다. 특정 유형의 크래시인 경우 심각하게 손상된 스레드가 복잡한 이런 동작을 수행하기란 불가능하다. 따라서 미처리 예외 필터 자체가 크래시된다. 이렇게 프로세스가 표시 없이 죽을 경우 그런 내용이 어디에도 로깅되지 않는다.
비스타 이후 버전은 미처리 예외 필터가 크래시 된다면 손상된 스레드의 외부에서 작업을 수행함으로써 WER 메커니즘을 개선 하였다.
WER에는 사용자가 그룹 정책 편집기를 이용하거나 레지스트리를 수동으로 변경함으로써 커스터마이징할 수 있는 여러 설정이 존재 한다.
설정 | 의미 | 값 |
ConfigureArchive | 아카이브 데이터 사용 | 인자는 1, 모든 데이터는 2 |
Consent\DefaultConsent | 동의에 필요한 데이터 종류 | 임의의 데이터 1, 인자만은 2, 인자와 안전한 데이터 3, 모든 데이터 4 |
Consent\DefaultOverrideBehavior | DefaultConsert가 WER플러그인 동의 값을 오버라이드 하는가? | 1은 오버라이브 가능 |
Consent\PluginName | 특정 WER 플러그인의 동의 값 | DefaultConsent와 동일 |
CorporateWERDirectory | 기업 WER 저장소의 디렉터리 | 경로를 포함하는 문자열 |
CorporateWERPortNumber | 기업 WER 저장소에 사용되는 포트 | 포트 번호 |
CorporateWERServer | 기업 WER 저장소에 사용되는 이름 | 이름을 포함하는 문자열 |
CorporateWERUseAuthentication | 기업 WER 저장소에 윈도우 통합 인증 사용 | 1은 내장된 인증을 활성화 |
CorporateWERUseSSL | 기업 WER 저장소에 SSL 사용 | 1은 SSL활성화 |
DebugApplication\ExeName | Debug와 Continue를 사용자가 선택해야 하는 애플리케이션 목록 | 애플리케이션 목록을 포함하는 문자열 |
DesableArchive | 아카이브가 활성화 되는가? | 1은 아카이브 비활성화 |
Disabled | WER이 비활성화 인가? | 1은 WER 비활성화 |
DisableQueue | 보고서가 큐잉되어야 하는지 결정 | 1은 큐잉 비활성화 |
DontShowUI | WER UI를 활성화 또는 비활성화할 것인가? | 1은 UI 비활성화 |
DontSendAdditionalData | 추가적인 크래시 데이터 전송을 하지 않는다. | 1은 보내지 않는다 |
ExcludedApplication\AppName | WER에서 제외된 애플리케이션 목록 | 애플리케이션 목록을 포함하는 문자열 |
ForceQueue | 보고서가 사용자 큐로 보내져야 하는가? | 1은 사용자 큐로 보내져야 한다 |
LocalDumps\DumpFolder | 덤프 파일을 저장할 경로 | 경로를 포함하는 문자열 |
LocalDumps\DumpCount | 경로에서 덤프 파일의 최대 수 | 개수 |
LocalDumps\DumpType | 크래시 중에 생성할 덤프 유형 | 0은 커스텀 덤프, 1은 미니덤프, 2는 풀덤프 |
LocalDumps\CustomDumpFlags | 커스텀 덤프인경우 커스텀 옵션을 지정 | MINIDUMP_TYPE에 정의된 값 |
LoggingDisabled | 로깅을 활성화 또는 비황성화 | 1은 로깅 비활성화 |
MaxArchiveCount | 아카이브의 최대 크기(파일로) | 1~5000 사이의 값 |
MaxQueueCount | 큐의 최대 크기 | 1~500 사이의 값 |
QueuePesterInterval | 해결 방법을 사용자가 확인하게 요청하는 날짜 간격 | 날짜 수 |
WER 서비스는 크래시된 프로세스와 통신을 위해 ALPC 포트를 사용한다. 이 메커니즘은 함수에서 윈도우 예외 디스패칭 설계에 항상 있어왔던 표준 예외 포트 메커니즘으로 확장되었다. 결과적으로 윈도우의 모든 프로세스는 WER 서비스가 등록한 실제로는 ALPC 포트객체인 오류 포트를 가진다.
윈도우 비스타 이전의 오류 보고 메커니즘이 처리할 수 없었던 전형적인 크래시 중 하나는 스택 손상 이었다. 이것은 크래시된 스레드의 스택이 손상돼(심하게는 메모리 할당이 해제 된 경우)새로운 함수를 호출하는 것도 또 다른 크래시를 유발하게 되어 커널이 프로세스를 종료하게 된다. 윈도우 비스타 이후에는 WER 서비스를 일시적으로 오프시킨 후 다시 활성화 하면 이 동작을 살펴 볼 수 있다.
[참고자료]
Windows Internals
'Windows , IIS' 카테고리의 다른 글
커널모드 시스템 디스패칭과 서비스 디스크립터 테이블 (0) | 2015.07.16 |
---|---|
32비트, 64비트 시스템 서비스 디스패칭 (0) | 2015.07.16 |
처리되지 않은 예외 (0) | 2015.07.16 |
예외 디스패칭 (0) | 2015.07.16 |
비동기 프로시저 호출 인터럽트 (0) | 2015.07.16 |