INFO: COM-Server-Aktivierung und NT-Windows-Stationen

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 169321 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Wenn ein Client ein Klassenobjekt für eine registrierte Klasse anfordert, COM-entweder ein vorhandene Klasse Objekt zurückgegeben oder startet einen Prozess, der als mit dem Objekt angeforderte Klasse registriert ist. Der Prozess erhalten Sie einen Objektverweis Klasse für einen anfordernden Client (unabhängig davon, ob die in Prozesserstellung oder "starten" resultiert) wird "Aktivierung." bezeichnet.

Unter bestimmten Bedingungen kann COM einen neuen Serverprozess starten, selbst wenn ein vorhandenen Objekt der Klasse ausgeführt wird und wie mehrere registriert wurde. Darüber hinaus Wenn COM einen neuen Prozess erstellt möglicherweise diesen Prozess in einer neuen Sicherheitsumgebung bekannt als "Arbeitsstation" gestartet werden statt eine vorhandenen Arbeitsstation z. B. der interaktiven Windowstation freigeben. (Weitere Informationen zum Fenster Stationen Suchen der Win32 SDK-Dokumentation für diesen Ausdruck.)

Grundlegendes zu COM Algorithmen zum Erstellen von neuen Prozesse und Fenster Stationen während eine Aktivierungsanforderung ist aus verschiedenen Gründen wichtig. Zuerst erstellen COM kann mehrere Prozess Instanz eines Klassenobjekts mehrfach verwendbare aufgrund von Sicherheitsproblemen. Zweitens "Single-Verwendung"-Servern werden immer in separaten Prozessen gestartet werden, aber Sie können oder in separaten Fenster Arbeitsstationen gestartet werden. Dieser Unterschied kann selbst Code der Anwendung in bestimmten Fällen ungewöhnlichen z. B. Wenn zwei COM-Server versuchen, über Fenstermeldungen oder sichere Kommunikation Einrichtungen wie COM- oder RPC-Kommunikation, manifest. Da die Anzahl der Arbeitsstationen, die in Windows NT gleichzeitig erstellt werden können, begrenzt ist, ist es dritten, wissen, wann Ihre com-Server eine neue Windowstation ruft wichtig.

In diesem Artikel untersucht verschiedene Aktivierungs-Szenarien und erläutert die Erstellung von neuen Prozesse und Arbeitsstationen.

Weitere Informationen

Wenn COM-erstellt einen neuen Serverprozess oder einen neuen Serverprozess eine neuen Windowstation zugewiesen hängt von mehreren Faktoren ab:
  1. Die Sicherheitsidentität, unter der die COM-Klasse auf Starten festgelegt ist. Die Identität einer Klasse kann über das Tool DCOMCNFG festgelegt werden und wird von der benannte Wert unter dem Schlüssel "AppID" für die Klasse "runas" angegeben.
  2. Einfache Vs Registrierung mit mehreren-Verwendung durch Klassenobjekte.
  3. Die Sicherheit Identifier(SID) des Clientprozesses (Dies ist der numerische Wert, der einen bestimmten Benutzer Konto/Identität/Sicherheitsprinzipal in einer Windows NT-Umgebung darstellt).
  4. Die Anmeldung Identifier (LUID) der Client-Prozess (ein neue Anmeldung Bezeichner wird für jede eindeutige Anmeldung an einem Computer unter Windows NT generiert. Diese Anmeldung konnte entweder über ein Benutzer einen Benutzernamen und Kennwort an der Anmeldeaufforderung NT eingeben oder durch einen Aufruf der win32 API LogonUser sein.)
  5. Lokale Vs Remoteaktivierung.
  6. Die Arbeitsstation des Clients.

Mehrfach verwendbare Klassen

