원문 : http://blogs.msdn.com/ntdebugging/archive/2009/08/27/etw-introduction-and-overview.aspx
본 글은 연속성이 결여된 번역 작업과 제 허접한 영어 및 컴퓨팅 시스템에 대한 이해도로 인한 오역이 다소 존재 할 수 있습니다.
본 글의 모든 권리는 원문 저자에 있습니다.

소개

윈도우 이벤트 추적기(ETW)는 시스템과 소프트웨어 진단 문제해결 그리고 성능 모니터링을 위한 윈도우즈의 컴포넌트죠. (윈도우 2000 부터 사용되었습니다.) 하지만 윈도우 비스타 이전까지는 메이저 급 컴포넌트는 아니 였습니다. 하지만 윈도우 비스타 부터는 메이저 급 컴포넌트로 급부상 한 것은 물론 이 ETW 추적을 아주 빈번하게 이용하게 돼었습니다. (물론 이전 보다 더 실용적이고, 유용하게 돼었으니깐요…)

ETW는 아래를 포함한 여러가지 시나리오에서 유용합니다.

- 유저와 관리자 : 시스템을 운영하고, 시스템에 무슨일이 일어나고 있는지 알 수 있습니다.
- 유저와 관리자 : 성능 및 하드웨어 OS 문제를 해결합니다.
- 매니아 : OS 및 OS 내부에 대한 커널 레벨 수준의 지식을 습득할 수 있습니다.
- 소프트웨어 개발자 / ISV / OEM : 개발된 소프트웨어 와 마이크로소프트 OS 및 기술간에 발생하는 여러 이슈에 대한 추적을 할 수 있습니다.
- 하드웨어 개발자/IHV/OEM : 개발된 하드웨어 와 OS (커널 및 디바이스 서브시스템에서 유저 스택을 포함) 간에 발생하는 여러 이슈들에 대한 추적을 할 수 있습니다.

ETW는 OS 내부의 아주 밑단까지도 들여다 볼 수 있는 현재의 도구들 및 기술의 집합체입니다.

