INFO: COM 서버 활성화 및 NT 윈도우 스테이션

기술 자료 번역 기술 자료 번역
기술 자료: 169321 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

요약

클라이언트가 등록된 클래스의 클래스 개체를 요청하면 COM은 기존의 클래스 개체를 반환하거나 요청된 클래스 개체를 포함하는 것으로 등록된 프로세스를 시작합니다. 프로세스가 생성되거나 "시작"하는 것에 관계 없이 클라이언트 요청에 대해 클래스 개체 참조를 구하는 프로세스를 "활성화"라고 합니다.

특정 조건에서 COM은 기존 클래스 개체가 실행 중이고 다중 사용으로 등록된 경우에도 새 서버 프로세스를 시작할 수 있습니다. 또한 COM이 새 프로세스를 만들면 이 프로세스는 대화형 윈도우 스테이션과 같은 기존 윈도우 스테이션을 공유하지 않고 "윈도우 스테이션"으로 알려진 새 보안 환경에서 시작할 수 있습니다. 윈도우 스테이션에 대한 자세한 내용은 Win32 SDK 설명서에서 해당 구문을 검색하십시오.

활성화 요청 중 새 프로세스와 윈도우 스테이션을 만들기 위해 COM의 알고리즘을 이해하는 것은 여러 가지 이유로 중요합니다. 첫째, COM이 보안 문제로 인해 다중 사용 클래스 개체에 대한 둘 이상의 프로세스 인스턴스를 만들 수 있습니다. 둘째, "단일 사용" 서버가 개별 프로세스에서는 항상 실행되지만 개별 윈도우 스테이션에서는 실행되지 않을 수도 있습니다. 두 개의 COM 서버가 윈도우 메시지나 COM 또는 RPC와 같은 보안 통신 기능을 통해 통신하는 경우와 같이 특별한 경우에 이러한 차이가 응용 프로그램 코드에도 나타날 수 있습니다. 셋째, Windows NT에서 동시에 만들어질 수 있는 윈도우 스테이션의 수가 제한되기 때문에 COM 서버에서 새 윈도우 스테이션을 가져오는 시기를 아는 것이 중요합니다.

본 문서에서는 다른 활성화 시나리오를 살펴보고 새 프로세스와 윈도우 스테이션이 만들어지는 시기에 대해 설명합니다.

추가 정보

COM이 새 서버 프로세스를 만들거나 새 윈도우 스테이션을 새 서버 프로세스에 할당하는 시기는 다음과 같은 여러 요소에 따라 달라질 수 있습니다.
  1. 시작되도록 설정된 COM 클래스의 보안 ID. 클래스의 ID는 DCOMCNFG 도구를 통해 설정될 수 있고 클래스의 AppID 키 아래의 RunAs라는 값에 의해 지정됩니다.
  2. 클래스 개체별 단일 사용 등록 및 다중 사용 등록
  3. 클라이언트 프로세스의 보안 ID(SID). 이 ID는 Windows NT 환경에서 특정 사용자 계정/보안 ID/사용자를 나타내는 숫자 값입니다.
  4. 클라이언트 프로세스의 로그온 식별자(LUID). 새 로그온 식별자는 Windows NT를 실행하는 컴퓨터에 각각 고유하게 로그온하기 위해 생성됩니다. NT 로그온 프롬프트에서 사용자가 사용자 이름과 암호를 입력하거나 win32 API LogonUser를 호출하여 이렇게 로그온할 수 있습니다.
  5. 로컬 및 원격 활성화
  6. 클라이언트의 윈도우 스테이션

다중 사용 클래스

