文章編號: 169321 - 上次校閱: 2005年7月11日 - 版次: 2.5

資訊: COM 伺服器啟動和 Windows NT 電台

中英文對照顯示按一下這裡顯示機器翻譯的中英文對照
機器翻譯檢視機器翻譯免責聲明
檢視此文章適用的產品。
系統提示本文適用於您使用的作業系統之外的作業系統。與您不相關的文章內容已停用。

在此頁中

全部展開 | 全部摺疊

結論

當用戶端要求的已註冊類別的類別物件時，COM 傳回現有的類別物件，或啟動登錄為包含要求的類別物件的處理序。取得類別物件參考提出要求的用戶端 (會導致處理序建立或 「 啟動 」) 的處理程序就稱為 [啟動]。

在某些情況下 COM 可能啟動新的伺服器處理序，即使當現有的類別物件正在執行，而且已經登錄為多個使用。 此外，COM 建立新的處理程序時該處理程序可能會啟動在新的安全性環境著名的視窗工作站而不是共用如互動式視窗工作站的現有視窗工作站。(如需有關視窗工作站的詳細資訊，搜尋 Win32 SDK 文件，該的片語)。

瞭解 COM 的演算法，於啟動要求期間建立新的處理序和視窗工作站是重要幾個原因。 首先，COM 可能會因為的安全性問題建立多個使用類別物件的一個以上的處理程序執行個體。第二個，"單使用 「 伺服器將永遠啟動個別處理序中但它們可能或可能不在個別的視窗工作站中啟動。這項差異可能資訊清單本身中某些罕見的情況下例如兩個 COM 伺服器嘗試透過視窗訊息] 或 [安全通訊機能，例如 COM 或 RPC 通訊的應用程式程式碼。第三，因為同時可在 Windows NT 中建立的視窗工作站的數目是有限的務必知道當您的 COM 伺服器取得新的視窗工作站。

本文將探討不同啟動案例，並說明建立新的處理序和視窗工作站的時。
回此頁最上方

其他相關資訊

當 COM 會建立新的伺服器處理序，或將新的視窗工作站指派給新的伺服器處理序取決於幾個因素：
  1. 安全性識別在其下 COM 類別設為啟動。類別的識別身份可以經由 DCOMCNFG 工具設定，和由 RunAs 名為類別的 AppID 機碼下的值指定。
  2. 類別物件由單一使用對多重使用註冊。
  3. (這是數值，表示特定使用者帳戶/安全性識別/主體 Windows NT 環境中) 的用戶端處理序的安全性 Identifier(SID)。
  4. 登入識別元 (LUID) 的用戶端處理程序 (一個新的登入識別項產生每個唯一的登入到執行 Windows NT 的電腦。這個登入可能透過使用者名稱和密碼在 NT 登入提示字元中輸入的使用者或透過呼叫 win32 API LogonUser)。
  5. 本機與遠端啟動。
  6. 用戶端的視窗站。
回此頁最上方

多重使用類別