2007년 4월 MSDN 메거진에 ETW에 대한 아주 깊은 지식 까지 다루고 있는 좋은 기사(http://msdn.microsoft.com/en-us/magazine/cc163437.aspx )가 있습니다. 한번 읽어 보시길 부탁 드립니다. 

아래 ETW의 인프라스트럭처에 대한 Overview 를 보면 어떻게 프로바이더들이 메모리 버퍼의(버퍼들은 메모리의 서큘러 버퍼에 있거나 디스크에 순차적 또는 원형 패션으로 기록됩니다.) 높은 성능을 기록하는지를 알 수 잇습니다.

원문 : http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx
본 글은 연속성이 결여된 번역 작업과 제 허접한 영어 및 컴퓨팅 시스템에 대한 이해도로 인한 오역이 다소 존재 할 수 있습니다.
본 글의 모든 권리는 원문 저자에 있습니다.

2009년 11월 3일을 마지막으로 시스인터널의 NewSID(Machine Security Indentifire / machine SID 를 변경하는 유틸리티)는 역사의 뒤안길로 사라졌습니다. 전 1997년에 NewSID를 NTSID라는 이름으로 개발했습니다. 그 당시에는 MS의 Sysprep 라는 유일한 SID 변경 툴이 있었지만, 그 마저도 어플리케이션이 설치된 이후에는 쓸 수가 없었습니다. 머신 SID는 Windows 설치 시 생성되는 식별자로써 Windows에서는 관리자가 생성한 로컬 계정과 그룹 SID의 기본값으로 사용하게 됩니다. 사용자가 로그인하게 되면 사용자는 시스템은 사용자 계정의 SID와 그룹 SID를 통해 시스템상의 각종 오브젝트의 접근 권한을 체크합니다. 만약 2개의 머신이 동일한 SID를 가지고 있다면 계정이나 그룹의 SID 역시 동일할것입니다. 이 때문에 동일한 SID를 갖는 다수의 컴퓨터들은 보안상 문제를 야기할 수 있겠죠? 그렇지 않을까요? 이것이 바로 우리가 전부터 알던 지식이였습니다.

사람들은 Windows Vista에서 NewSID를 유용하게 사용한다고 했지만 내 스스로 NewSID를 완벽하게 테스트 하지도 못했고, 종종 NewSID 적용 이후 Windows의 일부 컴포넌트들이 실패를 한다는 애기를 듣고 NewSID를 은퇴시키기로 마음 먹었습니다. 차분하게 않아 레포트를 들어다 보면서 전 모두가 알고있는 “SID가 중복되면 문제가 일어난다” 부터 차분하게 다시 생각하기 시작했습니다. 차분하게 생각하고 생각한 결과 SID 중복은 문제가 아닐 수 있다는 확신을 갖게 되었습니다. 다른 말로 동일한 SID를 갖는 머신들이 있더라도 별 보안상의 문제가 아니라는 것이죠. 전 윈도우 개발팀과 보안팀과 함께 위와 같은 결론을 냈는데, 우리 중 누구도 도메인이나 Workgroup 환경에서 SID 중복이 문제를 일으키는 시나리오에 대한 증명을 하지 못했습니다. 이게 발로 NewSID가 역사의 뒤안길로 사라지게 된 이유입니다.
윈도우즈 NT의 시작부터 이미지 형태의 배포에서 신념처럼 SID를 변경했었는데 이 SID의 중복이 별 문제가 없다는 것은 정말 엄청난 충격으로 다가왔다. 본 포스트는 이 SID의 중복과 관련된 신화의 실체를 폭로할 것이다. 우리는 먼저 머신 SID의 표현 방식에 대해 알아보고 어떻게 윈도우즈에서 SID를 사용하는지 그리고 단하나의 예외 상황까지 모두 보여줄 것이다.
윈도우즈는 절대 자신의 머신 SID를 외부에 노출하지 않는다. 이는 바로 시스템이 중복 SID를 갖더라도 무방하다는 증거가 된다. Sysprep는 머신의 특정한 상태를 리셋한다는 것을 기억하자 물론 이 SID가 중복이 된다면 특정 어플리케이션(Windows 서버 업데이트 서비스와 같은)에서는 문제가 될 수 있다. 그래서 여전히 마이크로소프트는 복제 이미지 기반의 배포등을 이용할때는 Sysprep를 통해 SID를 유니크하게 만들어 줄것을 권고하고 있다.

SIDs
윈도우즈는 단지 머신 뿐만이 아닌 모든 보안 Principle들을 표현하기 위하여 SID를 사용한다. 보안 Principle은 머신과 도메인 환경의 유저와 사용자 그리고 보안 그룹들을 모두 포괄하는 개념이다.
이름이라는 건 단지 SID를 사용자 편의에 맞춰 표현해 놓은 것에 불과하다. 이름을 변경한다고 해도 이미 ACL에서 계정의 변경된 부분을 반영하고 있기 때문에 굳이 ACL을 변경해 줄 필요는 없습니다. (역 주 : 왜냐하면 내부적으로는 SID를 이용하여 ACL을 정의 하기 때문에 이름이 변경되도 이 SID는 변경되지 않습니다.)

SID는 가변길의 숫자 값들로 이루어져 있는데, 이는 스트럭처 리비전 번호와 48비트의 아이텐티파이어 오소리티 값 그리고 가변길이의 32비트 서브오소리티값과 RID로구성되어 있습니다. 이 authority 값을 통해 SID를 발급하는 에이전트를 구분하게 됩니다. 이런 에이전트는 일반적으로 윈도우즈의 로컬 시스템이거나 도메인이 됩니다. (역 주 : SID의 앞단의 indetifier authority를 에이전트라고 부르는데, 이값을 기본으로 SID가 구성되게 되기 때문에 에이전트라 하고 있습니다.) 그리고 subauthority 값을 통해 issuing authoriy 와 연관되어 수탁받은 권한들을 확인하며, RID는 윈도우즈에서 base SID를 통해 유니크한 SID를 만드는 간단한 방법을 제공합니다.

여러분은 Sysinternals 의 PsGetSid 툴을 단순히 실행 하는 것만으로 머신의 SID를 확인 할 수 있습니다.

보시면 리비전 넘버가 1번이고 오소리티는 5번 입니다. 그리고 4개로 이루어진 서브오소리티 값들이 있습니다. 중요한 점은 윈도우즈 엔티가 머신의 SID가 네트워크상의 아이덴티피케이션으로 사용될 수 도 있다는 염두를 해 두고 디자인 됐다는 점입니다. 즉 이 아이텐디티의 유일성을 보장하기 위하여 1개의 (21) 고정된 서브오소리티 값과 3개의 렌덤하게 생성된 값이 만들어지게 됩니다. (S-1-5-21 뒤에 나오는 숫자들)

첫번째 유저를 만들지 않았더라도 윈도우즈는 몇개의 빌트인 유저 및 그룹들을 정의해놓고 있는데 이 속에는 administrator 나 Guest 계정들이 포함되어 있습니다. 윈도우즈는 위와 같은 유저들을 위한 렌덤한 SID 생성 대신에 각 유저마다 RID라 불리는 간단한 유니크한 숫자들을 SID에 추가로 붙여 각 계정의 SID의 유일성을 보장하게 됩니다. 위와 같은 유저들은 RID이 이미 정의 되어 있습니다. 예를 들어 Administrator의 경우 RID는 항상 500이 되게 되죠.

설치가 끝난 후 새로운 계정이나 그룹의 RID는 1000부터 시작하게 됩니다. 여러분은 PsGetSid를 통해 특정 계정의 SID를 확인 할 수 있는데, 아래 그림의 Abby 계정(윈도우즈 설치 과정에서 관리자 권한으로 생성한 계정)의 RID는 1000임을 볼 수 있습니다.

추가적으로 윈도우즈가 먼저 정의해놓은 SID들중 RID를 사용하지 않는 녀석들도 있습니다. 예를 들자면 Everyone 그룹이 이에 해당하는데 이 Everyone은 모든 윈도우즈 시스템에서 S-1-1-0의 SID를 갖습니다.

또다른 예로 로컬 시스템 계정 (System) 역시 마찬가지 입니다. (시스템 프로세인 SMSS.exe 나 Services.exe, Winlogon.exe 를 실행 시키는 계정)

SIDs and Access Control Lists

Local Security Authority Subsystem (LSASS -Lsass.exe) 은 계정이 윈도우에 로그인 할 때 로그온 세션과 토큰을 만듭니다. 이 토큰은 윈도우의 커널 정의한 구조체인데, 이 토큰은 계정과 해당 시점에 인증된 이 계정의 SID 및 해당 시점에 인증된 그룹의 SID 그리고 계정과 그룹 할당된 보안 권한 등을 나타냅니다. 로그온 세션에서 참조하고 있는 마지막 토큰이 삭제되면 LSASS는 로그온 세션을 삭제하고 유저는 로그 오프 한 것으로 추정되게 됩니다. 아래는 시스인터널스의 LogonSession 유틸리티로 본 제 인터렉티브 로그인 세션입니다.

여러분은 아래와 같이 프로세스 익스플로어의 핸들 뷰를 통해 세션을 위해 할당된 토큰을 확인 할 수 있습니다. 계정 명 뒤에 따라오는 번호 (7fdee) 를 기억하시고 이를 LogonSessions의 로그인한 세션의 ID와 맞춰 보시기 바랍니다.

기본적으로 프로세스들은 부모 프로세스의 토큰을 상속 받습니다. 예를 들어 인터렉티브 세션에서 동작하는 모든 프로세스는 Userint.exe 프로세스로(인터렉티브 로그온을 위해서 Winlogon.exe 가 생성한) 부터 상속된 토큰의 카피를 갖게 되는 것이죠. 여러분은 프로세스 익스플러어의 프로세스를 더블 클릭한 화면의 보안 탭을 통해 해당 내용을 확인 할 수 있습니다.

제 프로세스 중 하나가 OS object (파일, 레지스트리키 와 같은) 을 오픈 하면 보안 서브 시스템은 퍼미션 체크를 진행 합니다. 퍼미션 체크란 해당 오브젝트의 엑세스 컨트롤 리스트 (ACL / 프로세스 토큰의 SID를 참조)의 항목들에 대한 내용을 확인 하는 것을 의미합니다.

이와 유사한 확인은 원격 컴퓨터의 공유의 net use 를 통해 생성된 외부 로그온 세션에서도 확인 할 수 있습니다. 공유된 자원을 사용하기 위해서는 해당 외부 시스템이 확인 할 수 있는 계정을 통해 해당 시스템으로 부터 인증을 받아야 합니다. 만약 그 환경이 워크 그룹이라면 여러분은 해당 리모트 (외부) 시스템의 로컬 계정이여야 하고, 만약 도메인 환경이라면 여러분은 해당 리모트 시스템의 로컬 계정이거나 도메인 계정이여야 합니다. 여러분이 공유되어 있는 파일에 접근을 하게 되면 해당 시스템의 파일서버 드라이버는 로그온 세션의 토큰을 이용하여 권한을 확인하게 됩니다. 이런 레버리징 메커니즘을 임퍼스네이션이라고 부릅니다.

SID Duplication

마이크로소프트에서 제공하는 유일한 이미지 기반의 윈도우 배포 방법은 이미지로 윈도우를 배포한 후에 Sysprep 툴을 실행 하는 것입니다.  이를 이미지를 제네럴라이징 한다고 부르는데 그 이유는 여러분이 이 이미지로 만들어진 윈도우를 부팅할 때 Sysprep 이 새로운 SID 생성 및 PnP 하드웨어 디텍션, 제품 엑티베이션 클락 리셋, 컴퓨터 이름과 같은 데이터를 설정 진행하기 때문입니다.

어떤 IT 담당자들은 하나의 시스템에 어플리케이션을 설치하고 설정을 변경한 후 SID를 리셋 없이 이에 대한 카피본을 사용하는 경우가 있습니다.  지금까지 가장 좋은 방법은 NewSID와 같은 툴로 SID를 리셋하는 것이였습니다. 이 유틸리티는 새로운 머신 SID를 생성하고 파일 시스템과 레지스트리등의 ACL을 확인하여 모든 SID를 새로운 머신의 SID로 업데이트하는 역활을 했습니다. 마이크로소프트에서 Sysprep와는 다른 이런 방식의 시스템 변경을 지원하지 않았던 이유는 윈도우즈에서 감추고 있는 모든 머신 SID에 대한 참조를 알 수 없었기 때문입니다. 이러한 이유로 새로운 머신 SID와 이전의 변경되지 않는 SID가 공존하는 환경에 대한 안정성 및 보안은 게런티가 될 수 없는거죠…

자 같은 SID를 갖는 다수의 컴퓨터들은 문제가 될까요?  딱 한가지 윈도우들이 다른 컴퓨터의 머신 SID를 참조한다면 문제가 될 수도 있을 것입니다. 예를 들어 만약 여러분이 리모트 시스템에 접근할때 로컬 머신의 SID가 리모트 머신으로 전달 되고 이를 이용하여 권한을 체크한다면 시스템은 외부의 인바운드 계정과 로컬 머신의 같은 SID를 같는 로컬 계정을 구분할 수 없어 문제가 발생 하게 됩니다. (이 양 계정의 SID는 동일한 머신 SID 를 기반으로 동일한 RID를 갖고 있습니다.) 그러나 검토한 결과로는 윈도우즈는 여러분이 자신의 로컬 컴퓨터 만이 확인 할 수 있는 계정을 가지고 다른 컴퓨터로부터 인증을 받는 것을 허용하지 않습니다. 대신에 여러분은 리모트 시스템의 로컬 계정이나 리모트 컴퓨터가 트러스트한 도메인의 도메인 계정의 크리덴셜을 이용하여야 합니다. 리모트 컴퓨터는 SID를 조회하는데 로컬 계정의 경우 Security Accounts Database (SAM) 부터 조회하고, 도메인 계정인 경우 DC의 Active Directory 데이터 베이스로부터 조회합니다. 리모트 컴퓨터는 절대 연결되는 컴퓨터의 머신 SID를 참조 하지 않습니다.

즉 컴퓨터에 엑세스 하는 궁극의 방법은 SID가 아니라 계정 명과 패스워드입니다.. 간단히 말해서 리모트 시스템 계정의 SID를 알아 봤자 컴퓨터나 해당 머신 상의 어떤 자원에 대한 접근도 할 수 없고,. 좀더 들어가 보자면 SID는 충분한 인증 정보가 아닙니다. 기억하겠지만 Built – in 계정의 경우 모든 컴퓨터에서 동일한 SID 값을 갖기 때문에 만약 이게 가능하다면 이것 보안상의 아주 큰 문제가 되는 것이죠.

이전에 제가 언급했던 딱 하나의 예외는 DC들 자신들에 대한 것입니다. 모든 도메인은 도메인 셋업 시 유니크한 도메인 SID를 생성합니다. 그리고 모든 도메인 DC의 머신 SID는 도메인 SID로 매치 되게 됩니다.  이는 어떤 의미에서는 서로의 머신의 SID를 참조하는 것이죠. 이는 모든 도메인의 멤버 컴퓨터의 머신 SID는 DC의 머신 SID나 도메인의 SID와 절대 동일 할 수 없다는 것을 의미합니다. 그러나 각각의 DC 역시 멤버 컴퓨터들 처럼 도메인 내에서 컴퓨터 계정을 지니고 리모트 시스템에 접근할 경우 인증을 받아야 합니다.

몇몇의 SID 중복에 대한 아티클들을 보면 (KB 314828을 포함하여) 동일한 SID를 갖는 다수의 컴퓨터를 사용할 경우에 대한 우려를 제기하고 있습니다. (NTFS-formatted firewire disk와 같은 이동식 미디어의 경우 로컬 계정을 이용하여 Secure 할 수 없는 등의 / 역 주 왜냐하면 이동식 디스크의 ACL의 SID 값이 일부 계정의 경우 동일 하기 때문에 직접 다른 머신의 로컬로 붙을 경우 로컬 계정에 대한 혼선이 있을 수 있습니다.) 하지만 이는 기우에 불과합니다. 왜냐하면 이동식 미디어들은 보안에 대한 고려 자체가 없기 때문입니다. 왜냐하면 자 NTFS를 지원하지 않는 운영체제에서 해당 데이터에 접근한다고 생각합시다. 그 경우 사용자는 아무런 제약 없이 해당 리소스를 접근할 수 있지 않습니까? 게다가 이동식 미디어의 경우 administrators 그룹과 같이 모든 시스템에서 잘 알려진 SID에 대해서는 기본적인 접근 권한을 할당하고 있습니다. 이는 물리 보안과 윈도우즈 7에서 소계된 Bitlocker-to-go(이동식 스토리지의 데이터를 암호화하는)의 기본 개념입니다.

마지막 케이스로 만약 Distributed application 이 머신 SID을 고유 식별자로 사용한다면 문제가 될 수 도 있습니다. (예를 들어 모든 컴퓨터들이 사용하는 어플리케이션인데 이 어플리케이션들을 식별하기 위하여 머신의 SID를 사용하는 경우) 하지만 어떤 마이크로소프트의 소프트웨어도 이런 방식은 사용하지 않으며 머신 SID 역시 이런 일을 위해서 만들어 진 것이 아닙니다. 그리고 동일한 SID를 같은 DC들의 경우에는 이와 같은 경우 아예 제대로 동작하지 않는다고 봐야 합니다. 고유의 컴퓨터 식별자에 기반을 둔 소프트웨어는 컴퓨터의 이름이나 컴퓨터의 도메인 SID들을 이용하게 됩니다. (도메인 상의 컴퓨터 계정의 SID)

The New Best Practice

SID 중복에 관한 이슈가 꽤 오랫동안 제기 되지 않은 것은 좀 놀랄 만한 사실입니다. 정작 문제는 모든 사람들이 누군가는 정확히 알고 있을 꺼라 생각하고 있었다는 것입니다.. 제가 진짜 억울한 것은 NewSID가 어느짝에도 쓸모가 없었다는 것이고, 그게 바로 NewSID가 역사의 뒤안길을 밟더라도 아쉬워할 일 없다는 것 입니다. 기억하시기 바랍니다. Sysprep는 머신 설정을 재 리셋 해줍니다. (만약 이런 설정들이 중복된다면 WSUS 와 같은 어플리케이션에서는 문제를 일으킬 수 있습니다.)  그래서 마이크로소프트의 지원 정책은 여전히 복제 시스템에서는 Sysprep를 통해 유니크하게 만들어라 입니다.

너무 좋은 자료를 찾았습니다.

Windows가 시작하게 되면 사용자는 세션을 할당 받습니다.
물론 터미널로 접속하게 되도 세션을 할당 받죠.
각 세션에는 직접 사용자의 입력을 받기 위한 WinSta0 라는 스테이션이 존재 하고, 이 하단에는 3가지 데스크 톱 (Default, Disconnect, Winlogon)이 존재 합니다.

WinSta0 스테이션은 Win32k.sys 드라이버를 통해서 호출되게 됩니다.
그런데 여러분도 아시다시피 사용자와 인터럭티브하게 (메세지를 주고 받을려면) 통신 하는 쓰레드는 Windows 객체가 필요 한 거죠.

결론적으로 이 WinSta0 와 Desktop에 대한 이해가 있다면 사용자에 대한 세션 할당에 대해서 조금은 더 알 수 있는 기회가 되지 않을까 합니다.

여기에 대한 아주 좋은 글이 있어서 링크를 슬며시 올립니다.
링크 : http://blogs.msdn.com/coreinternals/archive/2009/08/19/session-window-station-desktop.aspx

입력 파라미터 받기

If (Wscript.Arguments.Count < 1) Then 
    Wscript.Echo "Required Parameter missing" 
    Wscript.Quit 
End If
strName = Wscript.Arguments(0)   
Wscript.Echo strName

CMD 실행 하기

Dim oShell
Set oShell = WScript.CreateObject ("WScript.shell")
oShell.run "cmd /c echo " & "hi"
Set oShell = Nothing

배열을 이용하여 파일 읽기 각 항목 저장하기

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("\\sldc.sl.lab\print\g.txt", ForReading)

Const ForReading = 1
Dim arrFileLines()
i = 0
Do Until objFile.AtEndOfStream
    Redim Preserve arrFileLines(i)
    arrFileLines(i) = objFile.ReadLine
i = i + 1
Loop
objFile.Close

On Error Resume Next

For Each strLine in arrFileLines
    WScript.Echo strLine
Next

원문 : http://blogs.technet.com/josebda/archive/2009/10/31/scary-sql-server-stuff-tombstones-phantoms-blobs-ghosts-and-zombies.aspx

본 포스트는 할로윈의 정신과 SQL Server를 향한 열정을 담고 있어

당신은 SQL Server의 공포영화와 같은 소소한 부분들을 알고 있는가? SQL Server의 지식도 태스트 하고 즐거운 할로윈 게임도 즐길 겸 아래의 SQL Server에 관련된 몇가지 상황에 답해 보도록해!
만약 어렵다면 링크를 따라가던가...

- Tombstones
녀석은 너의 사라진 데이터에 대한 표시라 할 수 있지. 만약 네가 그들을 지키지 못한 다면 너의 미팅은 죽지 못한채로 끝나게 될것이야...
http://msdn.microsoft.com/en-us/library/ms186771.aspx
- Phantoms
그들은 보이지만 존재하지는 않지. 이러한 유령같은 쿼리들은 적절한 격리 설정을 통해 피할 수 있어.
http://msdn.microsoft.com/en-us/library/ms186771.aspx
- Deadlocks
Hairy 트렌젝션들이 서로 충돌할때 이상한 일이 일어나곤해. 만약 그들 중 하나가 당신 주위를 감싸고 있다면, 네가 바로 희생자가 될 수도 있어. 
http://msdn.microsoft.com/en-us/library/ms178104.aspx
- Blobs
오, 당신의 데이터베이스의 생기를 모두 빨아들이는 엄청난 일을 하는 악몽과 같은 놈... 네가 할 수 있는 일 이 물줄기를 눌려서 줄이는 수 밖에... 
http://msdn.microsoft.com/en-us/library/3517w44b.aspx
- Kill.
왜 데이터베이스는 이런 명령어를 필요로 하는 걸까? 그래... 확인해 보독해 넌은 필요치 않는 명령을 수행했을지도 몰라.
http://msdn.microsoft.com/en-us/library/ms173730.aspx
- Crypt properties.
데이터베이스의 보안을 위하여 사용하는 기술로써 절대로 키를 분실 하지 않도록 하길 바래
http://msdn.microsoft.com/en-us/library/ms189536.aspx
- Hash Match.
이는 누가 가장 빠른 공포인가를 확인하기 위한 경쟁이 아니야.
http://msdn.microsoft.com/en-us/library/aa237090.aspx
- Drop user.
결국 모든 사용자는 영원할 수 없어.
http://msdn.microsoft.com/en-us/library/ms189438.aspx
- Ghost rows.
모든 유령군대는 완벽하게 정렬하고 있나? 실제로는 그렇지 않아. 
http://msdn.microsoft.com/en-us/library/ms188436.aspx
- Zombie rowsets.
좀비가 없는 할로윈은 할로인이라 할 수 없지.
http://msdn.microsoft.com/en-us/library/aa258325.aspx
- Execute reader.
누구나 당신의 데이터를 읽을 수 있다는 저주처럼 들리지만, 실제로는 이는 유용하고 빠릅단 말이야...
http://msdn.microsoft.com/en-us/library/9kcbe65k.aspx
- Shadow Copies.
들리는 만큼 무섭지는 않지만... 네 데이터가 문제에 빠지고 있거나, 네가 이 Shadow Copy를 가지고 있지 않을때, 더욱 무섭게 다가올 것이야.
http://msdn.microsoft.com/en-us/library/cc966520.aspx
- Nested Triggers.
옥상에서 당신을 쏘기 위해 기다리고 있는 저격수 같은 놈이지. 하지만 이 이상 설명하기는 어려워... http://msdn.microsoft.com/en-us/library/ms190739.aspx
- RIP.
이는 비문이 아니야. 이는 당신이 접근할 수 있는 접근 레벨을 명확히 하고 또한 준수할 수 있도록 도와주는 방법이지.
http://msdn.microsoft.com/en-us/library/bb326650.aspx
물론 많은 마법사들이 곧곧에 있지...
당신도 알고 있는게 있다면 블로그 포스트의 코멘트를 통해서 공유해주기 바래

PS 카렌 아줌마의 아무 끔찍한 결과를 초래하는 Halloween Problem (http://en.wikipedia.org/wiki/Halloween_Problem) 에 대해서도 기억하고 있지. 현재의 SQL Server와는 관계 없지만 SQL Server 7과 관련이 있었던... http://support.microsoft.com/kb/248441.

Happy Halloween! 흠하하하하!

제 블로그 통계를 보니 NTLDR에 대해 궁금해 하는 분들이 꽤 많이 찾아오셨군요.
그래서 오늘은 이전 http://maystyle.tistory.com/463 에 이어서 글을 씁니다.
(제 미비한 영어 실력으로 인해 저자의 원 글을 100% 완역이 불가능하여 나름대로 해석하여 글을 씁니다. 잘못된 내용이 있을 가능성이 많으니 지적해 주시기 바랍니다.)

저번에는 POST 과정과 디스크 초기화 까지 다뤘죠?
디스크 초기화에서는 부팅 파티션을 찾아서 실행을 위한 정보까지를 준비해 줍니다.
자 이제 NTNDR 차례가 왔습니다. (Windows Vista 이후 버전에서는 winload.exe 로 변경 되었습니다.)

원문 : http://blogs.msdn.com/ntdebugging/archive/2007/06/28/how-windows-starts-up-part-the-second.aspx

이번에는 부트 로더 단계에 대해 이야기 하도록 하겠습니다. 이전에 다뤘던 내용을 한번 다시 상기해 보도록 하겠습니다. 먼저 컴퓨터는 POST 과정을 거친 후, MBR 코드를 실행 합니다. 해당 MBR의 활성 파티션을 정보를 확인 한 후 활성 파티션의 부트 섹터 코드를 실행 하고, NTLDR을 메모리에 로드 합니다.

부트 로더 단계는 NTLDR 실행 시 시작하게 됩니다.

1. NTLDR 은 프로세서를 Real mode 에서 32비트 flat memory mode로 변경합니다.
NTLDR은 16비트 컴포넌트(프로세서의 Protected mode 변환을 담당) 와 32비트 컴포넌트 (NTLDR의 나머지 Role들 담당) 로 이루어져 있습니다.

NTLDR은 Processor는 Real-Mode로 불리는 x86 실행 모드에서 실행됩니다. Real-Mode 에서는 가상 메모리 주소 변환이 일어나지 않습니다. 이는 모든 메모리 주소가 16bit 세그먼트 및 offset 포맷을 사용함을 의미합니다. 즉 이때는 오직 1MB 의 물리 메모리만이 접근 가능합니다. (16bit 세그먼트 주소 64KB 까지 표현할 수 있는 공간에 추가로 4bit offset이 붙어서 1MB까지 메모리 접근 공간이 확장됨) NTLDR은 이 Real-Mode 에서 Protected-Mode (32bit 메모리 접근 가능)로 CPU를 변환합니다.

*Trivia Alert* Protected-Mode로 들어가기전 우리는 A20 라인을 활성화 합니다. (시스템 bus 중 21번째 라인을 말함) IBM 친구들은 제가 무슨 말을 하는지 알 것입니다.

여전히 가상 메모리 주소 변환은 일어나지 않지만, 4GB의 물리 메모리에 대한 접근은 가능합니다.

2. NTLDR은 메모리 접근 및 페이징을 위한 16M 정도의 페이지 테이블을 만듭니다.

3. NTLDR은 페이징을 활성화 합니다. “Protected-Mode with Paging Enabled”는 Windows 가 정상 실행이 가능한 모드입니다.

4. NTLDR은 FAT 와 NTFS 미니 파일 시스템 드라이버를 시작합니다. 이는 부트 섹터의 파일 시스템 코드와는 다른데 NTLDR은 서브 디렉토리까지 읽을 수 있을 정도로 정교한 수준의 드라이버를 제공합니다.

Note: NTLDR에서는 IDE 장치만 지원 합니다. 즉 SCSI 장치 등은 지원 하지 않죠. SCSI 장치는 13h 인터럽트가 발생하게 되면 ntbootdd.sys 로드되어 접근이 가능하게 됩니다. ntbootdd.sys는 Windows의 미니 SCSI 포트 드라이버와 같습니다.

5. 만약 Windows 가 부팅되는 것이 아니고 이전의 hibernation 모드에서 살아나는 것이라면 NTLDR은 hibernator file (Hiberfil.sys) 를 찾게 되어 해당 내용을 메모리에 로드 하여 실행하게 됩니다.

Hyberbation 파일은 좀 흥미로운데, 일반적으로는 Hybernation이 되는 당시의 메모리 이미지를 갖고 있으나, Hiberfil.sys 다른 위치에 있는 경우 부팅 파티션의 Hiberfil.sys는 ARC Path 즉 진짜 Hybernation 파일의 위치를 가르키는 Path가 기록됩니다. ARC path 는 아래와 같은 Syntaxs를 사용합니다.

- linkmulti()disk()rdisk()partition()
- linksignature()disk()rdisk()partition()
- linkscsi()disk()rdisk()partition()

6. Hiberfil.sys가 발견되지 않은 경우 NTLDRT은 Boot.ini 단계를 실행합니다. 만약 Boot.ini에 1개 이상의 OS 및 부팅 옵션이 있는 경우 이는 부트 로더 화면에 Display 됩니다.

다음은 Windows 2000서버의 Boot.ini 샘플입니다.

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Server" /fastdetect

ARC(http://support.microsoft.com/kb/102873) 는 ‘Advanced ROSC Computing’을 의미합니다.
ARC 는 “Multi”, “SCSI” 또는 “Signature” Syntax를 사용합니다.

“Multi” Syntax는 (IDE 장치에서 유효) Windows 에서 시스템 파일을 로드하려면 컴퓨터 BIOS를 사용해야 함을 나타냅니다. 즉, 운영 체제가 인터럽트(INT) 13 BIOS 호출을 사용하여 Windows NT 부팅에 필요한 NTOSKRNL.EXE 및 다른 파일을 찾고 로드하게 된다는 것을 의미합니다.

“SCSI” Syntax는 RISC와 x86 기반 컴퓨터 둘 모두에서 사용되며 Windows의 모든 버전에서 사용됩니다. SCSI() 표기법은 Windows가 부팅 장치 드라이버를 로드하고 해당 드라이버를 사용하여 부팅 파티션에 액세스하는 것을 나타냅니다. x86 기반 컴퓨터에서 사용되는 장치 드라이버는 NTBOOTDD.SYS이며, 이 파일은 시스템 드라이브(일반적으로 C 드라이브)의 루트에 있고 사용 중인 드라이브 컨트롤러용 장치 드라이버의 복사본입니다.

“Signature” Syntax는 SCSI 문법과 구문이 동일합니다. 다만 MBR의 Signature 값을 이용하여 OS를 지정한다는 점이 차이 입니다. Signature() 문법은 다음의 조건 중 하나가 존재할 때에만 사용됩니다.

- Windows 2000이 설치된 파티션이 ~7.8 GB 보다 크거나 해당 파티션 마지막 실린더 번호가 1024 보다 크고 시스템 BIOS 또는 부트 컨트롤러 BIOS가 INT13 익스텐션을 지원하지 않는 경우
- BIOS가 사용 불가능한 SCSI 컨트롤러에 Windows 2000이 설치된 드라이브가 연결되어 있어서 INT13 BIOS 호출이 부트 과정 동안에 사용될 수 없는 경우

7. 만약 Boot.ini를 찾지 못한 경우 NTLDR은 동일 파티션의 기본 위치 (C:\Windows)에 Windows가 인스톨 되어 있는 것으로 간주하고 부팅 프로세스를 진행합니다. 만약 C:\Windows 디렉토리가 없는 경우 다음과 같은 에러메세지를 화면에 표시 합니다. “Windows could not start because the following file is missing or corrupt: \winnt root\system32\ntoskrnl.exe”

8. 만약 Boot Loader 가 화면에 표시되면 부팅할 OS를 선택하여야 합니다.
a. 만약 사용자가 Windows XP/2003 이 아닌 Windows 95/98 이나 DOS를 선택한 경우 NTLDR은 Bootsect.dos 파일을 실행합니다.
(1) bootsect.dos 파일을 찾으면 NTLDR은 해당 파일을 RAM에 로드하고 Control을 넘깁니다.
(2) (1) 단계 이후 bootsect.dos 는 IO.sys, MSDOS.sys, Command.com 등등 하위 레벨의 OS을 위한 모듈을 실행 합니다.
(3) 만약 해당 파일을 못 찾은 경우 NTLDR은 아래의 오류를 화면에 표시 합니다.
”I/O Error accessing boot sector file multi(0)disk(0)rdisk(0)partition(1): \bootsect.dos”
b. 사용자가 Windows NT 베이스의 OS를 선택한 경우 NTLDR은 Ntdetect.com 을 실행합니다.
(1) 만약 ARC 경로가 시스템에 없는 하드디스크나 파티션을 가르키면 아래와 같은 메세지를 화면에 표시 합니다.
”Windows could not start because of a computer disk hardware configuration problem.  Could not read from the selected boot disk.  Check boot path and disk hardware.  Please check the Windows documentation about hardware disk configuration and your hardware reference manuals for additional information.”
(2) Signature() 구문을 이용한 경우 MBR이 바이러스 따위로 덮어 씌워 지거나 Corrupt되어 변경되면 Boot.ini의 Signature() 값과 같지 않을 수 있고, 이 경우에는 아래와 같은 메세지도 표시될 수 있습니다.
”Windows could not start because of the following ARC firmware boot configuration problem: did not properly generate ARC name for HAL and system paths. Please check the Windows documentation about ARC configuration options and your hardware reference manuals for additional information.”

9. Ntdetect.com은 모든 지원되는 하드웨어를 Detect 하고 초기화 합니다.
(문재 해결 팁: 윈도우즈 리소스킷 시디 않의 Debug.cab 파일에는 Ntdect.chk 라는 파일이 있습니다. 이 파일의 이름을 Ntdect.com 으로 변경하고 컴퓨터를 시작하면 Detecting 되는 모듈들을 확인 할 수 있습니다.)

Ntdetect.com 은 아래와 같은 모듀을 Detect 합니다.

a)    Computer ID
b)    Bus/adapter type
c)    Video adapter
d)    Keyboard
e)    Communications ports
f)     Floppy disks
g)    Mouse or other pointing devices
h)    Parallel ports