다중 사용 클래스는 CoRegisterClassObject() API를 통해 REGCLS_MULTIPLEUSE 플래그를 지정하는 COM에 등록되는 클래스입니다. 이러한 클래스의 경우 COM은 대개 모든 클라이언트 활성화 요청에 동일한 서버 프로세스 인스턴스를 사용합니다. 그러나 시작하는 사용자의 보안을 유지하면서 실행되거나 일부 다른 경우에 실행되도록 구성된 클래스의 경우 COM은 서비스 활성화 요청에 대해 서버 프로세스의 새 인스턴스를 시작합니다. 이런 식으로 서버 프로세스의 새 인스턴스가 시작되면 서버 프로세스는 새 윈도우 스테이션도 얻을 수 있습니다. 아래에서 여러 시나리오를 살펴보겠지만 먼저, 클래스 개체의 인스턴스가 이미 "다중 사용" 클래스로 등록된 경우 COM이 요청된 클래스 개체를 포함하는 새 프로세스를 시작하는 이유에 대해 간략하게 설명할 것입니다.

첫째, COM 클래스가 "시작하는 사용자"로 실행되도록 시스템에 등록된 경우(좀더 엄밀하게 말하면 AppID가 COM 클래스와 연관된 경우) 시스템 관리자는 이 클래스와 관련된 특정 보안 정책을 설정했습니다. 이 정책에서 활성기(activator)는 활성 코드와 동일한 보안 컨텍스트에서 실행 중인 프로세스 내의 클래스 개체를 받아야 합니다.

이 보안 정책은 모든 활성화 요청에 대해 REGCLS_MULTIPLEUSE로 표시되는 단 하나의 클래스 팩터리 개체를 가지는 서버 정의 동작과 충돌할 수 있습니다. COM은 응용 프로그램 동작보다 보안 정책에 우선 순위를 둡니다. 따라서 "시작하는 사용자"로 실행하도록 등록된 다중 사용 서버는 다중 사용의 일반 규칙에 따라 동작하지 않습니다. 새 프로세스는 각각의 활성화하는 보안 사용자에 대해 시작됩니다.

둘째, 주어진 CLSID에 대해 지정된 보안 컨텍스트와 다른 컨텍스트에서 실행 중인 COM에 의해 시작되지 않는 프로세스가 이 CLSID를 등록하면 등록에 실패합니다. 이 경우 CoRegisterClassObject는 오류 코드 CO_E_WRONG_SERVER_IDENTITY를 반환합니다. 또한 활성화 요청이 나중에 도착하면 새 프로세스는 CLSID/AppID에 대해 지정된 보안 컨텍스트에서 COM에 의해 시작됩니다. COM은 CoRegisterClassObject()를 호출하는 코드(보안되지 않는 작업)를 신뢰할 수 없고 레지스트리 설정(레지스트리는 보안 데이터베이스임)만 신뢰하여 클래스 개체와 그 실행 방법을 확인할 수 있습니다. 이렇게 하여 승인 받지 않은 사용자가 클래스 개체를 시스템 규모로 불법 위장(spoofing)할 수 없게 합니다.

