It's Myself

Administration utility (2.0.50727) to install and uninstall ASP.NET on the local machine.

-- ASP.NET REGISTRATION OPTIONS --
-i
Install this version of ASP.NET and update scriptmaps at the IIS metabase root and for all scriptmaps below the root. Existing scriptmaps of lower version are upgraded to this version.

-ir
Install this version of ASP.NET, register only. Do not update scriptmaps in IIS.

-iru
Install this version of ASP.NET. If there are any existing applications that uses ASP.NET, it will not update scriptmaps in IIS.

-enable
When -enable is specified with -i, -ir or -r, ASP.NET will be enabled in the IIS security console (IIS 6.0 or later).

-disable
When -disable is specified with -i, -ir or -r, ASP.NET will be disabled in the IIS security console (IIS 6.0 or later).

-s <path>
Install scriptmaps for this version at the specified path, recursively. E.g. aspnet_regiis.exe -s W3SVC/1/ROOT/SampleApp1

-sn <path>
Install scriptmaps for this version at the specified path, non-recursively.

-r
Install this version of ASP.NET and update scriptmaps at the IIS metabase root and for all scriptmaps below the root. Existing scriptmaps are upgraded to this version regardless of the original versions.

-u
Uninstall this version of ASP.NET. Existing scriptmaps to this version are remapped to highest remaining version of ASP.NET installed on the machine.

-ua
Uninstall all versions of ASP.NET on the machine.

-k <path>
Remove all scriptmaps to any version of ASP.NET from the specified path, recursively.
E.g. aspnet_regiis.exe -k W3SVC/1/ROOT/SampleApp1

-kn <path>
Remove all scriptmaps to any version ASP.NET from the specified path, non-recursively.

-lv
List all versions of ASP.NET that are installed on the machine, with status and installation path.

-lk
List all the path of all IIS metabase keys where ASP.NET is scriptmapped, together with the version. Keys that inherit ASP.NET scriptmaps from a parent key will not be displayed

-c
Install the client side scripts for this version to the aspnet_client subdirectory of each IIS site directory.

-e
Remove the client side scripts for this version from the aspnet_client subdirectory of each IIS site directory.

-ea
Remove the client side scripts for all versions from the aspnet_client subdirectory of each IIS site directory.

-ga <user>
Grant the specified user or group access to the IIS metabase and other directories used by ASP.NET.

필요사항
COM 클래스를 활성화 하기 위해 권한 상승 Moniker를 사용하기 앞서 클래스는 반드시 실행 사용자 또는 '활성자로써 활성화(Activate as Activator)'의 응용 프로그램 ID로 실행 할 수 있도록 설정되어 있어야 합니다. 만일 클래스가 여타 다른 ID하에서 실행되도록 설정하려면, Activation에서는 CO_E_RUNAS_VALUE_MUST_BE_AAA 에러를 돌려주게 됩니다.
클래스에서는 반드시 다중 언어 사용자 인터페이스(MUI) 호환이 되는 "친숙한" 표시 이름으로 되어 있어야 합니다. 여기서는 다음과 같은 레지스트리
항목이 필요하게 됩니다.:

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\

  {CLSID}\LocalizedString = <displayname>

만일 항목이 빠진 경우, Activation에서는 CO_E_MISSING_DISPLAYNAME 에러를 돌려주게 됩니다. 만일 MUI 파일이 빠진
경우 RegLoadMUIStringW API에서 에러 코드를 돌려주게 됩니다.
추가적으로, LUA 사용자 인터페이스에서 보여주게 될 응용 프로그램 아이콘을 표시하려면 다음 레지스트리 키를 추가해 줍니다.:

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\

  {CLSID}\IconReference = <applicationicon>

COM 클래스에서는 LUA-Enabled 와 같은 표시가 반드시 필요합니다. 이 사항을 적용하려면 다음과 같은 레지스트리 항목을 추가하시면 됩니다.

HKEY_LOCAL_MACHINE\Software\Classes\CLSID\

  {CLSID}\Elevation\Enabled = 1

만일 항목이 빠져 있는 경우 Activation에서는 CO_E_ELEVATION_DISABLED이라는 에러를 돌려주게 됩니다.
HKEY_LOCAL_MACHINE 항목 상에 이들 항목이 있는 경우, HKEY_CURRENT_USER 및 HKEY_USERS 항목에서는 없어야
합니다. 이는  COM 클래스의 권한 상승을 레지스트리 등록 권한이 없는 사용자가 멋대로 등록하는 경우를 방지하기 위해서 입니다.