Eine mehrfach verwendbare Klasse ist eine Klasse, die mit COM (über CoRegisterClassObject()-API), die Angabe der REGCLS_MULTIPLEUSE-Flag registriert ist. Für eine solche Klasse verwendet COM normalerweise dieselbe Instanz der der Serverprozess für alle Clientanforderungen Aktivierung. Allerdings startet COM für Klassen, die zum Ausführen unter die Sicherheit der startende Benutzer und in einigen Fällen konfiguriert, eine neue Instanz des Serverprozesses auf Dienstanforderungen von Aktivierung. Wenn daher eine neue Instanz der der Serverprozess gestartet wird, ist es möglich, dass der Serverprozess sowie eine neuen Arbeitsstation erhält. Betrachten wir die verschiedenen Szenarien unten, aber zunächst wird erörtert kurz warum startet COM neue Prozesse, die angeforderte Klassenobjekte enthalten, wenn eine Instanz des Klassenobjekts bereits als Klasse "Multiple-Verwendung" registriert ist.

Erstens, wenn eine COM-Klasse (genauer, wenn eine AppID eine COM-Klasse zugeordnet) registriert ist mit dem System als "starten Benutzer" ausgeführt werden, hat der Systemadministrator eine bestimmte Sicherheitsrichtlinie in Bezug auf die Klasse einrichten. Die Richtlinie ist, dass eine Aktivierung ein Klassenobjekt innerhalb eines Prozesses erhalten soll, die in dem gleichen Sicherheitskontext wie der Aktivierung Code ausgeführt wird.

Diese Sicherheitsrichtlinie kann Konflikte verursachen, mit dem Verhalten Server definiert, dass nur ein Klasse Factory-Objekt für alle Aktivierungsanforderungen (wie durch REGCLS_MULTIPLEUSE angezeigt) stammen. COM priorisiert die Sicherheitsrichtlinie über Verhalten der Anwendung. Als Ergebnis verhält sich mehrfach verwendbare Server registriert, die als "starten Benutzer" Ausführen nicht der normalen Standardregeln für die Verwendung mehrerer. Ein neuer Prozess wird für jedes Sicherheitsprinzipal Aktivierung gestartet werden.

Wenn ein Prozess nicht gestartet von COM in einem anderen als dem für die angegebene CLSID angegeben Sicherheitskontext ausgeführt, dass CLSID registriert, wird die Registrierung Zweitens Fail(CoRegisterClassObject will return an error code CO_E_WRONG_SERVER_IDENTITY in this case). Und wenn eine Aktivierungsanforderung später eingeht ein neuer Prozess gestartet von COM mit den Sicherheitskontext für die CLSID/AppID angegeben. COM kann nicht Aufruf CoRegisterClassObject() (eine unsichere Operation) Code vertrauen, können nur vertrauen die Registrierungseinstellung (die Registrierung ist eine sichere Datenbank) bestimmen, welches Objekt-Klasse verwenden und zum Ausführen. Dieses Verhalten verhindert, dass illegale computerweiten spoofing von Klassenobjekten durch nicht autorisierte Benutzer.