이것을 고려하여 COM이 다중 사용 서버를 시작할 때 새 프로세스와 윈도우 스테이션이 만들어지는 시기에 대한 문제를 살펴봅니다. 클라이언트의 LUID는 다중 사용 클래스의 경우 어떤 방식을 사용해도 관계 없습니다.
  1. "대화형 사용자" 보안 ID. 다중 사용 COM 클래스의 AppID가 "대화형 사용자" ID로 실행되도록 구성된 경우 제일 첫 번째 서버 프로세스와 해당 클래스 개체는 COM에서 이후의 모든 활성화 요청을 제공하도록 사용됩니다. 서버 인스턴스가 있으면 이 서버 인스턴스에는 대화형 윈도우 스테이션이 있습니다. 로컬로 로그온한 사용자가 없으면 모든 활성화 요청이 실패합니다. 위에서 언급한 것처럼 COM에서 시작하지 않고 대화형 윈도우 스테이션에서 실행하지 않는 프로세스가 CLSID를 등록하면 이 등록은 실패합니다. 또한 활성화 요청이 나중에 도착하면 새 프로세스는 대화형 사용자의 보안 컨텍스트에서 시작됩니다. 이렇게 하여 클래스 개체를 불법으로 위장(spoofing)할 수 없게 합니다. 추가 서버 프로세스가 COM에 의해 시작된 적이 없으므로 새 윈도우 스테이션에 대한 문제는 이론에 불과합니다. 클라이언트의 SID 또는 LUID, 클라이언트가 로컬인지 원격인지 여부는 이 경우에 아무런 관계가 없습니다.
  2. "이 사용자" 보안 ID. 마찬가지로 다중 사용 COM 클래스의 AppID가 "이 사용자"(미리 정의된 보안 ID)로 실행되도록 구성된 경우 첫 번째 서버 프로세스와 해당 클래스 개체는 COM에서 이후의 모든 활성화 요청을 제공하도록 사용됩니다. 이 첫 번째 서버 인스턴스에는 첫 번째 프로세스 작성 중에 만들어진 전용 윈도우 스테이션이 있습니다. 추가 서버 프로세스가 COM에 의해 시작된 적이 없으므로 추가 윈도우 스테이션에 대한 문제는 이론에 불과합니다. 클라이언트의 SID 또는 LUID, 클라이언트가 로컬인지 원격인지 여부는 이 경우에 아무런 관계가 없습니다. 동일한 사용자가 대화형 winstation에 현재 로그온되는 경우에도 새 윈도우 스테이션은 "이 사용자"로 실행하도록 구성된 class/AppID의 첫 번째 인스턴스를 실행할 때 만들어집니다. 현재 로그온된 사용자의 ID를 고려하지 않는 문제로 인해 클래스의 동작이 달라지므로 COM은 "이 사용자"로 실행하도록 구성된 서버를 실행하는 데 대화형 winstation을 사용하지 않습니다. 위에 언급한 것처럼 COM에서 시작하지 않고 "이 사용자"에서 지정된 계정에서 실행하지 않는 프로세스가 CLSID를 등록하려고 하면 이 등록은 실패하고 활성화 요청이 나중에 도착하면 "이 사용자" 계정에서 새 프로세스가 시작됩니다. 이렇게 하여 클래스 개체를 불법으로 위장(spoofing)할 수 없게 합니다. 반면에 지정된 CLSID/APPID에 대해 등록된 프로세스가 "이 사용자"로 실행하도록 구성되고 COM이 아닌 특정 에이전트에 의해 적절한 사용자 계정에서 만들어진 다음(예를 들어, 대화형 사용자가 "이 사용자"와 동일한 사용자일 때 대화형 사용자에 의해 실행되거나 "이 사용자"와 동일한 보안 컨텍스트에서 실행 중인 서비스에 의해 CreateProcess()를 통해 시작됨) 해당 REGCLS_MULTIPLEUSE 클래스 개체를 등록하면 COM은 기존의 실행 중인 클래스 개체를 사용하여 모든 클라이언트에서 들어오는 후속 활성화 요청을 만족시킵니다.
  3. "시작하는 사용자" 보안 ID. 이 경우 클래스의 AppID는 "시작하는 사용자" ID에서 시작하도록 설정됩니다(이 클래스를 "Activate as Activator" 클래스라고도 함). a. 로컬 클라이언트. 먼저 로컬 시스템의 경우를 고려해봅니다. 여기에는 두 가지 규칙이 있습니다. 1. 각각의 다른 활성화 클라이언트 SID를 사용하면 동일한 윈도우 스테이션에서도 COM이 서버 프로세스의 새 인스턴스를 시작할 수 있습니다. 2. SID와 일치하는 경우에도(예를 들어, 동일한 사용자가 단일 NT 시스템에 두 번 이상 로그온되는 경우) 각각의 다른 로컬 클라이언트 윈도우 스테이션에서는 COM이 서버 프로세스의 새 인스턴스를 시작할 수 있습니다. 즉, 시작하는 사용자 ID의 다중 사용 서버는 윈도우 스테이션에서 절대로 공유되지 않습니다. 동일한 SID 및 동일한 윈도우 스테이션을 가진 모든 클라이언트 프로세스는 동일한 윈도우 스테이션에서 단일 서버 프로세스를 공유합니다. 서버가 클라이언트의 윈도우 스테이션을 공유하므로 새 윈도우 스테이션은 만들어지지 않습니다. 예를 들어, a_domain\a_user로 대화형 로그온되는 것을 가정해봅니다. 모두 서버(대화형 윈도우 스테이션이 있음)의 동일한 인스턴스에 연결되는 클라이언트의 여러 인스턴스를 실행합니다. a_domain\a_user에서 시작하도록 설정된 서비스에 해당하는 클라이언트가 있다고 가정합니다. 이 서비스는 COM 서버의 새 인스턴스를 시작합니다. 이것은 서비스 프로세스에 대화형 윈도우 스테이션이 아닌 윈도우 스테이션이 있으므로 서비스(클라이언트) 프로세스의 ID가 실행 중인 서버 프로세스(a_domain\a_user) ID와 같더라도 COM에서 서버의 새 인스턴스가 시작될 수 있기 때문입니다. 그러나 새 윈도우 스테이션은 COM 서버 프로세스에 대해 만들어지지 않습니다. 서버가 서비스의 윈도우 스테이션을 계속 상속합니다. 서비스가 LocalSystem에서 시작하고 데스크톱과 상호 작용하도록 설정되면(제어판의 서비스 애플릿에서 "서비스와 데스크톱 상호 작용 허용" 확인란 참조) 이 서비스는 대화형 윈도우 스테이션이나 winsta0에서 실행됩니다. 이 경우 COM은 대화형 윈도우 스테이션에서 서버의 새 인스턴스를 계속 시작합니다. 여기서 LocalSystem인 클라이언트의 SID는 해당 서버의 SID(a_domain\a_user)와 다릅니다. b. 원격 클라이언트. 원격 활성화의 경우 위의 로컬 경우와 달리 클라이언트가 원격이므로 COM은 클라이언트의 윈도우 스테이션을 무시합니다. 여기에서는 각각의 새 클라이언트 SID를 사용하여 해당 서버 프로세스의 새 인스턴스를 시작하고 각각의 새 서버 프로세스가 새로운 윈도우 스테이션을 가져오는 것이 규칙입니다. 동일한 SID를 사용하여 원격 클라이언트에 의해 수행된 후속 활성화 요청은 해당 프로세스와 윈도우 스테이션뿐 아니라 기존의 등록된 클래스 개체를 다시 사용합니다. 예를 들어, 10개의 다른 시스템에서 a_domain\a_user로 로그온된다고 가정합니다. 이 모든 시스템의 클라이언트가 해당 서버 시스템에서 동일한 서버 인스턴스에 연결됩니다. a_domain\b_user 시스템의 클라이언트가 새 서버 인스턴스와 새 윈도우 스테이션을 시작합니다. 요청된 CLSID에 대해 등록된 COM 서버를 실행한 로컬 사용자와 동일한 SID를 갖는 원격 호출자는 기존의 클래스 개체를 다시 사용합니다. 그러나 이 경우 COM 서버가 시작되는 순서가 중요합니다. 서버가 먼저 로컬 클라이언트에 의해 시작되면 같은 SID를 갖는 원격 클라이언트가 이 서버에 연결됩니다. 반면에 서버가 먼저 원격 클라이언트에 의해 시작되면 같은 SID를 갖는 로컬 클라이언트가 서버의 새 인스턴스를 시작합니다. 여기서 다시 위에서 언급한 윈도우 스테이션 규칙으로 돌아갑니다. 로컬 클라이언트의 경우에는 클라이언트의 윈도우 스테이션과 서버의 윈도우 스테이션이 일치해야 하고 원격 클라이언트의 경우에는 클라이언트의 윈도우 스테이션이 무시됩니다. 예를 들어, 로컬 클라이언트 a_domain\a_user가 먼저 서버를 시작하면 원격 클라이언트 a_domain\a_user가 이 서버에 연결됩니다. 반대로 원격 클라이언트 a_domain\a_user가 먼저 서버를 시작하면 로컬 클라이언트 a_domain\a_user가 새 서버 인스턴스와 새 윈도우 스테이션을 시작합니다. 클라이언트의 LUID는 이 경우에 아무런 관계가 없습니다.
  4. 서비스 기반 COM 서버. 서비스가 한 번만 시작될 수 있으므로 Win32 서비스에 패키지된 COM 클래스/AppID는 다중 사용 서버여야 합니다. 이 경우 첫 번째 활성화 요청 시 새 프로세스는 자신의 전용 윈도우 스테이션에서 시작됩니다. 이에 대한 예외가 두 가지 있습니다. a. LocalSystem 계정에서 시작하도록 서비스가 설정되면 이 서비스는 시스템의 미리 정의된 윈도우 스테이션을 상속합니다. b. LocalSystem 계정에서 시작하도록 서비스가 설정되고 데스크톱과 상호 작용할 수 있으면 이 서비스는 대화형 윈도우 스테이션이나 winsta0을 상속합니다. 모든 후속 활성화 요청은 로컬이든 원격이든 관계 없이 서비스의 클래스 개체에 의해 처리됩니다. 위에서 언급한 것처럼 COM에서 시작되지 않고 지정된 서비스로 실행되지 않는 프로세스가 CLSID를 등록하면 이 등록은 실패하고 활성화 요청이 나중에 도착하면 등록된 서비스가 시작됩니다. 이렇게 하여 클래스 개체를 불법으로 위장(spoofing)할 수 없게 합니다.