10. Ntdetect.com 은 로딩된 하드웨어 목록을 NTLDR에 넘깁니다.

11. 만약 /SOS 스위치가 있는 경우 NTLDR은 로드 되는 드라이버들의 이름을 화면에 표시합니다. 단 해당 목록이 초기화 되어 있지는 않습니다. 단지 메모리에 로딩 되었을 뿐입니다. 종종 MUP.sys가 로드된 후 Windows 가 Hang이 걸린다는 애기를 하는데 이는 사실이 아닙니다. 단지 화면의 마지막에 표시되는 모듈일 뿐입니다. 물론 /SOS를 통해 확인 할 수 있는 리스트들은 로딩될 잠제적인 멜웨어등을 확인 하게 해주는 등 매우 유용합니다.

12. NTLDR은 Ntoskrnl.exe 와 Hal.dll를 메모리에 로딩합니다. 다시 한번 강조하지만 로딩이 초기화를 의미 하지 않습니다.

13. NTLDR은 System registry hive를 메모리에 로드합니다. 만약 Windows 가 레지스트리 하이브를 로드하지 못할 경우에는 ERD (긴급 복구용 디스크) 나 윈도우즈 복구 콘솔을 통해 Windows\Repair 또는 Windows\Repair\RegBack 폴더에서 파일을 복구해야 합니다.