使用多個類別是使用指定 REGCLS_MULTIPLEUSE 旗標 (透過 CoRegisterClassObject() API) COM 註冊的類別。這種類別的 COM 通常為所有的用戶端啟動要求使用相同的伺服器處理序執行個體。不過，設定成在安全性執行啟動的使用者，並在 [其他少數的情況下執行的類別為 COM 啟動伺服器處理序服務的啟動要求的新執行個體。當因此啟動伺服器處理序的新執行個體時有可能伺服器處理序會取得新視窗工作站也。我們將探討各種的案例下面的，但首先我們會討論簡要為什麼 COM 啟動類別物件的執行個體已經註冊為 「 多重使用 「 類別時，包含要求的類別物件的新處理程序。

第一個 COM 類別時 (更準確時的 AppID 聯 COM 類別) 係以 「 啟動使用者 」 身分執行系統，系統管理員已設定至該類別特定安全性原則。原則是一個啟動項應該會收到相同的安全性內容，以啟動的程式碼正在執行的處理序內的類別物件。

此安全性原則可以進入伺服器定義的表現方式，讓所有啟動要求 (如 REGCLS_MULTIPLEUSE 所指示) 的只有一個類別工廠物件的衝突。COM 透過應用程式行為優先順序的安全性原則。如此一來註冊為 「 啟動使用者 」 身分執行的多個使用伺服器不將根據多重使用的一般規則來行為。針對每個啟動的安全性主體，就會啟動新的處理程序。

第二個，如果不由不同於給定的 CLSID 所指定的安全性內容中執行的 COM 啟動處理程序會登錄該 CLSID，該登錄將會 fail(CoRegisterClassObject will return an error code CO_E_WRONG_SERVER_IDENTITY in this case)。如果啟動要求稍後到達新的處理程序將會由啟動 COM 與所指定的 CLSID/AppID 的安全性內容。COM 不能信任程式碼呼叫 CoRegisterClassObject() (不安全作業)，它只可以信任 (登錄是安全的資料庫) 的登錄設定來決定哪一個類別物件使用以及如何執行它。這種行為可以避免非法全機器詐騙的未經授權的使用者類別物件。

知道這一點之後，我們現在回到問題的當新的處理序和視窗工作站時，會建立多重使用伺服器啟動的 COM。 請注意用戶端 LUID 不以任何方式在多重使用類別的情況下重要。
  1. 互動使用者 」 的安全性識別。 在多重使用 COM 類別的 AppID 設定為以互動使用者 」 身分識別身分執行的地方最情況下非常第一個伺服器處理序和其類別物件將由使用 COM 來服務所有後續的啟動要求。此伺服器執行個體將會有互動式的視窗] 電台，如果有的話) (如果沒有使用者登入本機然後所有啟動要求將會都失敗)。 如上所述，如果由 COM 不啟動處理程序並不在互動式視窗工作站中執行註冊 CLSID，該登錄將會失敗。如果啟動要求稍後到達，新的處理序啟動與互動式使用者的安全性內容。這種行為可以避免非法詐騙類別物件。 因為沒有任何額外的伺服器處理序曾經由 COM 啟動，新的視窗工作站的問題是 moot。用戶端的 SID，其 LUID 或是否本機或遠端並不會有任何影響在這種情況下。
  2. 「 此使用者 」 的安全性識別。 如果多重使用 COM 類別的 AppID 同樣，設定成 「 此使用者 」 執行 (預先定義的安全識別碼)，第一部伺服器處理]，且 COM 會使用其類別物件來服務所有後續的啟動要求。這個第一個伺服器執行個體將會有建立的第一個處理程序建立一部份為其本身視窗工作站。因為沒有任何額外的伺服器處理序曾經由 COM 啟動，其他的視窗工作站的問題是 moot。用戶端的 SID，其 LUID 或是否本機或遠端並不會有任何影響在這種情況下。 請注意當您啟動設定為以 「 此使用者 」，身分執行，即使同一個使用者目前登入在互動式 winstation 一個類別/AppID 的第一個執行個體時，將會建立新的視窗工作站。COM 永遠不會使用互動式 winstation 來啟動伺服器，設定為以 「 此使用者 」 身分執行，因為會導致不同的行為，為類別的目前登入使用者的識別不相關的問題而定。 如上所述，如果由 COM 不啟動處理程序並不在 [本使用者] 中所指定之帳戶中執行嘗試註冊 CLSID 的註冊將會失敗並啟動要求如果稍後到達新的處理程序就會啟動 「 此使用者 」 帳戶中。這種行為可以避免非法詐騙類別物件。 在另一方面，如果處理序登錄為給定的 CLSID/AppID 設定為以 「 此使用者 」 身分執行，便會建立在適當的使用者帳戶由 COM 以外的其他一些代理程式 (比方說它執行由互動式使用者互動式使用者是相同的使用者為 「 這個使用者 」 或透過 CreateProcess() 啟動服務，以 「 此使用者 」 相同的安全性內容中執行時)，及再註冊其 REGCLS_MULTIPLEUSE 類別物件，請 COM 將使用現有的執行類別物件滿足後續來自任何用戶端的連入啟動要求。
  3. "啟動使用者 」 的安全性識別。 在這種情況下該類別的 AppID 設定為在啟動使用者 」 idenitity (這也稱為是"為啟動項啟動 」 的類別) 下啟動。 a.本機用戶端。 首先考慮本機機器大小寫。有兩個規則: 1 每個不同的啟動用戶端的 SID 將會導致 COM 啟動伺服器處理序，即使是在相同的視窗工作站的新執行個體。 2.甚至對於符合的 SID (例如大小寫，其中相同的使用者登入一次以上一部 NT 電腦)，每個不同的本機用戶端視窗工作站會導致 COM 啟動伺服器處理序的新執行個體。 亦即在視窗工作站之間永遠不會共用執行啟動的使用者身分識別多重使用伺服器。具有相同的 SID 和相同的視窗工作站的所有用戶端處理程序將會共用單一伺服器處理程序，在相同的視窗站。因為伺服器共用視窗工作站的用戶端會建立沒有新的視窗電台。 比方說假設您以互動方式登入為 a_domain\a_user。您執行用戶端均可將連接到相同的執行個體的伺服器 (具有互動式視窗工作站) 多個執行的個體。現在讓我們假設您有用一個戶端，是一服務設定為啟動 a_domain\a_user 下啟動。此服務將會啟動 COM 伺服器的新執行的個體。會發生這種情況是因為 COM 會導致要啟動因為服務處理序都有視窗工作站而不是互動式的視窗站--即使 service(client) 處理序識別，是執行伺服器處理序 (a_domain\a_user) 識別相同伺服器的新執行個體。不過，請注意沒有新的視窗工作站為 COM 伺服器處理序建立。伺服器仍會繼承視窗工作站的服務。如果服務設定在 LocalSystem 下啟動，並與桌面互動 (請參閱 「 服務 」 中的 「 允許服務來互動與桌面 」 核取方塊在控制台中的小程式)，然後服務會在互動式視窗工作站或 winsta0 中執行。在這種情況下 COM 會仍然啟動新的例項 (也就是 LocalSystem 用戶端的 SID 在這種情況下是不同的伺服器的 SID 也就是 a_domain\a_user) 伺服器的互動式視窗工作站中。 b.遠端用戶端。 在遠端啟動的情況下 COM 會忽略視窗工作站的用戶端，因為用戶端是與上述本機的大小寫不同的是遠端。 這裡的規則是每個新的用戶端的 SID 將導致伺服器處理序啟動的新執行個體，且每個新的伺服器處理序會得到新的視窗工作站。後續啟動要求由遠端用戶端具有相同的 SID 將重複使用現有登錄類別物件為其處理程序和視窗工作站。比方說假設您登入為 a_domain\a_user 10 個不同的機器上。 所有這些機器從用戶端將會連線到相同的執行個體的伺服器機器上伺服器。從 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 伺服器。 一個 COM 類別/AppID 的封裝在 Win32 服務是實用的必要性多重使用伺服器因為只有一次啟動服務。在這種情況下在第一個啟動要求新的處理程序會在它自己的視窗工作站中啟動。有兩個例外狀況： a.服務設為啟動 LocalSystem 帳戶下，如果它將繼承系統預先定義的視窗工作站。 b.如果服務設定為 LocalSystem 帳戶下啟動，且可以與桌面互動，它將繼承互動式視窗工作站或 winsta0。所有的後續啟動要求無論是本機或遠端，是由處理服務的類別物件。 如上所述，如果由不啟動處理序 COM 並沒有執行所指定的服務登錄 CLSID，該登錄將會失敗，如果啟動要求稍後到達已註冊的服務就會啟動。這種行為可以避免非法詐騙類別物件。