권한 상승 Moniker 및 권한상승 UI
만일 클라이언트가 이미 권한 상승 Moniker로 권한 상승이 된 경우, 권한 상승 UI를 보여주지 않게 합니다.

권한 상승 Moniker를 사용하는 방법
권한 상승 Moniker는 표준 COM Moniker이며, 세션, 파티션 또는 큐 형태의 Moniker들과 유사합니다. 특정 권한 레벨을 특정 서버에 활성 요청을 관리합니다.Moniker 문자열에서 활성화 할 CLISID를 나타냅니다.
권한 상승 Moniker에서는 다음과 같은 실행 레벨 토큰들을 지원합니다.

1. Administrator(관리자).
2. Highest(높음).

이 사항에 대한 문접은 다음과 같습니다.

[code]
Elevation:Administrator!new:{guid}
Elevation:Highest!new:{guid}
[/code]

앞의 문법 중에서 해당 GUID의 COM 클래스의 새로운 인스탄스를 받으려면 "new" Moniker를 사용하면 됩니다. 여기서 "new" Monker에서는 클래스 객체를 탑재한 후 IClassFactory::CreateInstance를 호출하기 위해 IClassFactory interface 를 내부적으로 사용한다는 것에 주의해주시기 바랍니다.
또한 권한 상승 Moniker가 IClassFactory를 구현하기 위해 클래스 객체를 얻을 때 이용 될 수 있습니다.그리고 호출자에서는 객체 인스탄스를 얻기 위해 IClassFactory::CreateInstance 를 호출하게 됩니다. 이 사항에 대한 문법은 다음과 같습니다.

[CODE] Elevation:Administrator!clsid:{guid} [/CODE]

예제 코드
다음 예제 코드에서는 어떻게 권한 상승 Moniker를 사용하는지에 대한 내용입니다. 이 부분의 의미하는 사항은 현재 쓰레드 상에서 이미 초기화 된 COM을 나타내는 것입니다.

[CODE] HRESULT CoCreateInstanceAsAdmin(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv) {   BIND_OPTS3 bo;   WCHAR  wszCLSID[50];   WCHAR  wszMonikerName[300];

  StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0]));   HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);   if (FAILED(hr))        return hr;   memset(&bo, 0, sizeof(bo));   bo.cbStruct = sizeof(bo);   bo.hwnd = hwnd;   bo.dwClassContext  = CLSCTX_LOCAL_SERVER;   return CoGetObject(wszMonikerName, &bo, riid, ppv); } [/CODE]

BIND_OPTS3은 Windows Vista에서 새롭게 등장한 사항입니다. 이 부분은 BIND_OPTS2에서 상속 받은 사항으로 다음과 같은 형태로 정의되어 있습니다.

[CODE] typedef struct tagBIND_OPTS3 : tagBIND_OPTS2 {   HWND hwnd; } BIND_OPTS3, * LPBIND_OPTS3; [/CODE]

한가지 추가적인 사항은 HWND 필드, hwnd가 있습니다.이 핸들은 대부분의 경우 권한 상승 UI의 부모가 될 윈도우를 나타내게 됩니다.
만일 hwnd가 NULL인 경우 COM은 현재 스레드에 관련된 Window Handle을 찾기 위해 GetActiveWindow를 호출하게 됩니다. 클라이언트가 스크립트로 구성되어, 발생되는 경우로 BIND_OPT3 구조체의 정보가 불완전하게 담기게 됩니다. 이 경우, COM에서는 스크립트 스레드와 관련된 Window를 사용하도록 시도하게 됩니다.

