[회보 보관 ^] [< 볼륨 1, 번호 1] [볼륨 1, 번호 3 >]
시스템 내부 뉴스레터 1권, 2호
1999년 5월 15일 - 이번 호에서:
SYSTEMS INTERNALS의 새로운 소식
- SDelete
- 블루스크린 화면 보호기 Win2K 업데이트
- "Linux 및 Enterprise"
- "NT 유틸리티 내부"
- My May Windows NT 매거진 칼럼
- 별로 새롭지 않은 내용
INTERNALS 뉴스
- GUI 박사의 형편없는 태도
- WinDev '99 동부
- Numega Driver Works 출시 임박
- 베타 3 DDK 출시
- Win2K 대기 중인 스핀 잠금
향후 예정 사항
- Win2K SFP(시스템 파일 보호기)
스폰서: WINTERNALS 소프트웨어
Systems Internals 뉴스레터는 Winternals Software가 후원하며 웹(http://www.winternals.com.)에서 제공됩니다. Winternals Software는 Windows NT/2K용 고급 시스템 도구의 선도적인 개발업체이자 제공업체입니다. Winternals 소프트웨어 제품에는 Windows NT 4.0용 FAT32, ERD Commander(Windows NT용 부팅 디스크 기능) 및 NTRecover가 포함됩니다.
여러분, 안녕하세요.
Systems Internals 뉴스레터의 두 번째 버전에 오신 것을 환영합니다. 뉴스레터는 현재 2700명의 구독자를 보유하고 있으며 구독자 수는 여전히 강한 증가세를 보이고 있습니다.
지난 뉴스레터 이후 Microsoft는 공식적으로 Windows 2000 베타 3을 출시했습니다. 베타 3 커널의 빌드 번호는 2031이고 NT 4.0의 초기 릴리스 커널의 빌드 번호는 1381이고 NT 3.51의 빌드 번호는 1025입니다. . 제가 이상하게 생각하는(그리고 다소 성가신) 점은 Microsoft가 운영 체제의 전체 빌드를 수행할 때마다(매 근무일) 빌드 번호를 증가시킨다는 것입니다. 그러나 보고된 커널의 빌드 번호는 초기 공개 릴리스의 빌드 번호를 반영합니다. 예를 들어, NT 4.0 서비스 팩 5 커널의 실제 빌드 번호가 1381보다 훨씬 높더라도 커널은 여전히 1381을 빌드 번호로 보고합니다.
Windows 2000 베타 3 릴리스는 개발자 커뮤니티를 깨우기 위한 것입니다. Microsoft는 10월에 Windows 2000을 출하할 것이라고 발표했으며 베타 3은 출하될 것의 완전한 기능 버전을 나타내므로 개발자는 상황이 바뀔 것이라는 두려움 없이 새 제품 작성을 시작할 수 있습니다.
Windows 2000에는 수많은 새로운 API, 계층화된 서비스 및 향상된 커널 기능이 포함되어 있습니다. 장치 드라이버 개발자에게 특히 눈에 띄는 한 가지 변경 내용은 BSOD(Blue Screen of Death)가 변경되었다는 것입니다. NT의 이전 버전에서 BSOD는 시스템의 모든 드라이버에 대한 링크 시간 및 로드 주소 정보와 충돌 당시 존재하는 스택 덤프를 표시했습니다. Windows 2000에서는 중지 코드 및 관련 주소 줄(주소 줄은 하나 이상의 중지 코드 매개 변수를 장치 드라이버 내의 위치로 변환함)만 자세한 메시지와 함께 표시됩니다. 지원 메시지는 충돌이 다시 발생하지 않도록 BIOS 및 하드 드라이브 설정을 확인하고 조각 모음 소프트웨어 및 바이러스 스캐너를 비활성화할 것을 제안합니다. Microsoft PSS(Premier Support Services)는 환경과 고객 피드백을 기반으로 NT 4 스타일 BSOD가 충돌 원인을 파악하는 데 유용하지 않다고 판단했습니다.
저는 개인적으로 로드된 드라이버 목록, 특히 스택 덤프가 사용자로부터 드라이버 버그 보고서를 받을 때 유용하다는 것을 알았습니다. 사용자가 멀티 메가바이트 크래시 덤프를 보내도록 하는 것보다 이 정보를 얻는 것이 훨씬 쉽고 빠릅니다. 저는 종종 스택 덤프를 기반으로 충돌 원인을 격리하고 드라이버 목록에 표시되는 버전 정보를 기반으로 사용자가 로드한 드라이버 버전을 확인했습니다. 여러분의 생각이 궁금합니다. NT 4 스타일의 BSOD가 Windows 2000으로 옮겨지는 것을 보고 싶습니까, 아니면 새로운 BSOD 형식으로 충분합니까? 의견이 있으시면 이메일을 보내주세요. 이 비공식 설문 조사 결과는 다음 뉴스레터에서 발표하겠습니다. BSOD에 대해 이야기하는 동안 이 문제에서 다루는 인기 있는 Systems Internals BlueScreen Screen Saver의 Windows 2000 업데이트를 확인하세요.
감사합니다!
-Mark
SYSTEMS INTERNALS의 새로운 소식
SDELETE
C2 보안 등급 요구 사항을 충족하는 Windows NT 4.0의 일부로 "개체 재사용 보호"를 구현합니다. 즉, NT는 애플리케이션이 리소스에 처음 액세스할 때 애플리케이션이 할당하는 파일 및 메모리 리소스를 0으로 만듭니다. 이것은 예를 들어 애플리케이션이 대용량 파일을 생성하고 그 내용을 검사하여 이전에 디스크에 저장된 내용을 확인하는 것을 방지합니다. 그러나 개체 재사용 보호는 표준 리소스 관련 API를 우회하거나 운영 체제를 모두 우회하는 애플리케이션에서 액세스할 수 있는 리소스를 보호하는 범위로 확장되지 않습니다. 예를 들어 리소스 키트의 DiskProbe와 같은 디스크 편집기를 사용하여 디스크의 할당되지 않은 부분의 내용을 검사할 수 있습니다. 이렇게 하면 이전에 삭제된 파일에 속한 데이터를 볼 수 있습니다.
많은 환경에는 "보안 삭제" 기능이 필요합니다. 이 기능을 사용하면 운영 체제 보호 기능을 우회하는 도구에서 보이지 않도록 중요한 데이터를 영구적으로 삭제할 수 있습니다. 암호화 파일 시스템(EFS)의 출현으로 Windows 2000에서 보안 삭제 기능의 필요성이 강조되었습니다. 이전에 암호화되지 않은 파일을 암호화할 때 EFS는 디스크 할당을 해제할 때 파일의 암호화되지 않은 데이터가 포함된 디스크 할당 내용을 지우지 않습니다. 따라서 암호화하는 파일의 활성 버전이 안전하더라도 파일의 이전 버전은 NTFS가 해당 부분에 할당하는 새 파일 데이터로 덮어쓰게 될 때까지 디스크의 할당되지 않은 부분에 여전히 존재합니다.
이 허점을 해소하기 위해 SDelete(보안 삭제)를 작성했습니다. 표준 파일을 안전하게 삭제할 수 있을 뿐만 아니라 디스크의 할당되지 않은 부분에 있는 이전에 삭제된 데이터를 안전하게 삭제할 수 있는 명령줄 도구입니다. 또한 조각 모음 API를 사용해야 하는 Windows NT/2000 압축, 암호화 및 스파스 파일과 함께 작동합니다. SDelete는 국방부 삭제 및 삭제 표준 DOD 5220.22-M을 준수하므로 데이터를 삭제하면 영원히 사라집니다.
SDelete에 전체 소스 코드와 작동 방식에 대한 설명을 제공하여 조각 모음 API를 사용하는 방법을 확인하고 삭제된 민감한 데이터를 복구할 수 없다는 내 주장을 확인할 수 있습니다.
http://www.sysinternals.com/defrag.htm.에서 Windows NT/2000 조각 모음 API에 대한 문서를 찾을 수 있습니다. http://www.sysinternals.com/sdelete.htm.에서 전체 소스 코드와 함께 SDelete를 다운로드하세요.
BLUESCREEN 화면 보호기 WIN2K 업데이트
Microsoft가 NT 시작 화면과 Windows 2000의 BSOD(Blue Screen of Death) 레이아웃을 변경했기 때문에 Systems Internals BlueScreen Screen Saver에 주요 업데이트가 필요했습니다. 최고의 BSOD 현실감을 계속해서 제공하기 위해 화면 보호기 버전 2.0을 출시했습니다. BSOD 형식의 변경 내용을 반영할 뿐만 아니라 Windows 2000 시작 화면을 정확하게 모방하여 회전하는 진행률 스트라이프 및 진행률 표시줄 업데이트를 완료합니다. 화면 보호기는 Windows 2000 전문 사용자와 개발자도 속일 정도로 현실적입니다. 물론 NT 4.0에서 BlueScreen Screen Saver는 여전히 NT 4.0 BSOD 및 시작 화면을 표시합니다.
제가 Windows 2000 시작 화면을 어떻게 그렇게 완벽하게 재현하면서 동시에 저작권법을 위반하지 않을 수 있었던 비결은 무엇일까요? 화면 보호기에 Windows 2000 시작 비트맵 그래픽을 포함하지 않습니다. 대신 DirectX를 사용하여 시작 시퀀스 동안 Windows 2000에서 사용하는 것과 동일한 그래픽 모드로 전환한 다음 Windows 200 커널 파일인 ntoskrnl.exe의 비트맵 리소스를 참조합니다. 이러한 리소스(Visual Studio에서 ntoskrnl.exe의 리소스를 열면 볼 수 있음)는 커널이 표시하는 리소스이며, 이는 시작 그래픽이 실제로 별도의 파일인 작업을 수행하는 Windows 9x 방식에서 변경된 것입니다. 컴퓨터 OEM이 Windows 2000에서 시작 환경을 사용자 지정할 수 있는 기회가 주어지지 않을 것 같습니다…
http://www.sysinternals.com/bluescreen.htm.에서 BlueScreen 화면 보호기를 다운로드할 수 있습니다. 화면 보호기로 누군가를 속인 것과 관련된 유머러스한 이야기가 있으면 전달해 주세요.
1997년 12월 필자의 Windows NT Magazine NT Internals 칼럼 "Inside the Blue Screen"에서 BSOD의 방법과 이유에 대한 자세한 정보를 찾을 수 있습니다. Systems Internals Publications 페이지(http://www.sysinternals.com/publ.htm)의 링크를 클릭하면 해당 칼럼의 온라인 버전으로 이동합니다. 이 페이지에는 제가 작성한 기사 및 칼럼의 다른 온라인 프레젠테이션에 대한 링크도 포함되어 있습니다.
"Linux 및 Enterprise"
Linux 커널의 확장성 결함에 대한 Windows NT Magazine 4월호 기사에 대한 Linux 커뮤니티의 엄청난 반응 덕분에 잡지는 예정보다 빨리 기사의 온라인 버전을 게시하게 되었습니다. http://www.sysinternals.com/publ.htm.의 "기사" 섹션에서 "Linux 및 엔터프라이즈" 기사에 대한 링크를 찾을 수 있습니다. 이 기사에서는 효율적인 이벤트 대기 메커니즘 부족, 상당한 시스템 호출 직렬화, 비동기 I/O 없음, (NT에서 TransmitFile이라고 하는) 소켓 API의 구현 불량 등 Linux 커널(2.2x)의 현재 릴리스에 대한 몇 가지 제한 사항을 설명합니다. 이러한 제한의 조합으로 인해 Linux는 웹 서버, 데이터베이스 서버 및 전자 메일 서버와 같은 엔터프라이즈급 애플리케이션에서 성능 면에서 NT 및 기타 UNIX와 정면으로 경쟁할 수 없습니다.
"INSIDE NT 유틸리티"
Filemon, Regmon 또는 HandleEx를 사용해 본 적이 있고 이들이 말하는 내용과 구현 방법에 대해 더 알고 싶다면 Windows NT Magazine 2월 칼럼 "Inside NT Utilities"에 관심이 있을 것입니다. 이 칼럼에서는 이러한 도구의 내부를 설명하고 Regmon 및 Filemon의 경우 레지스트리 또는 파일 시스템 활동을 캡처하는 동안 기록하는 오류 코드 및 요청 유형에 대해 약간 알려줍니다. 이제 막 사용할 수 있게 된 이 기사의 온라인 버전에 대한 링크는 http://www.sysinternals.com/publ.htm.에 있습니다.
MY MAY WINDOWS NT 잡지 칼럼
Windows NT/2000이 레지스트리의 내용을 메모리 또는 디스크에 어떻게 구성하는지 궁금해 하신 적이 있나요? 현재(5월) Windows NT Magazine에는 "Inside the Registry"라는 칼럼이 포함되어 있습니다. 예를 들어 Configuration Manager 커널 모드 하위 시스템(레지스트리 관리를 담당하는 하위 시스템)이 키를 조회하고, 값 데이터를 저장하고, 검색을 최적화하고, 디스크에 있는 레지스트리 파일의 무결성을 보호하는 방법을 알아보세요. Windows NT Magazine(http://www.winntmag.com)은 Borders and Barnes and Nobles에서 구할 수 있습니다.
별로 새롭지 않은 것들
Windows 2000 베타 2가 출시된 지 얼마 되지 않아 커널 이미지 파일(ntoskrnl.exe)의 Checked(디버그) 빌드를 가져와 커널에 대한 문자열 검색을 수행한 후 커널을 구축하는 데 사용된 소스 파일의 이름 목록을 생각해 냈습니다. NT/2000 커널의 Checked 빌드에는 Assert가 있는 파일의 파일 이름을 포함하는 수많은 Assert 문(일관성 검사)이 포함되어 있습니다. 커널 소스에 있는 거의 모든 중요한 파일에 적어도 하나의 Assert가 있다고 가정하면 이 목록은 상당히 포괄적입니다. 목록을 Java 스크립트로 덤프하면 Windows 2000 소스 트리의 디렉터리 구조에 대한 멋진 탐색기와 같은 트리 보기를 얻을 수 있습니다. http://www.sysinternals.com/nt5src.htm.에서 확인해 보세요.
INTERNALS 뉴스
GUI 박사의 형편없는 태도
Microsoft 개발자 네트워크 뉴스 GUI 박사 3/4월호에서는 드라이버가 스레드를 어피니티화(특정 CPU를 강제로 사용)할 수 있는 방법을 묻는 리더의 질문을 제시합니다. GUI 박사는 드라이버에서 시스템의 프로세서 수를 확인할 수 있는 방법이 없으며 드라이버 스레드가 실행 중인 프로세서를 알 수 없다고 응답합니다. 불행하게도 GUI 박사는 이 진단을 날려버렸습니다(아마도 GUI 박사는 GUI를 고수해야 할 것입니다).
NT 커널(ntoskrnl.exe)은 NTDDK.H에 정의된 KeNumberProcessors라는 변수를 다음과 같이 내보냅니다.
extern PCCHAR KeNumberProcessors;
다음과 같이 드라이버에서 직접 참조할 수 있습니다.
CHAR i;
for( i = 0; i < *KeNumberProcessors; i++ ) {
// do processor specific stuff
}
드라이버 스레드가 실행 중인 프로세서를 확인하려면 NTDDK.H에 정의되어 있을 뿐만 아니라 실제로 DDK에 문서화되어 있는 또 다른 커널 내보내기인 KeGetCurrentProcessorNumber()를 사용하세요!
GUI 박사는 이 질병에 대해 잘못된 약을 처방했기 때문에 저는 박사에게 정중한 이메일을 보내 이 사실을 알렸습니다. 놀랍게도 GUI 박사는 이메일을 확인조차 하지 않았습니다. 착한 박사가 다음 호에서 오류를 해결하는지 확인하겠습니다…
WINDEV '99 동부
Windows 개발자를 위한 프리미어 컨퍼런스인 1999년 동부 해안 에디션이 빠르게 다가오고 있습니다. WinDev '99 동부는 Boston Cambridge Marriot에서 6월 14-18일 개최됩니다. Jeff Richter, Jeff Prosise 및 Don Box를 포함하여 Windows 개발 분야의 많은 유명 인사들이 강연할 예정입니다. 장치 드라이버 트랙에서 Jamie Hanrahan 및 Brian Catlin과 함께 있을 것입니다. 제 프레젠테이션에는 NT 내부에 대한 하루 종일의 자습서, Windows NT/2K 파일 시스템 드라이버 작성에 대한 설명 및 고급 장치 드라이버 개발 문제에 대한 설명이 포함되어 있습니다. 와서 인사해 주세요!
NUMEGA DRIVER WORKS 출시 임박
Compuware NuMega Labs는 강력한 새 Windows 9x/NT/2K 장치 드라이버 개발 키트인 DriverStudio를 출시하기 직전입니다. DriverStudio는 DriverAgent, DriverWorks, SoftICE 및 VtoolsD를 포함하여 NuMega의 모든 기존 장치 드라이버 도구를 결합하고 드라이버 및 FieldAgent(Windows NT/2K만 해당)를 위한 새로운 BoundsChecker를 추가합니다.
BoundsChecker의 장치 드라이버 버전은 드라이버가 사용하는 모든 커널 API에 대한 포괄적인 모니터링을 제공하며 이를 사용하여 시스템의 다른 장치 드라이버와 드라이버의 상호 작용을 모니터링할 수 있습니다. FieldAgent를 사용하면 BoundsChecker의 드라이버 버전을 클라이언트 시스템에 배포하여 클라이언트가 분석할 수 있는 트레이스를 수집할 수 있습니다. DriverStudio 고객을 위한 무료 업데이트로 곧 출시될 드라이버용 TrueTime 및 드라이버용 TrueCoverage는 장치 드라이버의 성능을 쉽게 조정하고 적용 범위를 테스트할 수 있는 도구입니다.
이 패키지는 궁극적인 드라이버 개발 키트이며 진심으로 추천합니다(베타 프로그램에 참여 중입니다). http://www.numega.com.에서 자세히 알아보세요.
베타 3 DDK 출시
Windows 2000 Beta 3 출시와 함께 Microsoft는 Windows 2000 Beta 3 DDK(Device Driver Kit)를 무료로 다운로드할 수 있도록 했습니다. http://www.microsoft.com/ddk/ddk2kb3.htm.에서 DDK를 받을 수 있습니다. 베타 3에는 MSDN 4월 버전에서 문서화되지 않은 많은 Win32 API가 있으므로 SDK가 곧 출시되기를 바랍니다.
WIN2K 대기 중인 스핀 잠금
Windows 2000은 전역 잠금을 위해 "대기 중인 회전 잠금"이라는 새로운 유형의 회전 잠금을 사용합니다. Windows 2000의 전역 잠금은 Windows NT 4.0의 전역 잠금과 동일하며 다음을 포함합니다.
KiDispatcherLock: 스케줄러 데이터베이스 잠금KiContext-SwapLock: 트레드 스왑 락MmPfnLock: 실제 페이지 프레임 데이터베이스 잠금MmSystemSpaceLock: 커널 모드 주소 공간 잠금CcMasterSpinLock: 캐시 관리자의 전역 스핀 잠금CcVacbSpinLock: 캐시 관리 프로그램의 매핑 배열 잠금
유니프로세서에서 대기 중인 스핀 잠금은 일반 스핀 잠금과 똑같이 작동합니다. 그러나 NT의 멀티프로세서 빌드에서 대기 중인 스핀 잠금은 상당히 다릅니다. 표준 스핀 잠금과 마찬가지로 대기 중인 스핀 잠금은 HAL에서 구현됩니다. 커널은 HAL 함수 KeAcquireQueuedSpinlock 를 호출하여 대기하는 스핀 잠금을 획득하고 대기된 스핀 잠금을 해제하도록 호출합니다 KeReleaseQueuedSpinlock . KeAcquireSpinlock 및 KeReleaseSpinlock, 커널이 표준 스핀 잠금을 획득 및 해제하는 데 사용하는 HAL 함수에는 지정된 스핀 잠금의 주소가 매개 변수로 필요합니다. 대조적으로 큐에 있는 spinlock 함수는 전역 spinlock의 인덱스 번호를 사용합니다. 커널은 배열에서 전역 스핀락을 초기화합니다. 여기서 각 스핀락에는 커널이 HAL에 식별하는 데 사용하는 미리 정의된 인덱스 번호가 있습니다. 따라서 대기 중인 스핀 잠금은 장치 드라이버에서 정의하고 사용할 수 없습니다. 글로벌 큐에 있는 스핀 잠금 배열을 늘릴 방법이 없기 때문입니다.
Windows 2000에서 SMP의 각 프로세서 제어 영역(PCR)(프로세서마다 하나의 PCR이 있음)에는 대기 중인 스핀 잠금만큼 많은 항목이 있는 배열이 있습니다. 각 배열 항목에는 두 개의 필드가 포함되어 있습니다. 대기 중인 스핀 잠금에 대한 포인터("spinlock" 필드) 및 "queue" 필드입니다. 다음 설명에서 spinlock 및 queue 필드를 참조할 때 획득 또는 해제 중인 spinlock에 대한 배열 항목과 관련된 필드에 대해 이야기하고 있습니다.
KeAcquireQueuedSpinlock은(는) 다음과 같이 작동합니다. 이 함수는 현재 프로세서의 PCR 주소를 스핀 잠금에 배치하기 위해 연동 교환 CPU 명령을 사용하여 스핀 잠금을 획득하려고 시도합니다. spinlock이 유지되면 교환 작업의 일부로 함수가 다른 프로세서의 PCR 주소를 갖습니다. 그런 다음 함수는 자체 PCR에서 스핀 잠금 필드의 낮은 비트를 토글하여 "대기 중"으로 자신을 식별합니다. 다음으로 자신의 PCR 주소를 스핀 잠금에서 검색한 PCR의 큐 필드에 넣습니다. 마지막으로 비트가 꺼져 있을 때 스핀 잠금 필드에서 낮은 비트가 꺼질 때까지 바쁜 루프에서 대기하고 현재 프로세서에 스핀 잠금이 부여되어 획득 함수의 호출자에게 반환됩니다.
프로세서가 대기 중인 spinlock을 획득하고 잠금을 유지하는 동안 원하는 처리를 완료한 후 KeReleaseQueuedSpinlock을(를) 호출합니다. KeReleaseQueuedSpinlock은(는) 현재 프로세서의 PCR에서 지정된 spinlock에 대한 큐 필드를 찾습니다. 큐 필드가 0이 아니면 다른 프로세서가 해당 PCR을 "큐"에 넣은 것입니다. KeReleaseQueuedSpinlock은(는) 대기 중인 PCR에 대한 spinlock 필드의 낮은 비트를 지운 다음 자체 큐 필드를 지우고 반환합니다. 대기 중인 PCR의 스핀 잠금 필드에서 낮은 비트를 지우면 다음 CPU에 잠금을 가질 수 있다는 신호를 보낸 것입니다. 큐 필드가 0이면 잠금을 기다리는 다른 프로세서가 없으며 KeReleaseQueuedSpinlock은(는) 단순히 연동 교환 작업을 수행하여 전역 스핀 잠금을 해제합니다.
대기 중인 스핀 잠금의 작업은 프로세서가 보류 중인 스핀 잠금을 기다리는 "라인업" 작업입니다. 각 프로세서는 자신이 대기 중이라는 것을 앞에 있는 프로세서에 알리면서 대기합니다. 이는 대기 중인 스핀 잠금 프로세서의 획득에 대한 결정론적 순서를 제공합니다. 프로세서는 요청한 순서대로 스핀 잠금을 획득합니다. 표준 스핀 잠금의 경우 이러한 순서가 없습니다. 대기 중인 스핀 잠금에는 또 다른 중요한 이점이 있습니다. 프로세서가 스핀 잠금 필드가 낮은 비트를 지울 때까지 기다리면서 회전할 때 자체 프로세서 전용 메모리에서 회전합니다. 사용 중인 프로세서가 표준 스핀 잠금을 기다릴 때 모든 프로세서가 공유하는 전역 스핀 잠금 자체에서 회전합니다. 따라서 대기 중인 스핀 잠금은 바쁜 대기 동안 공유 캐시 라인 액세스가 없기 때문에 더 나은 다중 프로세서 버스 특성을 갖습니다. 또한 대기 중인 스핀 잠금의 큐잉 특성으로 인해 잠금이 여러 프로세서에서 경합 중인 경우 일반적으로 표준 스핀 잠금보다 버스 잠금 작업이 적습니다.
대기 중인 스핀 잠금은 Microsoft가 Windows 2000의 멀티프로세싱 확장성을 개선한 몇 가지 기능 중 하나입니다.
향후 예정 사항
Windows 2000에는 운영자 오류와 오작동하는 애플리케이션에 대한 복원력을 높이는 다양한 기능이 포함되어 있습니다. 그 중 하나는 %systemroot%\system32 및 %systemroot%\system32\drivers 디렉터리 아래에 있는 많은 DLL과 드라이버가 SFP(System File Protector)라는 감시 프로그램에 의해 보호된다는 것입니다. 해당 system32 디렉터리로 이동하고 ntoskrnl.exe의 이름을 변경하여 존재를 확인할 수 있습니다. 감시 프로그램이 깨어나 보호된 시스템 파일에 대한 변조를 감지하고 복구 중임을 알려줍니다. 디렉터리를 다시 확인하면 ntoskrnl.exe이(가) 마술처럼 교체되었음을 알 수 있습니다. 다음에는 이것이 어떻게 작동하는지 알려드리겠습니다.
시스템 내부 뉴스레터를 읽어 주셔서 감사합니다.
발행일: 1999년 5월 15일 토요일 오후 7:15 by ottoh