回此頁最上方

使用類別

注意: 使用單一類別應該避免使用盡可能。單一使用註冊是舊版的設定，並旨在支援較舊的 COM 應用程式，並簡化移植舊版非 COM 應用程式至 COM。 強烈建議新的類別設計來支援多重使用類別的物件登錄。本使用者 」 身分的伺服器的情況下特別是使用單一類別造成完全相反的效果 multi-use 類別。它們建立新的伺服器處理程序和每次啟動新的視窗工作站，而且當我們討論以下，這可能導致 Windows NT] 下的資源問題。

使用單一類別是使用指定 REGCLS_SINGLEUSE 旗標 (透過 CoRegisterClassObject() API) COM 註冊。這種類別的 COM 會永遠啟動新的例項類別的伺服器處理程序為每個啟動要求的來自任何用戶端 (本機或遠端)。為了本文的其餘的問題是： 伺服器何時會得到新視窗工作站也？
  1. 互動使用者 」 的安全性識別。 要花的案例在其中使用單一類別透過其 AppID 集互動使用者 」 識別下啟動。這種狀況的伺服器處理序的每個新執行個體將會永遠共用互動式視窗] 工作站如果有的話) (如果沒有使用者登入本機然後所有啟動要求將會都失敗)。沒有新的視窗工作站將會建立由 COM。
  2. 「 此使用者 」 的安全性識別。 現在考慮大小寫其中一個使用 COM 類別的 AppID 設定為本使用者 」 身分識別下執行。在這種情況下規則是非常簡單。每個新的用戶端啟用啟動新的處理序，在新的視窗站。是不論是否指定為本使用者 「 使用者登入互動式視窗站一次的啟動要求的任何如此。
  3. "啟動使用者 」 的安全性識別。 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 服務處理序的多個執行個體。