단일 사용 클래스

참고: 가능하면 단일 사용 클래스는 피해야 합니다. 단일 사용 등록은 기존의 설정으로, 이전 COM 응용 프로그램을 지원하고 기존의 비 COM 응용 프로그램을 COM으로 쉽게 포팅하기 위한 것입니다. 새 클래스는 다중 사용 클래스 개체 등록을 지원하도록 설계되는 것이 매우 좋습니다. 이것은 "이 사용자" ID를 갖는 서버의 경우에 특히 그렇습니다. 여기에서 단일 사용 클래스는 다중 사용 클래스에 정확히 반대되는 결과를 가져올 수 있습니다. 아래의 설명에서와 같이 단일 사용 클래스는 활성화마다 새 서버 프로세스와 새 윈도우 스테이션을 만들기 때문에 Windows NT에 리소스 문제가 발생할 수 있습니다.

단일 사용 클래스는 CoRegisterClassObject() API를 통해 REGCLS_SINGLEUSE 플래그를 지정하는 COM에 등록된 클래스입니다. 이러한 클래스의 경우 COM은 항상 모든 클라이언트(로컬 또는 원격)의 각 활성화 요청에 대해 해당 클래스의 서버 프로세스에서 새 인스턴스를 시작합니다. 여기서 해결해야 할 문제는 다음과 같습니다. 서버가 언제 새 윈도우 스테이션도 가져옵니까?
  1. "대화형 사용자" 보안 ID. 단일 사용 클래스가 해당 AppID를 통해 "대화형 사용자" ID에서 시작하도록 설정되는 경우가 이러한 경우에 해당합니다. 이 경우 서버 프로세스에 대한 각각의 새 인스턴스가 있으면 이 새 인스턴스는 항상 대화형 윈도우 스테이션을 공유합니다. 로컬로 로그온한 사용자가 없으면 모든 활성화 요청에 실패합니다. COM에서 새 윈도우 스테이션이 만들어지지 않습니다.
  2. "이 사용자" 보안 ID. 이제 단일 사용 COM 클래스의 AppId가 "이 사용자" ID에서 실행하도록 설정되는 경우를 고려해봅니다. 이 경우 규칙은 매우 단순합니다. 모든 새 클라이언트 활성화가 새 윈도우 스테이션에서 새 프로세스를 시작합니다. 이것은 "이 사용자"로 지정된 사용자가 모든 활성화를 요청할 때 대화형 윈도우 스테이션에 로그온되는지에 관계 없이 적용됩니다.
  3. "시작하는 사용자" 보안 ID. a. 로컬 클라이언트. 로컬 시스템 활성화 시나리오에서 서버 프로세스는 클라이언트의 윈도우 스테이션을 항상 가져옵니다. 새 윈도우 스테이션이 만들어진 적은 없습니다. 예를 들어, 대화형으로 a_domain\a_user로 로그온되고 클라이언트 프로그램의 여러 인스턴스를 실행한다고 가정합니다. 이 경우 서버 각각의 새 인스턴스는 대화형 윈도우 스테이션을 가져옵니다. 클라이언트가 로컬 시스템 계정에서 실행 중인 서비스라고 가정합니다. 이 경우 COM 서버는 서비스 프로세스의 윈도우 스테이션을 공유합니다. b. 원격 클라이언트. 원격 활성화 경우에 클라이언트가 원격이므로 COM은 클라이언트의 윈도우 스테이션을 무시합니다. 항상 그렇듯이 새 서버 인스턴스 프로세스는 각각의 원격 활성화를 위해 시작됩니다. 해당 규칙은 다음과 같습니다. 1. 각각의 새 원격 클라이언트 SID의 경우 새 윈도우 스테이션은 서버 프로세스에 대해 만들어집니다. 2. 각각의 새 원격 클라이언트 LUID의 경우 새 윈도우 스테이션은 서버 프로세스에 대해 만들어집니다. 3. 동일한 SID/LUID 쌍을 갖는 모든 원격 클라이언트는 동일한 윈도우 스테이션을 공유하는 서버를 만듭니다. 예를 들어, a_domain\a_user로 원격 클라이언트 시스템에 로그온됩니다. 이 클라이언트는 새 윈도우 스테이션을 가져오는 원격 서버를 시작합니다. 이제 a_domain\a_user가 동일한 클라이언트 시스템에서 클라이언트 응용 프로그램의 또 다른 인스턴스를 시작하고 원격 시스템에서 서버의 새 복사본이 시작되면 이 서버는 원래 서버의 윈도우 스테이션을 공유합니다. 다른 시스템에 a_domain\a_user로 다시 로그온하여 거기에서 클라이언트를 실행한다고 가정합니다. 해당하는 서버 인스턴스에 새 윈도우 스테이션이 있습니다. 이것은 클라이언트 SID가 동일한 경우에도 또 다른 클라이언트가 다른 LUID를 갖기 때문에 해당 서버 프로세스가 새 윈도우 스테이션을 가져온다는 것을 보여줍니다.
  4. 서비스 기반 COM 서버. 단일 사용 클래스를 Windows NT 서비스로 구현하지 말아야 합니다. 그 이유는 Windows NT 서비스 프로세스의 여러 인스턴스를 실행할 수 없기 때문입니다.