14. NTLDR은 HKLM\System\Select 키를 읽습니다.
a. 만약 Last Known Good 옵션이 선택되어 있지 않으면 NTLDR은 Control Set을 이용하기 위하여, Select Key의 “Default” 값을 찾습니다.
(0x1 = ControlSet001, 0x2 = ContolSet002, 0x3 = ControlSet003)
b. 만약 Last Known Good이 선택되어 있으면 NTLDR은 Control Set 을 사용하기 위하여 Last Known Good 을 찾습니다.

15. NTLDR 은 현재 사용하고 있는 HKLM\System\Select 키에 Current 값을 셋팅합니다.

Note: 이 시점에서 NTLDR이 어떤 ControlSet을 사용할 것인지 판단 됩니다. 그러나 “CurrentControlSet”에 대한 심볼릭 링크를 초기화 전까지는 사실 상 만들어진 것은 아닙니다. (초기화는 커널 부팅 시 일어납니다.) 그래서 전 NTLDR이 사용하기로 한 Controlset을 언급하기 위하여 “Active Control Set” 을 사용하겠습니다.

16. NTLDR은 HKLM\System\*ActiveControlSet*\Control\Nls\Codepage 의 “Acp”, “Oemcp”, 과 “Oemhal” 값을 스켄합니다. 이 엔트트리들은 동일 키단의 언어 정보 테이블을 가르키는 포인터 입니다. 그리고 이 포인터 값을 찾아가 필요한 nls 파일을 로딩합니다.