Mit dem Denken Sie daran wieder wir jetzt das Problem, wenn neue Prozesse und Arbeitsstationen erstellt werden, wenn mehrfach verwendbare Servern von COM gestartet werden Beachten Sie, dass die LUID des Clients nicht in irgendeiner Weise bei mehrfach verwendbare Klasse spielt.
  1. Sicherheits-ID "Interaktiver Benutzer". In der Fall, in denen eine mehrfach verwendbare COM-Klasse AppID für die Ausführung als Identität "Interaktiver Benutzer" konfiguriert ist, werden der erste Serverprozess und dessen Objekt der Klasse von COM verwendet werden, alle nachfolgenden Aktivierungsanforderungen zu verarbeiten. Dieser Serverinstanz haben der interaktiven Windowstation, falls vorhanden (Wenn kein Benutzer lokal angemeldet ist und alle Aktivierungsanforderungen fehlschlagen). Wie bereits erwähnt, wenn ein Prozess nicht von COM gestartet und die CLSID nicht in der interaktiven Windowstation ausgeführt registriert, schlägt die Registrierung fehl. Und wenn eine Aktivierungsanforderung später eintrifft, wird ein neuer Prozess mit dem Sicherheitskontext des interaktiven Benutzers gestartet werden. Dieses Verhalten verhindert, dass illegale spoofing von Klassenobjekten. Da keine zusätzlichen Serverprozesse jemals von COM gestartet werden, ist die Frage, neue Fenster Stationen moot. Die SID des Clients, seine LUID oder ob es lokal oder remote in diesem Fall spielt keine Rolle.
  2. "Dieser Benutzer" Sicherheits-ID. Entsprechend ist eine mehrfach verwendbare COM-Klasse AppID konfiguriert wird als "dieser Benutzer" ausgeführt (einer vordefinierten Sicherheits-ID) der erste Server verarbeiten und dessen Objekt der Klasse werden von COM verwendet, Anforderungen für alle nachfolgenden Aktivierung. Diese ersten Serverinstanz haben eigene Windowstation als Teil der ersten Prozesserstellung erstellt. Da keine zusätzlichen Serverprozesse jemals von COM gestartet werden, ist die Frage, zusätzliche Fenster Stationen moot. Die SID des Clients, seine LUID oder ob es lokal oder remote in diesem Fall spielt keine Rolle. Beachten Sie, dass eine neuen Arbeitsstation erstellt werden wird, beim Starten von der ersten Instanz einer Klasse/AppID darauf konfiguriert, als "Dieser Benutzer," ausgeführt, selbst wenn derselbe Benutzer in interaktive Winstation derzeit angemeldet ist. COM verwendet niemals interaktive Winstation zum Starten eines Server, als "Dieser Benutzer" ausgeführt werden, da, anderes Verhalten für die Klasse das nicht verbundene Problem der Identität des aktuell angemeldeten Benutzers je ergeben. Wie oben erwähnt, wenn ein Prozess nicht von COM gestartet und zu registrieren versucht nicht in das in "Dieser Benutzer" angegebene Konto ausgeführt werden die CLSID, die Registrierung fehl und wenn eine Aktivierungsanforderung später einen neuen Prozess Eintreffen im Konto "Dieser Benutzer" gestartet. Dieses Verhalten verhindert, dass illegale spoofing von Klassenobjekten. Andererseits, wenn der Vorgang registriert für eine bestimmte CLSID/APPID für die Ausführung als "Dieser Benutzer" konfiguriert ist, wird im erstellt des entsprechende Benutzerkontos durch einige Agent außer COM (beispielsweise, es ist Ausführen vom interaktiven Benutzer Wenn der interaktive Benutzer demselben Benutzer wie "Dieser Benutzer" oder es wird über CreateProcess() gestartet, von einem Dienst in der gleichen Sicherheitskontext wie "dieser Benutzer" ausgeführt), und registriert anschließend die REGCLS_MULTIPLEUSE-Klassenobjekte, COM wird das vorhandene ausgeführten Klassenobjekt verwenden, um nachfolgende eingehende Aktivierungsanforderungen von einem beliebigen Client erfüllen.
  3. "Benutzer starten" Sicherheits-ID In diesem Fall ist die Klasse "AppID" unter "Launching User" Idenitity gestartet (Dies ist auch bekannt als eine Klasse "Als Activator aktivieren") festgelegt. a. lokalen Client. Betrachten Sie zunächst den lokalen Fall. Es gibt zwei Regeln: 1. jeder Client verschiedene Aktivierungs-SID bewirkt, dass COM, eine neue Instanz des Serverprozesses selbst in der gleichen Arbeitsstation starten. 2. Auch nach übereinstimmenden SIDs (z. B. der Fall, in denen derselbe Benutzer mehr als einmal einen einzelnen NT-Computer angemeldet ist), bewirkt jeder anderen lokalen Client-Arbeitsstation COM, starten Sie eine neue Instanz des Serverprozesses. Starten Benutzer Identität mehrfach verwendbare Server sind mit anderen Worten, nie über Arbeitsstationen freigegeben. Alle Clientprozesse mit dem dieselbe SID und demselben Fenster Stationen werden einen einzelner Serverprozess in der gleichen Windowstation freigeben. Da der Server der Arbeitsstation des Clients Freigaben werden keine neuen Arbeitsstationen erstellt. Genommen Sie an, Sie interaktiv als A_domain\a_user angemeldet sind. Sie führen mehrere Instanzen des Clients eine Verbindung alle zur dieselbe Instanz des Servers herstellen wird (die der interaktiven Windowstation hat). Nachdem wir sagen einen Client ein Dienst ist, das Starten unter A_domain\a_user gestartet Ihnen. Dieser Dienst startet eine neue Instanz des COM-Servers. Dies geschieht, weil COM führt eine neue Instanz des Servers, da der Dienstprozess eine Windowstation außer der interaktiven Windowstation--von, obwohl die Identität des Prozesses service(client) der gleiche wie die Identität des ausgeführten Serverprozesses (A_domain\a_user ist) gestartet werden. Beachten Sie jedoch, dass keine neuen Arbeitsstation für die COM-Serverprozess erstellt wird. Der Server wird weiterhin der Arbeitsstation des Dienstes erben. Wenn der Dienst unter Lokales System starten und mit dem Desktop interagieren festgelegt ist (finden Sie in der Dienst das Kontrollkästchen "Zulassen Service zur Interaktion mit Desktop" Applet in der Systemsteuerung), und führen Sie der Dienst in der interaktiven Windowstation oder winsta0 wird. In diesem Fall COM wird weiterhin eine neue Instanz starten des Servers (des Client-SID die LocalSystem ist in diesem Fall unterscheidet der SID des Servers, A_domain\a_user) in der interaktiven Windowstation. b. RAS-Client. Bei der Remoteaktivierung ignoriert COM der Arbeitsstation des Clients, da der Client remote, im Gegensatz zu der lokalen oben genannten Fall ist. Die Regel hier darin, dass jeder neuer Client SID bewirkt, dass eine neue Instanz der der Serverprozess gestartet werden und jeder neue Serverprozess einer neuen Arbeitsstation erhalten. Nachfolgende Aktivierung Anforderungen, die Remoteclients mit derselben, die SID wiederverwenden wird, das vorhandene Class-Objekt sowie dessen Station Prozess- und Fenster registriert. Genommen Sie an, dass Sie als A_domain\a_user auf 10 verschiedenen Computern angemeldet sind. Die Clients von diesen Computern werden keine Verbindung auf dieselbe Instanz des Servers auf dem Server herstellen. Ein Client von einem Computer A_domain\b_user wird eine neue Serverinstanz und einer neuen Arbeitsstation gestartet. Remoteaufrufer mit der gleichen SID als lokaler Benutzer, der für die angeforderte CLSID registrierten COM-Server gestartet wurde, werden das vorhandene Klassenobjekt wiederverwendet. Allerdings ist die Reihenfolge in der com-Server gestartet ist wichtig in diesem Fall. Wenn der Server zuerst vom lokalen Client gestartet wird, wird der Remoteclient mit der gleichen SID mit diesem Server verbinden. Andererseits, wenn der Server zuerst vom Remoteclient gestartet wird, wird dann ein lokaler Client mit der gleichen SID eine neue Instanz des Servers gestartet. Dadurch wechselt wieder den oben genannten Fenster Station-Regeln. Für lokale Clients muss der Arbeitsstation des Clients und dem Server, für Remoteclients entsprechen der Arbeitsstation des Clients ignoriert wird. Z. B. wenn lokalen Client A_domain\a_user zunächst den Server startet, wird dann Remoteclient A_domain\a_user auf dem Server verbinden. Umgekehrt, wenn Remoteclient A_domain\a_user den Server zuerst gestartet wird, wird dann lokalen Client A_domain\a_user eine neue Serverinstanz und einer neuen Arbeitsstation gestartet. Die LUID des Clients spielt in diesem Fall keine Rolle.
  4. Service-basierte COM-Server. Eine COM-Klasse/AppID, die in einem Win32-Dienst gepackt ist durch praktische Notwendigkeit eine mehrfach verwendbare Server, da Dienste nur einmal gestartet werden können. In diesem Fall wird ein neuer Prozess bei der ersten Aktivierungsanforderung in eigene Arbeitsstation gestartet. Es gibt zwei Ausnahmen zu dieser: A. wenn der Dienst unter dem lokalen Systemkonto gestartet festgelegt ist, es eine vordefinierten Windowstation System erben. b. wenn der Dienst unter dem lokalen Systemkonto gestartet festgelegt ist und mit dem Desktop interagieren kann, wird es der interaktiven Windowstation oder winsta0 erben. Alle nachfolgenden Aktivierungsanforderungen werden, ob lokale oder remote, von der Dienst-Klassenobjekt behandelt. Wie oben erwähnt, wenn ein Prozess nicht gestartet, indem werden COM und nicht ausgeführt, wie der angegebene Dienst die CLSID registriert, die Registrierung fehl und wenn eine Aktivierungsanforderung später registrierten Dienst eintreffen gestartet. Dieses Verhalten verhindert, dass illegale spoofing von Klassenobjekten.