테이블 요약 시나리오

---------------------------------------------------------------------------------------------------
                                다중 사용 서버
                          (클래스 팩터리가 재사용을 요청함)
                                활성화 모드
---------------------------------------------------------------------------------------------------
클라이     대화형                 "이 사용자"            "시작하는                 Win32
언트       사용자                                           사용자"                서비스

				
로컬       첫 번째                 첫 번째                 첫 번째                   첫 번째
           활성화 요청 시          활성화 요청 시          요청 시                   활성화 요청 시
           대화형 윈도우           새 윈도우               클라이언트 윈도우         서비스가
           스테이션에서            스테이션에서            스테이션에서              시작되며
           프로세스가 시작되며     프로세스가 시작되며     프로세스가 시작되며       (서비스
           후속 요청은             후속 요청은             동일한 SID/윈도우         구성에 따라
           기존 클래스             기존 클래스             스테이션의 후속 요청은    새 winsta
          개체를 가져오고         개체를 가져옴           기존 클래스 개체를        또는
           사용자가 로컬로                                 가져오고                  시스템/대화형
           로그온되지 않으면                               SID가 같은 경우에도      winsta에서 시작)
          활성화에                                        윈도우 스테이션 간       요청이 
           실패함                                          클래스                   기존 클래스
                                                           개체를                   개체를             
                                                           공유하지 않음            가져옴            
