다음을 통해 공유


[회보 보관 ^] [< 볼륨 1, 번호 2] [볼륨 1, 번호 4 >]

Systems Internals 뉴스레터 1권, 3호

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich


1999년 6월 19일 - 이번 호에서:

  1. SYSTEMS INTERNALS의 새로운 소식

    • SDelete v1.1
    • Strings v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • "내부 NT 네트워킹"
    • 6월 "NT Internals"
    • NTFrob 업데이트 상태
    • 별로 새롭지 않은 것들
  2. INTERNALS 뉴스

    • Numega DriverStudio 릴리스
    • 6월 플랫폼 SDK 사용 가능
    • Win2K SFP(시스템 파일 보호기)
    • 네트워크에서 열린 파일 닫기
  3. 향후 예정 사항

    • "AWE"-일부 Win2K API

스폰서: 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가 포함됩니다.

Winternals Software는 Regmon 및 Filemon Enterprise Editions의 출시를 발표했습니다. 이러한 유틸리티는 프리웨어 Filemon 및 Regmon의 모든 기능을 제공하고 다음과 같은 강력한 기능을 추가합니다.

  • 원격 Win9x/NT 시스템에서 발생하는 레지스트리 및 파일 시스템 활동 보기
  • 실시간으로 파일에 로그 출력
  • 출력 라인을 클립보드에 복사
  • 필터와 일치하는 라인 강조 표시
  • 다른 컴퓨터의 출력을 동시에 보기
  • 출력물을 프린터로 직접 출력
  • 마지막 5개의 필터 선택을 쉽게 불러오기

http://www.winternals.com.에서 주문 및 가격 정보를 확인하세요.


여러분, 안녕하세요.

Systems Internals 뉴스레터 제3판에 오신 것을 환영합니다. 뉴스레터는 현재 4400명의 구독자를 보유하고 있습니다.

지난 뉴스레터에서 저는 Microsoft가 Windows 2000(Win2K)으로 이동하면서 어떻게 고질적인 블루 스크린 문제를 해결했는지 설명했습니다. 새로운 Win2K 블루 스크린에는 이전 버전 Windows NT의 블루 스크린에 있는 로드된 드라이버 및 스택 덤프 정보가 없습니다. 저는 Microsoft가 제거한 정보가 유용하다고 생각하는지, 그리고 그들이 그냥 내버려두기를 바라는지 물었습니다. 거의 만장일치로 모든 응답자(1명 제외)는 Microsoft가 최소 공통 분모를 사용하는 이유를 궁금해했습니다. 다음은 Tony Lavinio가 보낸 일반적인 의견입니다.

즉, Microsoft가 결정을 내리는 데 기반을 둔 고객 응답은 다음과 같습니다.

'나는 그것을 이해할 수 없습니다. 따라서 좋지 않은 대안임이 분명합니다. 없애 주세요.'

전체 화면을 제거하고 "Pull Plug, Reinsert Plug, Start Over"라는 메시지를 표시하지 않는 이유는 무엇입니까? 그들은 왜 상황이 악화된 이유에 대해 우리가 가지고 있는 몇 안 되는 단서 중 하나를 빼앗고 있는 것일까요?

적어도 이전에는 바이러스 스캐너, 조각 모음 또는 버그가 있는 드라이버라면 검색을 시작할 수 있는 지점이 있었습니다.

이 도구가 NT 배포의 광범위한 기반을 가진 우리 중 10,000명 중 1명에게만 도움이 된다면 그만한 가치가 있습니다. 특히 우리는 .01%가 다른 99.99%의 상당 부분을 뒷받침하기 때문입니다.

유일한 반대자는 누구였습니까? 블루 스크린 크래시 보고서를 작성하는 사람이 Microsoft의 누군가라는 것은 그리 놀라운 일이 아닙니다. 다음은 그 이유에 대한 Tony의 추측을 확인하는 변경 내용에 대한 그들의 견해입니다.