Einzelne verwenden Klassen

Hinweis: Verwenden einer Klassen sollte möglichst vermieden werden. Einfache Registrierung ist eine legacy-Einstellung und soll zur Unterstützung von älterer COM-Anwendungen und erleichtern die Portierung von legacy-COM-Anwendungen COM Es wird dringend empfohlen, dass neue Klassen für die Unterstützung mehrfach verwendbare Klasse Objektregistrierung ausgelegt werden. Dies gilt insbesondere im Fall von Servern mit der Identität "Dieser Benutzer", wobei führen einfache Klassen genau entgegengesetzten Auswirkungen Mehrzweck-Klassen. Sie erstellen Sie einen neuen Server Prozess und neue Windowstation pro Aktivierung, und wie wir weiter unten erläutert, kann diese Ressource Probleme unter Windows NT verursachen.

Eine einfache Klasse ist eine COM (über die CoRegisterClassObject()-API), die Angabe der REGCLS_SINGLEUSE-Flag registriert ist. Eine solche Klasse wird COM immer eine neue Instanz der Klasse Server-Prozess für jede Aktivierungsanforderung von einem beliebigen Client (lokal oder remote) beginnen. Für Zwecke dieses Artikels, die verbleibende Frage ist: Wenn der Server erhalten sowie eine neuen Windowstation?
  1. Sicherheits-ID "Interaktiver Benutzer". Nutzen Sie den Fall, in dem die einfache Klasse über seine AppID festgelegt wird, unter der Identität "Interaktiver Benutzer" zu starten. Für diesen Fall wird jede neue Instanz des Serverprozesses der interaktiven Windowstation immer freigeben, wenn eine vorhanden ist (Wenn kein Benutzer lokal angemeldet ist und alle Aktivierungsanforderungen fehlschlagen). Keine neuen Windowstation wird von COM erstellt werden
  2. "Dieser Benutzer" Sicherheits-ID. Betrachten Sie nun den Fall, bei denen die einfache COM-Klasse AppId festgelegt ist, unter der Identität "Dieser Benutzer" ausgeführt. In diesem Fall ist die Regel sehr einfach. Jede neue Clientaktivierung startet einen neuen Prozess in einer neuen Arbeitsstation. Dies gilt unabhängig davon, ob der Benutzer als "Dieser Benutzer" angegeben, der interaktiven Windowstation zum Zeitpunkt der keines der Aktivierungsanforderungen angemeldet ist zur Verfügung.
  3. "Benutzer starten" Sicherheits-ID a. lokalen Client. Im Szenario Aktivierung lokalen erhalten der Serverprozess immer der Arbeitsstation des Clients. Keine neuen Arbeitsstationen werden jemals erstellt. Genommen Sie an, Sie interaktiv als A_domain\a_user und Ausführen mehrerer Instanzen des Client-Programms angemeldet sind. Jede neue erstellte Instanz des Servers, der interaktiven Windowstation erhalten. Davon jetzt aus, dass der Client ein Dienst, der unter dem lokalen Systemkonto ausgeführt wird. Der com-Server wird in diesem Fall der Arbeitsstation des Dienstprozesses freigeben. b. RAS-Client. Im Fall Remoteaktivierung ignoriert COM der Arbeitsstation des Clients, da der Client remote ist. Für die einzelnen Remoteaktivierung werden wie immer eine neue Instanz Serverprozess gestartet. Die Regeln sind: 1. für jeden neuen remote Client SID werden eine neuen Arbeitsstation für den Serverprozess erstellt. 2. Für jede neue Remoteclient LUID wird eine neue Arbeitsstation für den Serverprozess erstellt. 3. Alle Remoteclients mit dem gleichen SID-LUID-Paar werden Servern erstellen, die dieselbe Arbeitsstation verwenden wird. Beispielsweise werden Sie als A_domain\a_user auf dem remote-Client-Computer protokolliert. Dieser Client startet den remote Server, der eine neuen Windowstation erhalten. Nun, A_domain\a_user eine zweite Instanz von der Clientanwendung von der gleichen Client-Computer gestartet wird, die wiederum eine neue Kopie des Servers auf dem Remotecomputer startet, wird dieser Server dem ursprünglichen Server Windowstation freigeben. Jetzt nehmen Sie sich anmelden, einem anderen Computer wieder als A_domain\a_user an und von dort aus den Client ausgeführt. Die entsprechende Serverinstanz haben eine neue Arbeitsstation. Dies veranschaulicht, dass selbst wenn der Client SIDs identisch, da der zweite Client eine unterschiedliche LUID, seine Serverprozess eine neuen Windowstation erhalten.
  4. Service-basierte COM-Server. Einfache Klassen sollten niemals als Windows NT-Dienste implementiert werden. Es ist nicht sinnvoll, da es nicht möglich, mehrere Instanzen eines Windows NT-Dienst-Prozesses auszuführen.