Over-The-Shoulder 권한 상승(OTS)
Over-the-shoulder 권한 상승 (Over-the-shoulder elevation : OTS)은 사용자 자체 권한 이라기 보다 관리자 권한을 가진 사용자의 권한으로 COM 서버가 동작하는 클라이언트에서 볼 수 있는 시나리오 상황 입니다.(Over-the-shoulder 의 의미는 사전적으로 훔쳐보다로써, 클라이언트가 서버를 동작시키는 것과 같이 클라이언트 권한 밖에서 관리자 처럼 동작시키는 것을 의미합니다.)
이 시나리오에서는 서버로 COM을 호출하는 문제를 발생시킬 수 있습니다. 그 이유로는 서버가 명확하거나(대부분 프로그램 로직상으로), 무조건적으로(정확히 말하자면, 레지스트리를 이용하여) CoInitializeSecurity를 호출하지 못하기 때문입니다. 그런 서버들 때문에, COM에서는 서버로 COM을 호출 할 수 있도록 SELF, SYSTEM 및 Builtin\Administrators를 나타내는 보안 명세서를 산정하게 됩니다.이 명세서는 OTS 시나리오에서 동작하지 않습니다. 대신에 서버는 INTERACTIVE SID 및 System Group을 포함하는 ACL을 명시에 명확하고 무조건적적으로 방법을 벗어나 CoInitializeSecurity를 반드시 호출하게 해줍니다.
다음 예제 코드에서는 INTERACTIVE group SID로 보안 명세서(security descriptor : SD)를 어떻게 생성하는지 보여주게 됩니다.