저는 MS에서 PSS의 NT Setup 그룹에서 일하고 있습니다(블루 스크린 문제 해결을 처리함). 내가 이야기하는 대부분의 사람들은 4.0 블루 스크린의 정보로 무엇을 해야할지 모른다는 것을 확신할 수 있습니다. 스택 전체에서 NAIFILTR.SYS로 중지 0xA를 본다면 바이러스 백신을 업데이트해야 한다는 것을 알 수 있지만 대부분의 사람들은 해당 연결을 만들지 않으며 실제로 중지 코드와 매개 변수가 그들에게 유용합니다. 블루 스크린 데이터를 해석하는 방법을 이해하는 사람들은 아마도 짜증이 날 것입니다. 그러나 불행하게도 그들의 수는 많이 않습니다.

지난 뉴스레터에서 언급한 것처럼 Microsoft는 로드된 드라이버 목록과 스택 덤프를 유지하면서 NT 4.0 블루 스크린을 더욱 개선해야 한다고 생각합니다. 또한 더 적은 정보가 아닌 더 많은 정보를 제공함으로써 블루 스크린을 더 좋게 만들 수 있다고 생각합니다. 예를 들어 크래시 당시 현재 실행 중인 프로세스의 이름을 표시하지 않는 이유는 무엇입니까? 또는 더 많은 BugCheck 호출이 오류가 발생한 주소뿐만 아니라 오류 발생자의 주소를 전달하도록 합니까? PSS가 블루 스크린에 대해 무지한 많은 고객을 만난 주된 이유는 Microsoft가 블루 스크린을 읽는 방법에 대한 문서를 작성하지 않았기 때문입니다. 따라서 Microsoft 측에도 사용자 무지에 대한 책임이 적어도 일부는 있습니다.