回此頁最上方

分析藍本進行摘要的資料表

--------------------------------------------------------------------------- 
       |                      Multiple-Use Server
       |             (class factory has requested reuse)
       |                       Activation Modes
       |-------------------------------------------------------------------
       |   Interactive     | As "This       |As "Launching    | Win32
Client |      User         |   User"        |   user"         | service
				
Local  | Process launched  | Process        | Process         | Service
       | in the            | launched in a  | launched client | started on
       | interactive window| new window     | window station  | first
       | station on first  | station on     | on first        | activation
       | activation        | first          | request,        | request
       | request,          | activation     | subsequent      | (new winsta
       | subsequent        | request,       | requests from   | or system/ 
       | requests get      | subsequent     | the same SID/   | interactive
       | existing class    | requests get   | window station  | winsta
       | object,           | existing class | get existing    | depending
       | activations fail  | object         | class object, no| on service
       | if no user logged |                | sharing of class| config),
       | on locally        |                | objects across  | subsequent
       |                   |                | window stations | requests
       |                   |                | even if same SID| get
-------|                   |                |-----------------| existing
Remote |                   |                | Process launched| class
       |                   |                | in new winsta on| objects
       |                   |                | first activation|
       |                   |                | request by a    |
       |                   |                | SID, subsequent |
       |                   |                | remote requests |
       |                   |                | by the same SID |
       |                   |                | get existing    |
       |                   |                | class object;   |
       |                   |                | class launched  |
       |                   |                | by local user   |
       |                   |                | reused by remote|
       |                   |                | callers with    |
       |                   |                | same SID        |
---------------------------------------------------------------------------

--------------------------------------------------------------------------- 
       |                      Single-Use Server
       |          (new process created for each activation request)
       |                       Activation Modes
       |-------------------------------------------------------------------
       |   Interactive     | As "This       |As "Launching    | Win32
Client |      User         |   User"        |   user"         | service
				
Local  | Process always    | Process always | Process always  | N/A(only
       | launched in the   | launched in a  | launched in     | one
       | interactive       | new window     | the window      | activation
       | window station,   | station        | station of      | possible)
       | if no interactive |                | client process  |
       | window station    |                |                 |
       | activation fails  |                |                 |
-------|                   |                |-----------------|
Remote |                   |                | if both SID and |
       |                   |                | LUID of the     |
       |                   |                | client match    |
       |                   |                | previous client |
       |                   |                | activation,     |
       |                   |                | process launched|
       |                   |                | in existing     |
       |                   |                | window station, |
       |                   |                | otherwise in new|
       |                   |                | windowstation   |
---------------------------------------------------------------------------
回此頁最上方

視窗工作站與 Windows NT 資源