[CODE] BOOL GetAccessPermissionsForLUAServer(SECURITY_DESCRIPTOR **ppSD) { // Local call permissions to IU, SY   LPWSTR lpszSDDL = L"O:BAG:BAD:(A;;0x3;;;IU)(A;;0x3;;;SY)";   SECURITY_DESCRIPTOR *pSD;   *ppSD = NULL;   if (ConvertStringSecurityDescriptorToSecurityDescriptorW(lpszSDDL, SDDL_REVISION_1, (PSECURITY_DESCRIPTOR *)&pSD, NULL))   {        *ppSD = pSD;        return TRUE;   }    return FALSE; } [/CODE]

다음 예제 코드는 이전 예제 코드에서 SD로 명확하게 CoInitializeSecurity를 호출하는 방법을 보여줍니다.

[CODE] // hKey is the HKCR\AppID\{GUID} key BOOL SetAccessPermissions(HKEY hkey, PSECURITY_DESCRIPTOR pSD) {   BOOL bResult = FALSE;   DWORD dwLen = GetSecurityDescriptorLength(pSD);   LONG lResult;   lResult = RegSetValueExA(hkey,        "AccessPermission",        0,        REG_BINARY,        (BYTE*)pSD,        dwLen);   if (lResult != ERROR_SUCCESS) goto done;   bResult = TRUE; done:   return bResult; } [/CODE]

다음 코드는 SD 상위의 권한으로 무조건적으로 CoInitializeSecurity를 호출하는 방법을 보여줍니다.

[CODE] // Absolute SD values PSECURITY_DESCRIPTOR pAbsSD = NULL; DWORD AbsSdSize = 0; PACL  pAbsAcl = NULL; DWORD AbsAclSize = 0; PACL  pAbsSacl = NULL; DWORD AbsSaclSize = 0; PSID  pAbsOwner = NULL; DWORD AbsOwnerSize = 0; PSID  pAbsGroup = NULL; DWORD AbsGroupSize = 0;

MakeAbsoluteSD (   pSD,   pAbsSD,   &AbsSdSize,   pAbsAcl,   &AbsAclSize,   pAbsSacl,   &AbsSaclSize,   pAbsOwner,   &AbsOwnerSize,   pAbsGroup,   &AbsGroupSize ); if (ERROR_INSUFFICIENT_BUFFER == GetLastError()) {   pAbsSD = (PSECURITY_DESCRIPTOR)LocalAlloc(LMEM_FIXED, AbsSdSize);   pAbsAcl = (PACL)LocalAlloc(LMEM_FIXED, AbsAclSize);   pAbsSacl = (PACL)LocalAlloc(LMEM_FIXED, AbsSaclSize);   pAbsOwner = (PSID)LocalAlloc(LMEM_FIXED, AbsOwnerSize);   pAbsGroup = (PSID)LocalAlloc(LMEM_FIXED, AbsGroupSize); if ( ! (pAbsSD && pAbsAcl && pAbsSacl && pAbsOwner && pAbsGroup)) {    hr = E_OUTOFMEMORY;   goto Cleanup; } if ( ! MakeAbsoluteSD(        pSD,        pAbsSD,        &AbsSdSize,        pAbsAcl,        &AbsAclSize,        pAbsSacl,        &AbsSaclSize,        pAbsOwner,        &AbsOwnerSize,        pAbsGroup,        &AbsGroupSize        )) {      hr = HRESULT_FROM_WIN32(GetLastError());      goto Cleanup; } else {      hr = HRESULT_FROM_WIN32(GetLastError());      goto Cleanup; } // CoinitilizeSecurity 호출 [/CODE]

COM 권한 및 위임 접근 라벨(COM Permissions and Mandatory Access Labels)
Windows Vista에서 보안 상세서(security descriptors : SD)에 있는 위임 접근 라벨에 대한기본적인 내용을 소개하였습니다.라벨에서는 클라이언트가 COM 객체로 접근 실행할 수 있도록 지시하게 됩니다. 라벨에는 보안 명세서의 시스템 접근 제어 리스트(system access control list : SACL)내에 명시되어 있습니다. Windows Vista에서는 COM 자체적으로 SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP 라벨을 지원합니다. Windows Vista 이전 운영체제에서는 COM 권한 내의 SACLs들의 내용이 무시되었습니다.
Windows Vista에서는 dcomcnfg.exe가 COM 권한 내에서 더 이상 통합 레벨(IL) 변경을 지원하지 않습니다. 반드시 프로그렘 적으로 설정하게끔 되어 있습니다.
다음 예제 코드에서는 모든 낮은 IL 클라이언트에서 실행/활성화 요청을 할 수 있도록 라벨을 이용하여 COM 보안 명세서를 어떻게 생성하는지에 대해 나타내고 있습니다. 이렇게 하면, 일정한 IL을 가진 클라이언트에서 실행, 활성화 또는 호출에서 실패된 COM 서버를 쓸 수 있게 됩니다.통합 레벨(IL)에 대한 더 자세한 사항은 Understanding and Working in Protected Mode Internet Explorer 안에 있는 "Understanding Windows Vista's Integrity Mechanism" 섹션을 보시기 바랍니다.

[CODE] BOOL GetLaunchActPermissionsWithIL (SECURITY_DESCRIPTOR **ppSD) { // Allow World Local Launch/Activation permissions. Label the SD for LOW IL Execute UP   LPWSTR lpszSDDL = L"O:BAG:BAD:(A;;0xb;;;WD)S:(ML;;NX;;;LW)";   if (ConvertStringSecurityDescriptorToSecurityDescriptorW(lpszSDDL, SDDL_REVISION_1, (PSECURITY_DESCRIPTOR *)&pSD, NULL))   {        *ppSD = pSD;        return TRUE;   } } BOOL SetLaunchActPermissions(HKEY hkey, PSECURITY_DESCRIPTOR pSD) {   BOOL bResult = FALSE;   DWORD dwLen = GetSecurityDescriptorLength(pSD);   LONG lResult;   lResult = RegSetValueExA(hkey,        "LaunchPermission",        0,        REG_BINARY,        (BYTE*)pSD,        dwLen);   if (lResult != ERROR_SUCCESS) goto done;   bResult = TRUE; done:   return bResult; }; [/CODE]

CoCreateInstance 및 통합 레벨(IL)
CoCreateInstance의 기능은 Windows Vista에 이르러 낮은IL 클라이언트에서 기본적으로 COM 서버를 연결하는 것을 방지하게 끔 변경되었습니다. 서버는 반드시 SASL로 명시하여 연결해야 명확하게 연결되게 됩니다.CoCreateInstance의 변화된 사항은 다음과 같습니다.

• COM 서버 프로세스를 실행할 때, 서버 프로세스 토큰 내 IL이 클라이언트 또는 서버 토큰 IL으로 설정되어 있어야 하며, 무엇보다 IL이 낮아야 합니다.
• 기본적으로, COM은 어떠한 COM 서버의 인스탄스를 실행하기 위해 낮은 IL 클라이언트이 연결하는 작업 자체를 배제합니다.연결을 허용하려면, COM 서버의 실행/활성화 보안 명세서(Launch/Activation security descriptor)가 낮은 IL 라벨 상에 명시되어 있는 SACL이 담겨 있어야 합니다.(이와 같은 보안 명세서를 생성하기 위한 예제 코드를 이전 섹션에서 보실 수 있습니다.)

권한 상승된 서버 및 ROT 등록
만일 COM 서버에서 실행 객체 테이블(Running Object Table : ROT)에 등록하는 경우나 기타 클라이언트 상에서 등록을 할 수 있도록 하려면, 제일 먼저 을 원하는 경우 ROTFLAGS_ALLOWANYCLIENT 플래그를 사용하셔야 합니다. 단, '활성자로써 활성화(Activate as Activator)' 형태의 COM 서버에서는 ROTFLAGS_ALLOWANYCLIENT를 명시해줄 수 없는데 그 이유는 DCOM 서비스 컨트롤 관리자(DCOMSCM)에서 강제적으로 이 플래그에 대한 속임수 체크를 수행하기 때문입니다. 그러므로 Windows Vista에서는 COM에서 새로운 레지스트리 항목에 대한 지원을 추가해야 합니다. 새로운 레지스트리 항목은 클라이언트에 가능하게 만들어주는 ROT 등록을 명시적으로 할 수 있도록 서버를 허용하는 항목입니다.

HKEY_LOCAL_MACHINE\Software\Classes\AppID\

{ APPID }

REG_DWORD_ROTFlags

단 한개의 이 항목에 대해 적용가능한 값은 다음과 같습니다.

[CODE] ROTREGFLAGS_ALLOWANYCLIENT 0x1 [/CODE]

이 항목은 HKEY_LOCAL_MACHINE 영역에 있어야 합니다.
그리고 ROTFLAGS_ALLOWANYCLIENT 로 RunAs server가 제공되는 기능을 '활성자로써 활성화(Activate as Activator)'와 동일하게 동작하기 위한 사항입니다.

추가적인 사항
Reference
BIND_OPTS3

기타 자료
Understanding and Working in Protected Mode Internet Explorer

프로세스와 주소 공간
32 비트 윈도우에서는 실제 시스템 상에 메모리가 얼마이든 간에 모든 프로세스는 4G(Giga Byte)[ 2 ^ 32 -1) ]의 용량의 가상 메모리 주소 공간을 가져올 수 있습니다.
기본 윈도우 설정을 기준으로 4G 중 2G 부분은 프로세스 개별적으로 이용하게 되는 주소 공간이고 나머지 2G는 다른 프로세스 및 운영체제와 공유해서 이용하게 되는 주소 공간입니다.
그래서 보통 응용 프로그램(메모장, 엑셀, 인터넷 익스플로어 등)은 2G 개별 주소 공간내에서 실행되도록 구성 되게 됩니다. 이 때 운영체제는 단지 응용 프로그램에서 필요로 하는 용량 만큼 가상 메모리 페이지 크기에 맞게 RAM상에 페이지 프레임(Page Frame)을 지정하게 됩니다.

여기서 물리 주소 확장(Physical Address Extention : PAE)이라는 기능이 있는데, 물리 메모리 주소를 36 비트로 확장해주는 32비트 아키텍처 입니다.(역주: 32비트 컴퓨터에서는 보통 32 비트의 물리 메모리 주소, 즉 최대 4G [ 2 ^ 32 - 1 ]의 주소공간을 가질 수 있읍니다. 이를 36비트로 확장한다는 의미입니다. 그러므로 최대 64G[ 2 ^ 36 - 1 ]의 주소공간을 가질 수 있게 됩니다.) - 참고 할 만한 정보로는 http://support.microsoft.com/kb/268363 를 보시면 됩니다. 그러나 이 가상 메모리는 PAE로 인해 크기적인 변화가 없으며 단지, 프로세서(CPU)에서 시스템 내에 설치된 메모리의 주소 영역만 확장되는 것입니다.
이 때 프로세스 내에서 동작되는 32Bit 기준의 가상 메모리 주소 공간과 36Bit 메모리 주소 공간 간의 변환 작업은 운영체제에서 관리하는 변환 표(Translate Table)에 따라 하드웨어 상에서 자동적으로 제어되며 투명하게 변환이 됩니다.

다음 목록은 각각 윈도우 버전 및 에디션에 따른 지원되는 최대 램용량입니다.(2004년 11월 현재 기준)
  Windows NT 4.0: 4 GB
  Windows 2000 Professional: 4 GB
  Windows 2000 Standard Server: 4 GB
  Windows 2000 Advanced Server: 8GB
  Windows 2000 Datacenter Server: 32GB
  Windows XP Professional: 4 GB
  Windows Server 2003 Web Edition: 2 GB
  Windows Server 2003 Standard Edition: 4 GB
  Windows Server 2003 Enterprise Edition: 32 GB
  Windows Server 2003 Datacenter Edition: 64 GB

페이지 파일
램은 제한 적인 자원인 반면, 가상 메모리는 이상적인 주소 공간이기 때문에 이론적으로 제한이 없습니다. 물론 프로세스 별 최대 할당될 수 있는 주소 크기는 2G입니다. 모든 프로세스들이 사용하는 총 메모리 용량이 실제 메모리의 총 용량을 넘어서면, 운영체제에서는 하나 혹은 여러개의 가상 메모리 주소의 페이지(4Kb 단위의 조각)를 하드 디스크 상에 옮기고, 옮겨진 양 만큼의 메모리 공간을 회수 하게 됩니다. 윈도우 시스템에서는 이들 "페이지 아웃(Paged Out)"된 를 pagefile.sys라고 불리는 파일을 한개 혹은 여러 개로, 시스템 하드 디스크의 루트 디렉토리 상에 저장하게 합니다. 물론 이 파일을 각 하드 디스크의 파티션 별로 하나씩 담을 수도 있습니다. 이 부분에 대한 설정은 시스템 등록정보, 고급, 성능(설정 탭을 클릭)에서 하실 수 있습니다.

가장 많은 질문 내용 중에 "페이지 파일을 얼마나 크게 잡아야 되나요?" 라는 것이 있는데, 사실 이 질문에 대한 정확한 한가지 답은 없습니다. 그 이유는 설치된 램 크기와 작업 중에 가상 메모리 사용량에 따라 달라지기 때문입니다. 그 외 특별한 사항이 없다면, 일반적으로 설치된 메모리의 1.5 배의 용량으로 구성하는 것이 가장 좋은 형태라고 권장하고 있습니다. 서버 시스템 중 일반적인 목적을 위해 구성되어 충분한 램 용량을 갖추어 있다면 굳이 페이지 파일을 구성할 필요는 없습니다. 이런 시스템에서는 큰 페이지 파일을 만들어 제공할 필요가 거의 없는 것이죠. 그러나 다른 한편으로는 간혹 발생될 큰 규모의 메모리 할당이 요구 될 시, 시스템 불안정한 상황이 발생할 수 있습니다. 이런 경우를 대비하기 위해 통상 앞서 말씀 드린 1.5배 이상의 가상 메모리를 미리 잡아 두는 것도 나쁘지는 않습니다.

성능, 아키텍처 상 제한 과 RAM
어느 컴퓨터 시스템이든 간에, 작업량(사용자 수, 업무를 수행하는 개수)이 증가되면 성능(업무를 처리하는데 걸리는 시간)은 감소되게 됩니다. 하지만 이 관계는 비 대칭형으로 진행되게 됩니다. 작업량 증가의 형태가 어느 정도였든간에, 극적인 성능 감소를 넘어서는 지점을 넘어서게 됩니다. 이 의미는 몇몇 자원들이 최악으로 소량 제공되어 결국 병목현상을 불러 일으킨다는 것입니다.

몇몇 지점에서는 최악으로 소량 제공되는 자원들이 증가되지는 않게 됩니다. 이는 아키텍쳐 상 제한에 도달했다는 것을 의미합니다. 윈도우의 아키텍쳐 상 제한에 대한 몇가지 보고 내용은 다음과 같습니다.
  1. 시스템 상의 2 GB의 공유 가상 주소 공간
  2. 프로세스 당 2 GB의 개별 가상 주소 공간
  3. 660 MB 시스템 PTE 저장공간
  4. 470 MB 페이지 풀 저장공간
  5. 256 MB 페이지 되지 않은 풀 저장 공간

위의 내용은 Windows 2003 기준으로 나열된 사항입니다.(KB 294418 글 참조). 그러므로 Windows XP 및 2000에서는 위의 사항과 다를 수 있습니다.
보통 쉽게 접할 수 있는 권장 사항이 다음과 같은 경우 입니다.
&nbsp; 터미널 서버를 사용하는데, 4GB를 사용하기 전에 공유 메모리인 2G를 완전히 활용하시오.

대부분의 경우 맞기도 하지만, 여러분이 겪는 상황에 따라 다를 수 있습니다. 몇몇 유형 중에, 특정 Windows NT 4.0 또는 Windows 2000 Server에서 충돌이 발생하거나, Windows Server 2003 중에서 불필요할 수도 있습니다. Windows Server 2003으로 넘어오면서 크게 바뀐 부분 중에 보다 효율적으로 이 아키텍쳐상 제한이 발생되는 가능성을 줄였다는 것입니다. 예를 들면 커널 상의 몇가지 프로세스들을 커널 프로세스에서 제외시킴으로써 공유 가상 메모리 사용량을 대폭 줄였습니다.

RAM 및 가상 메모리 사용량 감시하기
성능 감시기(시작, 관리자 도구, 성능)은 시스템의 성능을 측정하고 병목 현상을 실제 일으키는 사항이 무엇인지를 파악할 수 있도록 도와주는 중요한 도구 입니다. 아래에는 이 도구를 이용하여 측정할 수 있는 중요한 정보들에 대한 요약들을 나열합니다.

Memory, Committed Bytes
- 여기서는 가상 메모리의 의존도를 측정하게 됩니다. 운영체제에서 페이지 파일 내에 RAM 페이지 프레임 또는 페이지 슬롯을 적용한(Commited) 바이트 수와 프로세스 상에서 할당한 바이트수가 얼만큼인지를 보여줍니다.(대부분 2가지 동시에). 이 적용 바이트(Committed Byte) 수는 허용된 RAM 용 보다 늘어나게 되면, 페이징이 증가되며, 사용하는 페이지 파일의 총 용량도 증가됩니다. 몇몇 지점에서는 페이징 작업 자체가 실제적인 성능과 직결되어 영향을 미치기 시작할 것입니다.

Process, Working Set, _Total
- 여기서는 "active"하게 사용되는 가상 메모리 용량을 측정하게 됩니다. RAM내의 모든 프로세스들이 실제적으로 사용하는 가상 메모리에 대해 얼만큼의 RAM 필요한지를 보여주게 됩니다. 여기서는 항상 4,096이 곱해져서 나타내는데, 그 이유는 Windows 상에서 페이지 크기로 그 만큼의 크기를 사용하고 있기 때문입니다.가상 메모리가 사용 가능한 RAM 용량을 넘어서서 의존하게 되면, 운영체제 에서는 사용가능한 RAM과 최소 페이징 이용에 대해 최적화하는 Working Set 에 맞추어 프로세스의 가상 메모리의 양을 조절하게 됩니다.

Paging File, %pagefile in use
- 여기서는 페이지 파일이 실제적으로 사용되는 양을 측정하게 됩니다. 페이지 파일이 적절한 크기 인 경우가 언제 인지 측정하기 위해 사용되는 카운터 입니다. 만일 이 카운터가 100을 가지게 되면, 페이지 파일이 완전히 꽉 찼다는 의미가 되며, 몇몇은 작업을 중지하게 될 것입니다. 작업량의 변화에 따라 충분히 큰 페이지 파일이 필요할지 모르지만, 보통 50~70% 이하로 사용되게 됩니다. 만일 사용된 페이지 파일 수가 적다면, 다른 물리 디스크 상에 하나 또는 그 이상을 가질 수 있게 되며, 성능이 증가되게 됩니다.

Memory, Pages/Sec
- 여기서는 대부분은 잘못 인식된 값의 측정되는 내용 중 하나 입니다. 이 카운터의 최고값이 성능이 RAM 부족으로 인해 병목 현상이 발생된 것이라고 정확하게 의미하는 것은 아닙니다. 운영체제에서는 명시된 메모리에 제공될 스왑 페이지와는 다른 목적으로 페이징 시스템이 이용됩니다.

Memory, Pages Output/Sec
- 여기서는 매 초마다 다른 목적으로 RAM 페이지 프레임이 해제되기 위해 가상 메모리 페이지가 페이지 파일로 얼마나 많이 쓰여 졌는지를 보여줍니다. 이 기능은, 페이징이 성능의 병목현상을 일으키고 있는지 여부를 예측할 때 감시 할 때 사용되는 최적의 카운터 입니다.