----------------------------------------------------------------------------------------------------                                                                                     
원격                                                       SID에 의한    
                                                           첫 번째 활성화 요청 시 
                                                           새 winsta에서 프로세스가
                                                           시작되며 같은 SID에 의한    
                                                           후속 원격 요청이 
                                                           기존 클래스 개체를 
                                                           가져옴. 
                                                    로컬 사용자에서    
                                                           시작된 클래스는 
                                                           같은 SID를 가진 
                                                           원격 호출자가   
                                                           재사용함 
----------------------------------------------------------------------------------------------------                                                      
				


----------------------------------------------------------------------------------------------------
                             단일 사용 서버
                 (각 활성화 요청에 대해 만들어진 새 프로세스)
                             활성화 모드
----------------------------------------------------------------------------------------------------
클라이      대화형              "이 사용자"       "시작하는                Win32
언트        사용자                                 사용자"                서비스

				
로컬        대화형 윈도우        새 윈도우         항상                      N/A(단 
            스테이션 활성화에    스테이션에서      클라이언트 프로세스의     하나의
            실패하지 않은 경우   프로세스가        윈도우 스테이션에서       활성화만
            대화형 윈도우        항상 시작됨       프로세스가                가능함)
           스테이션에서                           시작됨             
            프로세스가                                            
            항상 시작됨                                           