Tabelle Summarizing Szenarios

---------------------------------------------------------------------------
       |                      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   |
				
---------------------------------------------------------------------------

Fenster Sender und Windows NT-Ressourcen

In diesem Abschnitt untersuchen wir, die Auswirkungen von Erstellen von neuen Arbeitsstationen unter Windows NT und wie, die Konfiguration des COM-Servers auswirken sollte. Wie Sie sehen werden, ist beschränkt die Anzahl der Arbeitsstationen, die auf einem Windows NT-Computer erstellt werden können. Wenn dieses Limit überschritten wird, schlägt Windows NT Versuch von COM, starten Sie eine neue Instanz des Serverprozesses fehl. In der Regel wird ein Fehlermeldung wie folgt:
Initialisierung der dynamic Link-Bibliothek
d:\winnt\system32\kernel32.dll ist fehlgeschlagen. Der Prozess ist
nicht normal beendet.
Unter Windows NT hat jede Arbeitsstation mindestens Desktop zugeordnet. Windows NT verwendet einen speziellen Speicherheap für alle auf einem Desktop ausgeführten Windows-Anwendungen. Standardmäßig verbraucht jede Desktopheap 3 MB Arbeitsspeicher. Windows NT hat eine nicht konfigurierbare Beschränkung von 48 MB für desktop Heaps erstellen. Dies bedeutet, dass die maximale Anzahl von Arbeitsstationen, die auf einem Windows NT-Computer erstellt werden können 16 ist (wahrscheinlich weniger da eine Windowstation, mehr als einem Desktop enthalten kann). Um diese Anzahl zu erhöhen, können Sie die standardmäßigen desktop-Heapgröße verringern, durch Bearbeiten der Registrierung mit dem Registrierungs-Editor.

