Windows , IIS

윈도우 오류 보고

SungWookKang 2015. 7. 16. 19:06
반응형

윈도우 오류 보고

  • 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

 

 

반응형