----------------------------------------------------------------------------------------------------
원격                                              클라이언트의 
                                                  SID 및 LUID 모두     
                                                  이전 클라이언트    
                                                  활성화와 일치하면 
                                                  기존 윈도우     
                                                  스테이션에서
                                                  프로세스가 시작되고     
                                                  그렇지 않으면 
                                                  새 윈도우 스테이션에서
                                                  시작됨 
----------------------------------------------------------------------------------------------------  
				

윈도우 스테이션 및 Windows NT 리소스

이 절에서는 Windows NT에서 새 윈도우 스테이션을 만드는 의미와 이것이 COM 서버의 구성에 영향을 미치는 방법에 대해 설명합니다. 다음에 설명하겠지만 Windows NT 시스템에서 만들어질 수 있는 윈도우 스테이션의 수에는 제한이 있습니다. 제한된 수를 초과하면 Windows NT는 COM에서 서버 프로세스의 새 인스턴스를 실행하려는 시도에 실패합니다. 일반적으로 다음과 같은 오류 메시지가 나타납니다.
d:\winnt\system32\kernel32.dll을(를)
초기화하지 못했습니다. 프로세스가
비정상적으로 종료되고 있습니다.
Windows NT의 각 윈도우 스테이션에는 적어도 하나의 연관된 데스크톱이 있습니다. Windows NT는 데스크톱에서 실행하는 모든 Windows 응용 프로그램에 특수한 메모리 힙을 사용합니다. 기본적으로 각 데스크톱 힙은 3MB의 메모리를 소모합니다. Windows NT는 최대 48MB까지 데스크톱 힙을 만들 수 있도록 제한되어 있습니다. 이것은 Windows NT 시스템에서 만들어질 수 있는 윈도우 스테이션의 최대 수가 16임을 의미합니다. 윈도우 스테이션이 두 개 이상의 데스크톱을 포함할 수 있기 때문에 더 작아질 수 있습니다. 이 수를 늘리기 위해 레지스트리 편집기에서 레지스트리를 편집하여 기본 데스크톱 힙 크기를 줄일 수 있습니다.

경고: 레지스트리 편집기를 잘못 사용하면 심각한 문제가 발생할 수 있으며 문제를 해결하기 위해 Windows NT를 다시 설치해야 할 수도 있습니다. Microsoft는 레지스트리 편집기를 잘못 사용하여 발생하는 문제의 해결을 보증하지 않습니다. 이 도구의 사용에 따른 모든 책임은 사용자에게 있습니다.

편집해야 하는 명명된 값은 다음 레지스트리 키에 나타납니다.
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
				