블루 스크린이 어떻게 발생하고 (NT 4.) 블루 스크린에 무엇이 있는지 자세히 알고 싶으면 Windows NT Magazine에서 1997년 12월에 작성한 "Inside the Blue Screen" 기사를 참조하세요(http://www.sysinternals.com/publ.htm).에서 온라인 버전에서 확인할 수 있음).

여느 때처럼 관심이 있을 것 같은 친구에게 뉴스레터를 전달해 주세요.

감사합니다!

-Mark

SYSTEMS INTERNALS의 새로운 소식

SDELETE V1.1

지난 뉴스레터에서 SDelete는 파일 데이터를 복구 불가능하게 삭제하고 이전에 삭제된 데이터의 디스크 여유 공간을 정리하는 데 사용할 수 있는 보안 삭제 유틸리티를 소개했습니다. SDelete의 첫 번째 버전은 삭제한 파일의 이름을 안전하게 덮어쓸 수 없었습니다. 파일 이름은 중요한 정보를 드러내는 경우가 많으며 SDelete를 사용하여 이름이 드러나는 파일을 삭제하면 해당 정보가 노출될 수 있습니다. 이 허점을 해결하기 위해 파일 데이터뿐만 아니라 파일 이름도 안전하게 덮어쓰도록 SDelete를 업데이트했습니다. SDelete는 파일 이름을 26번 변경하여 파일 이름의 각 문자를 'A'에서 'Z'까지 연속된 알파벳 문자로 대체하여 파일 이름을 안전하게 삭제합니다.

http://www.sysinternals.com/sdelete.htm.에서 전체 소스 코드와 함께 SDelete v1.1을 다운로드하세요.

STRINGS V2.0

실행 파일과 DLL에는 종종 문서화되지 않은 레지스트리 값과 문서화되지 않은 기능을 암시하는 오류 메시지를 드러낼 수 있는 문자열이 기본 제공됩니다. 안타깝게도 대부분의 Windows NT/2K 시스템 DLL 및 EXE는 유니코드 문자열을 사용하도록 작성되는 반면 Grep과 같은 기존 문자열 검색 도구는 ASCII 문자열만 추출합니다. ASCII 또는 유니코드 문자열에 대한 이진 파일을 검사하기 위해 몇 년 전에 Strings 유틸리티의 첫 번째 버전을 작성했습니다. 필자는 NT 내부 연구에서 Microsoft가 문서화하지 않은 사항을 파악하는 데 도움을 주기 위해 여러 번 사용했습니다.

그러나 Strings에는 항상 큰 결함이 있었는데, 그것은 한 번에 여러 파일을 스캔할 수 있도록 와일드 카드 표현식을 파일 지정자로 사용할 수 없다는 것입니다. 예를 들어 레지스트리 값의 이름이 주어지면 이를 참조하는 시스템 DLL을 쉽게 확인할 수 있도록 이 기능을 원했습니다.

마지막으로 전체 와일드 카드 파일 이름과 재귀 디렉터리를 사용하도록 Strings를 업데이트했습니다. 와일드 카드 식을 지정하면 Strings는 자동으로 Strings가 있는 파일의 이름을 출력 행에 접두사로 지정하므로 다음과 같이 할 수 있습니다.

strings *.dll | grep SafeBoot

이 식의 출력(Grep 버전은 Windows NT Resource Kit Posix 유틸리티에서 사용 가능)을 보면 Windows 2000에서 SafeBoot 레지스트리 키를 확인하는 시스템 DLL을 알 수 있습니다. Strings는 Win2K 시스템 DLL, 드라이버 및 실행 파일이 사용하는 새로운 레지스트리 값을 확인하는 데에도 매우 유용합니다. 예를 들어 Strings를 사용하여 NT 4.0 SP4 TCP/IP 스택(tcpip.sys)에서 참조하는 레지스트리 값과 Windows 2000 TCPIP 스택에서 참조하는 레지스트리 값을 비교했습니다. 다음은 Win2K의 TCPIP 스택에 새로 추가된 값의 절반 정도입니다(모두 HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 아래에 있다고 가정함).

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

저는 Microsoft가 모든 스택의 새로운 구성 매개 변수를 문서화할 때까지 가만히 기다리지 않을 것입니다.

http://www.sysinternals.com/misc.htm.에서 Strings v2.0을 다운로드할 수 있습니다.

LOGGEDON

누가 원격 NT 시스템에 로그온했는지 알고 싶었던 적이 있습니까? 그렇다면 LoggedOn을 다운로드할 수 있습니다. LoggedOn은 어떤 사용자가 리소스 연결(예: 파일 또는 프린터 공유)을 통해 로그온했는지 뿐만 아니라 어떤 사용자가 로컬 컴퓨터 또는 원격 컴퓨터에 대화식으로 로그온했는지 알려주는 간단한 유틸리티입니다. 다음은 샘플 LoggedOn 출력입니다.

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT 및 Win2K는 애플리케이션이 컴퓨터에 로그온한 사람을 확인하는 데 사용할 수 있는 API를 제공하지 않지만 LoggedOn은 시스템의 HKEY\USERS 레지스트리 트리에 로드된 레지스트리 키를 보고 이를 확인합니다. 대화형으로 로그온한 사용자의 프로필은 이 키에 로드되며 프로필에는 프로필과 연결된 사용자 계정의 SID(보안 ID)를 식별하는 이름이 있습니다. 예를 들어 Regedit를 열고 HKEY_USERS 아래를 보면 다음과 같은 내용이 표시됩니다.

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

여기서는 한 명의 사용자만 대화형으로 로그온됩니다. RID(Relative ID)가 500이기 때문에 로컬 또는 도메인 관리자에게 알릴 수 있습니다. RID NT는 관리자 계정에 대해 예약합니다.

한 시스템이 다른 시스템의 레지스트리를 볼 수 있도록 허용하는 API를 사용하여 LoggedOn은 원격 컴퓨터의 HKEY_USERS 키를 읽고 찾은 SID를 계정 이름으로 변환합니다. 리소스 공유를 통해 로그온한 사용자를 확인하기 위해 LoggedOn은 SDK에 문서화된 NET API를 사용합니다. Net 명령줄 도구는 NET API를 광범위하게 사용합니다. 원격 시스템의 레지스트리에 액세스하는 LoggedOn의 부작용은 LoggedOn을 실행하는 계정이 항상 LoggedOn 출력의 리소스 공유를 통해 원격 시스템에 로그온한 것으로 표시된다는 것입니다.

http://www.sysinternals.com/misc.htm.에서 전체 소스 코드와 함께 LoggedOn을 다운로드할 수 있습니다.

FILEMON V4.13

Windows NT 파일러 드라이버의 변경 내용을 반영하고 실수로 4.12 드라이버에 도입한 버그를 수정하는 업데이트인 Filemon v4.13이 방금 출시되었습니다. 4.13 필터 드라이버에는 다음과 같은 변경 내용이 있습니다.

  • 리소스 동기화 유형을 사용하여 일부 내부 데이터 구조를 보호합니다.
  • 새로운 Win2K IRP, IRP_MJ_PNP_POWER를 처리합니다.

리소스 동기화 유형은 Windows NT 4.0 및 Win2K DDK(장치 드라이버 개발 키트) 모두에서 거의 문서화되어 있지 않습니다. 디자인 가이드에는 리소스에 대한 언급조차 없지만 리소스의 기능은 "Executive Support Routines" 섹션 아래의 참조에 문서화되어 있습니다. 리소스는 서로 다른 스레드에서 동시에 읽을 수 있지만 업데이트 중에 스레드가 독점적으로 액세스해야 하는 데이터 구조를 보호하는 데 유용한 메커니즘입니다. 따라서 이들은 독자의 공유 액세스와 작성자의 독점 액세스를 위해 획득한 리더/작성기 잠금입니다. 파일 시스템 드라이버는 리소스를 광범위하게 사용하므로 Filemon을 업데이트하여 적절한 위치에 사용하는 것이 적절하다고 느꼈습니다.

Filemon v4.13은 또한 새로운 IRP_MJ_PNP_POWER IRP를 처리하므로 Win2K에서 실행될 때 전원 및 플러그 앤 플레이 친화적인 필터 드라이버입니다. 이 유형의 IRP를 처리하는 파일 시스템 필터 드라이버의 유일한 요구 사항은 필터가 연결된 파일 시스템 장치로 IRP를 전달하는 것입니다.

http://www.sysinternals.com/filemon.htm.에서 전체 소스 코드가 포함된 Filemon v4.13을 다운로드할 수 있습니다.

디버그 보기/EE V3.1

DebugView/EE는 Win95, Win98, WinNT 및 Win2K에서 Win32 프로그램 또는 커널 모드 장치 드라이버에 의해 생성된 로컬 또는 원격 디버그 출력을 캡처하는 데 사용할 수 있는 다목적 디버그 출력 모니터입니다. 사용자가 장치 드라이버를 사용하여 크래시을 경험하는 환경에서는 그 유용성이 제한됩니다. 그러나 크래시이 손실되기 전에 모든 디버그 출력 DebugView가 캡처합니다. 최신 버전의 DebugView/EE는 Windows NT/2K에서 이 문제를 해결합니다. 사용자가 장치 드라이버에서 생성된 커널 모드 출력을 캡처하고 사용자가 크래시 덤프를 저장하도록 NT를 구성한 경우 시스템이 재부팅될 때 DebugView/EE는 덤프 파일에서 디버그 출력을 추출할 수 있습니다. DebugView/EE의 크래시 덤프 편집|처리 메뉴 선택 항목을 사용하여 디버그 출력에 대한 메모리 덤프를 검사하도록 합니다. 이 기능을 사용하면 크래시이 발생한 시점까지 드라이버가 생성한 디버그 출력이 포함된 텍스트 파일을 다시 보낼 수 있습니다.

http://www.sysinternals.com/debugview.htm.에서 DebugView/EE v3.1 다운로드

"INSIDE NT NETWORKING"

제 1999년 3월 Windows NT Magazine "NT Internals" 칼럼이 이제 온라인에 게시되었습니다. 구현하는 API, 프로토콜 스택이 API와 인터페이스하는 방법, 하드웨어 벤더가 프로토콜 드라이버와 작동하도록 네트워크 드라이버를 작성하는 방법을 포함하여 위에서 아래로 NT의 네트워킹 아키텍처에 대해 알아보세요. 또한 역직렬화된 NDIS 및 ATM 지원을 포함하여 Win2K 네트워킹의 몇 가지 새로운 기능에 대해 알아보세요.

http://www.sysinternals.com/publ.htm.에서 "Inside NT Networking" 및 기타 지난 NT Internals 칼럼을 온라인으로 읽으세요.

6월 "NT INTERNALS"

제 Windows NT Magazine 칼럼의 6월 기사는 "Inside EFS, Part 1"입니다. 이 문서에서는 Microsoft의 파일 시스템 암호화(EFS) 아키텍처에 대해 설명하고 EFS가 파일을 암호화할 때 따르는 단계를 자세히 안내합니다. EFS는 Win2K NTFS 드라이브에 투명한 암호화 기능을 제공하며 Microsoft는 보안에 관계없이 NTFS 파일을 읽을 수 있는 NTFSDOS 도구의 기능을 처리하기 위해 특별히 개발했습니다. 이 칼럼은 3개월 후에 온라인으로 제공될 예정입니다.

두 번의 뉴스레터 전에 암호화된 파일을 백업하고 복원하는 데 필요한 EFS API가 어떻게 문서화되지 않았는지에 대해 이야기한 적이 있습니다. 안타깝게도 이러한 API는 현재 MSDN 버전에 아직 문서화되어 있지 않습니다. 그러나 저는 Microsoft가 "Microsoft Confidential"로 표시된 문서를 파트너와 백업 소프트웨어 공급업체에 보내고 있다는 정보를 받았습니다. 또한 Microsoft의 파일 시스템 프로그램 관리자인 David Golds는 최근 달라스에서 열린 Microsoft TechEd 컨퍼런스에서 Win2K의 파일 시스템 향상에 대한 강연을 했습니다. http://www.teched99.com/slides/1-337.ppt에서 슬라이드를 온라인으로 볼 수 있는 프레젠테이션에서 그는 백업 API가 문서화되어 있지 않지만 여러분의 요청이 있으면 문서화하겠다고 언급합니다. 안타깝게도 그의 이메일 주소는 슬라이드에 나와 있지 않습니다.

Windows NT Magazine 구독 정보를 보려면 http://www.winntmag.com을(를) 방문하세요.

NTFROB 업데이트 상태

NTFrob은 NT 4.0에서 전경 및 배경 프로세스의 양자 길이를 정확하게 구성할 수 있도록 몇 년 전에 출시한 유틸리티입니다. NTFrob은 NT 커널 내부의 데이터 구조를 수정하므로 서비스 팩에 따라 다릅니다. NT 4.0 서비스 팩 5 출시 이후 SP 5 업데이트인 NTFrob v1.5를 언제 출시할지 묻는 질문이 쏟아졌습니다. 대답은 업데이트가 곧 있을 것이라는 것입니다. 저는 Microsoft가 디버그 정보를 포함하여 SP5를 MSDN 구독자에게 제공하기를 기다리고 있습니다. 새 서비스 팩용 NTFrob을 업데이트하려면 디버그 정보가 필요합니다.

http://www.sysinternals.com/ntfrob.htm.에서 NT 4 SP0-4용 NTFrob을 다운로드할 수 있습니다.

별로 새롭지 않은 것들

몇 달 전에 저는 Systems Internals에서 Win9x/NT/2K 직렬 및 병렬 포트 모니터를 발표했습니다. Portmon을 사용하면 어떤 데이터를 보내고 받는지 포함하여 애플리케이션이 직렬 및 병렬 포트와 상호 작용하는 방식을 정확하게 볼 수 있습니다. 이를 사용하여 전화 접속 세션, laplink 직렬 연결 또는 프린터 활동을 볼 수 있습니다. Portmon은 대히트였으며 최근 Ziff-Davis의 소프트웨어 라이브러리에서 가장 높은 등급인 별 5개를 받았습니다. 별 5개를 획득한 기타 시스템 내부 도구에는 Regmon, NTFSDOS 및 BlueSave가 포함됩니다.

http://www.sysinternals.com/portmon.htm.에서 Portmon 다운로드

INTERNALS 뉴스

DRIVERSTUDIO 릴리스

CompuWare의 NuMega Labs는 Windows 9x/NT/2K 장치 드라이버 개발자를 위한 포괄적인 도구 키트인 DriverStudio를 출시했습니다. 여기에는 SoftICE 4.0, 드라이버용 BoundsChecker, VtoolsD, DriverAgent, DriverWorks, FieldAgent for Drivers가 포함되며 향후 드라이버용 TrueTime 및 드라이버용 TrueCoverage가 추가될 예정입니다. 지난 뉴스레터에서 말했듯이 이것은 필수 개발자 도구 키트입니다. NuMega는 또한 "Driver Central"이라는 장치 드라이버 개발자 지향 웹 사이트를 시작했습니다. - http://www.numega.com/drivercentral/default.asp.

6월 플랫폼 SDK 릴리스

지금 http://www.msdn.microsoft.com/developer/sdk/platform.asp.에서 Microsoft 플랫폼 SDK의 6월 릴리스를 다운로드할 수 있습니다.

WIN2K 시스템 파일 보호기(SFP)

NT 시스템 관리자와 사용자의 가장 큰 불만 중 하나는 NT의 "DLL 지옥"입니다. DLL 지옥은 번들 버전으로 키 시스템 DLL을 업데이트하는 많은 애플리케이션의 결과입니다. 애플리케이션은 일반적으로 제대로 작동하는지 확인하기 위해 이 작업을 수행하지만 DLL을 교체할 때 호환되지 않는 버전을 설치하거나 DLL을 이전 버전으로 "업데이트"하여 다른 애플리케이션을 여러 번 손상시킵니다.

Microsoft는 SFP(시스템 파일 보호기)를 도입하여 Win2K의 DLL 버전 관리 문제를 해결했습니다. 사실 이름은 곧 WFP(Windows File Protector)로 변경되지만 베타 3(빌드 2031)에서는 여전히 SFP입니다. SFP는 시스템이 부팅될 때 Winlogon 프로세스(winlogon.exe)가 로드하는 sfc.dll이라는 DLL에서 구현됩니다. SFP에는 30-40개의 서로 다른 디렉터리에 설치된 약 3000개의 표준 Win2K 시스템 DLL, 실행 파일(.exe), 설치 파일(.inf), 드라이버(.sys) 및 글꼴(.fon) 파일의 기본 제공 목록이 포함되어 있습니다. SFP가 초기화되면 보호하는 파일이 포함된 각 디렉터리에서 디렉터리 변경 알림 작업을 실행합니다. 파일 변조를 감지하면 현재 사용자에게 알리는 대화 상자를 표시하고 이벤트 로그에 이벤트를 기록하고 수정된 파일을 %systemroot%\system32\dllcache에 저장된 백업으로 바꿉니다. SFP가 dllcache에서 찾는 백업 파일이 없거나 변조된 경우 SFP는 Win2K 설치 미디어에서 새 복사본을 검색합니다.

SFP가 보호하는 파일을 확인하려면 이 뉴스레터의 다른 부분에서 언급된 Strings 유틸리티를 사용하여 %systemroot%\system32\sfc.dll에 포함된 유니코드 문자열 이름을 덤프할 수 있습니다.

시스템 파일을 업데이트할 수 있는 유일한 유틸리티는 hotfix.exe, 서비스 팩(update.exe), 업그레이드 설치 및 Win2K 업데이트 서비스입니다. 이러한 도구는 어떻게 SFP를 우회합니까? 내보낸 sfc.dll 함수 SfcTerminateWatcherThread를 호출하여 일시적으로 비활성화하고 dllcache 하위 디렉터리에 업데이트를 반영합니다. Win2K는 모든 시스템 파일에 Microsoft의 디지털 서명이 필요하므로 일반적으로 자신의 임의 버전으로 시스템 파일을 업데이트할 수 없습니다.

Win32 프로그램은 FindFirstChangeNotification 및 FindNextChangeNotification Win32 API를 사용하여 디렉터리의 변경 내용을 감시할 수 있습니다. 그러나 이러한 API는 단순히 변경 내용이 있음을 애플리케이션에 알립니다. 무엇이 변경되었는지 애플리케이션에 정확히 알려주지 않습니다. 따라서 애플리케이션은 전체 디렉터리를 스캔하여 어떤 파일이나 하위 디렉터리가 변경되었는지 확인해야 합니다. SFP는 NT 네이티브 API를 사용하여 변경 알림 요청을 수행합니다. 여기서 NT는 모니터링되는 디렉터리에서 정확히 어떤 파일 또는 하위 디렉터리가 변경되는지 알려줍니다. SFP가 사용하는 기능의 이름은 NtNotifyChangeDirectoryFile이며 NT 네이티브 API의 90%와 마찬가지로 문서화되어 있지 않습니다. 가까운 장래에 Systems Internals에서 NtNotifyChangeDirectoryFile을 사용하는 방법을 보여주는 애플릿을 찾으세요.

제 9월 "NT Internals" 칼럼, "Inside Win2K Reliability Enhancements, Part 2"에서 SFP에 대해 자세히 설명합니다.

네트워크에서 열린 파일 닫기

Systems Internals 방문자로부터 가장 자주 받는 질문 중 하나는 "사용자가 네트워크에서 연 파일을 어떻게 닫습니까?"입니다. 사용자가 원격으로 파일이나 디렉터리를 열면 로컬에서 파일이나 디렉터리를 삭제하거나 이름을 바꾸거나 업데이트할 수 없습니다. 유사한 질문은 "사용자가 네트워크에서 어떤 파일을 열었는지 어떻게 알 수 있습니까?"입니다. Windows NT/2K와 함께 제공되는 Net 명령줄 유틸리티를 사용하면 이 두 가지 질문에 대한 답을 얻을 수 있습니다. 열려 있는 파일을 보려면 "net file"을 입력하세요. 열린 파일 이름, 해당 파일 이름 식별자 및 파일을 연 사용자 이름 목록이 표시됩니다. 열려 있는 파일 중 하나를 닫으려면 net file <id> /close을 입력합니다. 로컬로 열린 파일을 보려면 내 NTHandle 또는 HandleEx 도구를 사용할 수 있습니다.

Net 명령의 파일 보기 및 닫기 기능의 기반이 되는 API는 Platform SDK 및 MSDN 라이브러리에 문서화되어 있습니다. NetFileEnum API를 사용하여 열린 파일을 열거하고 NetFileClose API를 사용하여 열린 파일을 닫습니다. API를 사용하면 Net 명령이 허용하지 않는 원격 서버의 열린 파일을 열거할 수 있습니다.

NTHandle은 http://www.sysinternals.com/nthandle.htm.에서 다운로드할 수 있습니다. HandleEx는 http://www.sysinternals.com/handleex.htm.에서 다운로드할 수 있습니다.

향후 예정 사항

"AWE"-일부 WIN2K API

Win2K는 메모리 사용량이 많은 애플리케이션이 대용량의 물리적 RAM에 직접 액세스하고 관리하는 데 사용할 수 있는 AWE(Address Window Extensions)라는 새로운 API를 도입했습니다. 이 API는 Windows NT 애플리케이션이 가상 주소 공간에서 주소를 지정할 수 있는 RAM의 상한선인 3GB를 초과합니다. 실제로 x86 시스템에 PSE(Page Size Extensions)와 4GB 이상의 RAM이 있는 경우 애플리케이션은 AWE를 사용하여 컴퓨터의 모든 메모리를 활용할 수 있습니다. 따라서 이 API는 웹 서버 및 데이터베이스 서버와 같은 메모리 사용량이 많은 애플리케이션에 이상적입니다. 다음 시간에는 Win32 애플리케이션과 장치 드라이버 모두에서 API를 사용하는 방법을 알려드리겠습니다.

메모리를 많이 사용하는 애플리케이션에 대해 이야기하는 동안 파일을 캐시하는 애플리케이션(예: 웹 서버)을 작성하는 모든 사용자를 위한 팁이 있습니다. Windows NT 캐시 관리자는 캐시 메모리를 "뷰"라고 하는 256KB 슬롯으로 나눕니다. 크기가 256KB 미만인 파일이 캐싱되는 경우 캐시 관리 프로그램은 파일에 전체 256KB 슬롯을 할당해야 합니다. 즉, 캐시의 가상 메모리 일부가 낭비됩니다. 따라서 일반적으로 크기가 256KB 미만인 파일은 자체 애플리케이션의 가상 메모리에 캐시하고 파일 시스템에 의존하여 크기가 256KB보다 큰 파일을 캐시하는 것이 성능에 더 효율적입니다. IIS 5.0은 이 트릭을 사용합니다.


시스템 내부 뉴스레터를 읽어 주셔서 감사합니다.

게시일: 1999년 6월 19일 토요일 오후 7:14 by ottoh

[회보 보관 ^] [< 볼륨 1, 번호 2] [볼륨 1, 번호 4 >]