Achtung: Durch das unkorrekte Verwendung des Registrierungseditors kann schwerwiegende, systemweite Probleme verursachen, die möglicherweise installieren Sie Windows NT zur Fehlerkorrektur erforderlich machen. Microsoft kann nicht garantieren, dass alle Probleme, die aus der Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie das Programm auf eigene Verantwortung.

Der benannte Wert Sie bearbeiten müssen wird angezeigt, unter dem folgenden Schlüssel:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
				
müssen Sie mit der Bezeichnung Value "Windows" zu bearbeiten. Es ist ein REG_SZ-Zeichenfolge. Bearbeiten Sie die Zeichenfolge und suchen Sie nach "Shared Abschnitt = 1024, 3072". Ändern Sie dazu zu lesen "Shared-Bereich 1024 = 3072, 512". Sie müssen den Computer für diese Änderung wirksam wird neu starten. Durch diese Änderung werden Sie angeben, 3 MB (Standard)-Heapgröße für der interaktiven Windowstation Desktop und 512 KB für alle nicht - interaktive Desktops (der erste Parameter ist veraltet, jedoch nicht geändert werden sollten). Diese Änderung ermöglicht die Erstellung von ca. weniger als 48 MB/512 KB oder 96 Arbeitsstationen.

Hinweis: Eine Windowstation kann mehreren Desktops darin enthalten. In der Diskussion von "Launching User" Servern oben an der Stelle, an der Arbeitsstation den lokalen Client-Prozess genannt wird sollte es als ein kürzeres Formular für "Arbeitsstation und Desktop" betrachtet werden. Einstellung "Benutzer starten" ist wirklich zum beachten herkömmliche nicht-DCOM-Server vorgesehen und sollte nur selten verwendet werden. Solche Legacyserver erwarten, in Ihren eigenen Desktops ausgeführt. Folglich für MULTIPLEUSE "Launching User" Server, jeder Clientprozess auf einem anderen Desktop innerhalb der gleichen Windowstation bewirkt, dass einen neuer Serverprozess in die Fenster Station/Desktop gestartet werden. Für SINGLEUSE "Launching User"-Servern erneut, den Server den Windows Station/Desktop Client-Prozess erbt.