本章節中我們將檢視建立新的視窗電台，在 [Windows NT 和如何，應該會影響 COM 伺服器的設定的含意。您會發現沒有可以建立在 Windows NT 的電腦的視窗工作站的數目限制。當超過限制時 Windows NT 將會失敗嘗試由 COM 啟動伺服器處理序的新執行個體。通常，會出現一則錯誤訊息如下所示：
動態連結程式庫的初始化
d:\winnt\system32\kernel32.dll 失敗。處理程序
異常終止。
在 Windows NT 下每個視窗工作站會有至少一個與其相關聯的桌面。Windows NT 使用特殊的記憶體堆積來執行在桌面上的所有視窗應用程式。預設情況下，每個桌面堆積會消耗 3 MB 的記憶體。 Windows NT 會具有非可設定 48 MB 的限制，用於建立桌面堆積。 這表示可以在 Windows NT 的電腦建立的視窗工作站的最大數目是 16 (可能是較少因為視窗工作站可以包含一個以上的桌面)。若要增加這個數字，您可以藉由編輯登錄使用登錄編輯程式減少預設桌面堆集大小。

警告： 不當使用 「 登錄編輯器 」 可能會導致嚴重的全系統的問題，可能必須重新安裝 Windows NT 以更正。 Microsoft 無法保證任何因使用登錄編輯程式所造成的問題可以獲得解決。使用此工具，請自行負擔相關的風險。

您需要編輯的具名的值將會顯示下列機碼下： 
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
您需要編輯已命名值在 [Windows]。它是 REG_SZ 字串。編輯字串，並尋找 ＜ 共用區段 = 1024 3072 」。修改此選項可讀取 」 共用區段 = 1024，3072 512 」。您必須重新啟動機器，這個變更才會生效。藉此變更您要指定互動式的視窗工作站桌面 3 MB (預設) 堆積的大小和 512 KB 的所有非-互動式桌面 (第一個參數已過時，但不是應該變更)。這項變更將會允許建立的大約少於 48 MB/512 KB 或 96 視窗電台。

注意: A 視窗工作站可以包含內的多個桌面。在上述，地方提到視窗工作站本機用戶端程序的啟動使用者 」 伺服器的討論，它應該被視為為較短的表單 」 視窗工作站與桌面 」。"啟動使用者 」 設定真正適用於舊版非-DCOM 注意伺服器，應該很少使用。 這種傳統伺服器預期在他們自己的桌上型電腦中執行。因此，針對 MULTIPLEUSE 啟動使用者 」 伺服器，不同的桌面內相同的視窗工作站中的每個用戶端處理程序會造成新的伺服器處理序，以啟動該視窗站/桌面中的處理序。SINGLEUSE 啟動使用者 」 的伺服器，再次，伺服器繼承視窗站/的桌面用戶端處理序。

在 Windows NT 4.0 服務套件 4.0 COM 會嘗試重複使用視窗電台。之前要這，如果伺服器設定為 RunAs，特定的使用者，而且會啟動伺服器處理序的多個執行個體，每個處理程序會取得自己的視窗工作站。這會導致限制描述上面的視窗工作站。在 SP4，COM 會嘗試建立設定為下，相同的使用者識別身份 (或語彙基元) 執行相同的視窗工作站中的所有 RunAs (也就是不"啟動為啟動項 」 或 「 啟動的使用者 」) 伺服器。

這不需要調整桌面堆集大小在這些情況下，多個伺服器處理程序執行有相同的語彙基元的位置。然後如果您的設定中的所有伺服器都設定為 RunAs，同一個使用者或多個同一個執行的 RunAs 伺服器處理序的執行個體，您應該不減少服務台頂端 heapsize 依建議 」 文件中。建議您保持它在預設值 (3 M) 在這種情況下。這是因為，如果您降低桌面堆積，然後系統可以建立多個視窗電台/桌上型電腦 ； 不過，可以在視窗工作站/桌面中執行的處理序數目會變得漸進的較小。

另一方面，在您的組態中如果您有多個伺服器執行不同的語彙基元然後您將面對視窗工作站限制。在這種情況下您應該遵循建議降低桌面堆集大小的文件中。
回此頁最上方

?考

如需有關桌面堆集問題的詳細資訊，請參閱 「 Microsoft 知識庫 」 中下列文：

142676? (http://support.microsoft.com/kb/142676/EN-US/ ) 如何修正常見 User32.dll 檔案錯誤
回此頁最上方
這篇文章中的資訊適用於:
  • Microsoft OLE 4.0?應用於:
    • Microsoft Platform Software Development Kit-January 2000 Edition
回此頁最上方
關鍵字：?
kbmt kbapi kbdcom kbenv kbinfo kbinterop kbkernbase kbprogramming kbusage KB169321 KbMtzh
回此頁最上方
機器翻譯機器翻譯
重要：本文是以 Microsoft 機器翻譯軟體翻譯而成，而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章，讓使用者可以依其使用語言使用知識庫中的所有文章。但是，機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤，就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本：169321? (http://support.microsoft.com/kb/169321/en-us/ )
回此頁最上方
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應，不負任何擔保責任。Microsoft及(或)其供應商謹此聲明，不負任何對與此資訊有關之擔保責任，包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。