"Windows"라는 값을 편집해야 합니다. 이것은 REG_SZ 문자열입니다. 문자열을 편집하고 "Shared Section=1024,3072"를 찾습니다. 이 값을 "Shared Section=1024,3072,512"로 수정합니다. 이 변경 내용을 적용하려면 시스템을 다시 시작해야 합니다. 위와 같이 변경함으로써 대화형 윈도우 스테이션의 데스크톱에 대해 3MB(기본값) 힙 크기를, 모든 비 대화형 데스크톱에 대해 512KB를 지정합니다. 첫 번째 매개 변수는 더 이상 사용되지 않지만 변경해서는 안됩니다. 이렇게 변경하면 약 48MB/512KB나 96개 미만의 윈도우 스테이션을 만들 수 있습니다.

참고: 윈도우 스테이션 내에 여러 개의 데스크톱이 포함될 수 있습니다. 위에서 설명한 "시작하는 사용자" 서버에서 로컬 클라이언트 프로세스의 윈도우 스테이션이 언급될 때마다 이것을 좀더 간단하게 "윈도우 스테이션 및 데스크톱"이라고 할 수 있습니다. "시작하는 사용자" 설정은 실제로 기존의 비 DCOM 인식 서버에 사용되지만 거의 사용해서는 안됩니다. 이러한 기존의 서버는 자신의 데스크톱에서 실행됩니다. 따라서 MULTIPLEUSE "시작하는 사용자" 서버의 경우 동일한 윈도우 스테이션 내의 다른 데스크톱에 있는 각 클라이언트 프로세스로 인해 새 서버 프로세스가 해당 윈도우 스테이션/데스크톱에서 시작될 수 있습니다. SINGLEUSE "시작하는 사용자" 서버의 경우 서버가 클라이언트 프로세스의 윈도우 스테이션/데스크톱을 상속합니다.

Windows NT 4.0 서비스 팩 4.0에서 COM은 윈도우 스테이션을 다시 사용하려고 합니다. 이에 앞서 서버가 특정 사용자로 실행하도록 설정되고 서버 프로세스의 여러 인스턴스가 시작되면 각 프로세스는 자신의 윈도우 스테이션을 가져옵니다. 이렇게 하여 위에서 설명한 윈도우 스테이션 제한 사항이 생깁니다. SP4에서 COM은 동일한 윈도우 스테이션에 있는 동일한 사용자 ID(또는 토큰)에서 실행하도록 설정되는 모든 RunAs(즉, "Activate as Activator" 또는 "시작하는 사용자"가 아님) 서버를 만들려고 시도합니다.

이렇게 하면 여러 서버 프로세스가 동일한 토큰에서 실행되는 경우에 데스크톱 힙 크기를 조정할 필요가 없습니다. 해당 구성에서 모든 서버가 동일한 사용자로 실행하도록 설정되거나 동일한 RunAs 서버 프로세스의 여러 인스턴스가 실행되면 본 문서에서 제안한 것처럼 데스크톱 힙 크기를 줄이지 마십시오. 이 경우 기본 값(3M)으로 유지하는 것이 좋습니다. 그 이유는 데스크톱 힙을 줄이면 시스템에서 더 많은 윈도우 스테이션/데스크톱을 만들 수 있기 때문입니다. 그러나 윈도우 스테이션/데스크톱에서 실행할 수 있는 프로세스의 수는 점점 줄어들 수 있습니다.

반면에 해당 구성에서 다른 토큰으로 실행하는 여러 서버가 있으면 윈도우 스테이션 제한 사항이 생깁니다. 이 경우 데스크톱 힙 크기를 줄이려면 본 문서에서 제안하는 대로 수행해야 합니다.

참조

데스크톱 힙 문제에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

142676 User32.dll 초기화 실패 오류 해결




Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.

속성

기술 자료: 169321 - 마지막 검토: 2005년 7월 11일 월요일 - 수정: 1.2
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft OLE 4.0?을(를) 다음과 함께 사용했을 때
    • Microsoft Platform Software Development Kit-January 2000 Edition
키워드:?
kbinfo kbinterop kbapi kbenv kbprogramming kbkernbase kbdcom kbusage KB169321

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com