코드 페이지는 특정 OS나 플랫폼의 문자열 셋입니다. 이 코드 페이지들은 문자들의 문자 코드로 구성되어 있습니다.

17. NTLDR 은 HKLM\System\*ActiveControlSet*\Control\Nls\Language 의 “Default” 값을 스켄합니다. 이 값도 역시 동일키의 언어정보 테이블을 가르키는 포인터 입니다.  NTLDR은 해당 파일을 로딩합니다. 기본 값은 L_intl.nls입니다.

18. NTLDR 은 HKLM\System\*ActiveControlSet*\Services 의 “Start” 값이 0x0 디바이스 드라이버를 스켄합니다. 또한 이 드라이버들의 Group 과 Tag 값도 찾습니다.

19 NTLDR 은 HKLM\System\*ActiveControlSet*\Control\ServiceGroupOrder 의 값을 확인하여 반드시 실행 되어야 될 서비스들을 정열합니다.

20. NTLDR은 드라이버들은 Group과 Tag 값으로 정렬합니다. 각각의 서비스나 드라이버는 자신이 속해야할 그룹이 지정되어 있습니다. 모든 드라이버는 Tag로 정렬된 특정 그룹에 속하게 됩니다.

21. NTLDR은 0x0 드라이버를 메모리에 로드 합니다.

22. 자 장기판은 이제 셋팅이 완료 됐습니다. 이제 장기 알들이 나서야 할 차례가 됐습니다. NTLDR은 Ntoskrnl.exe를 실행합니다.

[현상]
AD 서비스에는 문제가 없으나, AD 를 못 찾는 다는 메세지가 발생
실제로 nslookup 진행 시 해당 AD 명으로 IPv6 주소가 나타남

[설명]
Windows 2008 부터는 기본적으로 IPv6를 지원 한다.
다만 사용자가 해당 기능을 Network 장비에서 지원하지 않아 Disable 했을 지라도 터널 IP는 남게 된다.

일시적으로 네트워크 장애가 발생 하는 경우 서버는 끝내 자신의 IP를 IPv4 가 아니라 IPv6로 인식하게 되는 경우가 있다. 이 경우 서버에 DNS 쿼리를 하게 되면 IPv6 주소를 쿼리하게 되고, 이로 인해 장애를 경험하게 된다.

[해결 방법]
궁극은 아니지 아래 레지스트리 값을 적용하여 IPv6의 활성화를 차단 할 수 있다.