In Windows NT 4.0 Service Pack 4.0 versucht COM Arbeitsstationen wiederverwenden. Vor dazu erhalten Wenn ein Server auf "runas" ein bestimmtes Benutzers festgelegt ist und mehrere Instanzen der Serverprozess gestartet werden, jeder Prozess seinen eigenen Windowstation. Dies führt zu der Windowstation Einschränkungen oben beschreiben. In SP4 versucht COM, alle RunAs (d. h., nicht "Als Activator aktivieren" oder "Launching User")-Server erstellen, die unter den gleichen Benutzer Identität (oder Token) in der gleichen Arbeitsstation ausgeführt.

Dadurch erübrigt sich die Anpassen der Größe Desktopheap in diesen Fällen, in denen Prozesse für mehrere Server mit dem gleichen Token ausgeführt. Wenn in Ihrer Konfiguration alle Server auf "runas" denselben Benutzer oder mehrere Instanzen der gleichen RunAs-Serverprozess ausgeführt eingerichtet sind, sollten Sie den Desktop Heapsize wie im Artikel vorgeschlagen nicht reduzieren. Es wird empfohlen, dass Sie es den Standardwert (3 M) in diesem Fall lassen. Dies liegt daran, wenn Sie den Desktopheap verringern, dann das System kann erstellen Weitere Fenster Stationen bzw. Desktops; die Anzahl der Prozesse, die in einem Fenster Station/Desktop ausgeführt werden können werden jedoch zunehmend kleiner.

Andererseits, in Ihrer Konfiguration werden Wenn Sie mehrere Server mit verschiedenen Token ausgeführt haben dann die Fenster Station Einschränkungen bestehen. In diesem Fall sollten Sie die Vorschläge im Artikel zum Reduzieren der desktop-Heapgröße folgen.

Informationsquellen

Weitere Informationen zu den Desktopheap Problem finden Sie in der folgenden Artikel der Microsoft Knowledge Base:

142676Wie Sie häufige User32.dll Dateifehler korrigieren

Eigenschaften

Artikel-ID: 169321 - Geändert am: Montag, 11. Juli 2005 - Version: 2.5
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft OLE 4.0, wenn verwendet mit:
    • Microsoft Platform Software Development Kit January 2000 Edition
Keywords: 
kbmt kbapi kbdcom kbenv kbinfo kbinterop kbkernbase kbprogramming kbusage KB169321 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 169321
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

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