Information : Activation des serveurs COM et stations de Windows NT

Traductions disponibles Traductions disponibles
Numéro d'article: 169321 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Lorsqu'un client demande un objet de classe pour une classe inscrite, COM renvoie un objet de classe existant ou lance un processus est enregistré comme contenant l'objet de classe demandée. Le processus d'obtenir une référence d'objet de classe pour un client demandeur (ou non qui a pour résultat la création du processus ou "lancement") est appelé «activation».

Dans certaines conditions, COM vous pouvez lancer un nouveau processus de serveur même lorsqu'un objet de classe existant est en cours d'exécution et a été enregistré comme usage multiple. En outre, lorsque COM crée un nouveau processus de ce processus peut être lancé dans un nouvel environnement de sécurité appelé «station de fenêtre» au lieu de partager une station existante de fenêtre telles que la station Windows interactive. (Pour plus d'informations sur les stations de fenêtre, recherchez la documentation du SDK Win32 pour cette phrase.)

Il est important de comprendre les algorithmes de COM pour créer de nouveaux processus et des stations window pendant une demande d'activation pour plusieurs raisons. Tout d'abord, COM peut-être créer plus d'une instance de processus d'un objet de classe usage multiple raison de problèmes de sécurité. Deuxièmement, «usage unique» serveurs seront toujours lancés dans des processus distincts, mais ils peuvent ou ne peuvent pas être démarrés dans les gares de fenêtre séparée. Cette différence peut se manifester au code de l'application dans certains cas inhabituels, comme lorsque deux serveurs COM essaient de communiquer par le biais de messages de fenêtre ou des installations de communication sécurisée tels que COM ou RPC. Troisièmement, dans la mesure où le nombre de stations de fenêtre qui peuvent être créés simultanément dans Windows NT est limité, il est important de savoir quand votre serveur COM Obtient une nouvelle station de fenêtre.

Cet article examine les scénarios d'activation différente et explique lorsque les nouveaux processus et des stations window sont créées.

Plus d'informations

Lorsque COM crée un processus serveur ou affecte une nouvelle station de fenêtre à un nouveau processus de serveur dépend de plusieurs facteurs :
  1. L'identité de sécurité sous lequel la classe COM est configurée pour démarrer. L'identité d'une classe peut être définie via l'outil DCOMCNFG et est spécifiée par RunAs valeur sous la clé AppID pour la classe nommée.
  2. À usage unique d'inscription par rapport à usages multiples par des objets de classe.
  3. Identifier(SID) de sécurité du processus client (il s'agit de la valeur numérique qui représente une utilisateur particulier compte/identité/entité de sécurité dans un environnement Windows NT).
  4. L'identificateur de connexion (LUID) de la client processus. (un nouvel identificateur d'ouverture de session est généré pour chaque ouverture de session unique sur un ordinateur exécutant Windows NT. Cette ouverture de session pourrait être par l'intermédiaire d'un utilisateur saisissant un nom d'utilisateur et un mot de passe à l'invite d'ouverture de session NT ou par l'intermédiaire d'un appel à l'API win32 LogonUser.)
  5. Local par rapport à l'activation à distance.
  6. La station Windows du client.

Classes à usage multiple

Une classe usage multiple est une classe qui est inscrit avec COM (via API CoRegisterClassObject()) spécifier l'indicateur REGCLS_MULTIPLEUSE. Pour une telle classe COM utilise normalement la même instance du processus du serveur pour toutes les demandes d'activation de client. Toutefois, pour les classes configurées pour s'exécuter sous la sécurité des utilisateurs exécutant et dans certains autres cas, COM lance une nouvelle instance du processus du serveur pour traiter des demandes d'activation. Lorsqu'une nouvelle instance du processus du serveur est lancée par conséquent, il est possible que le processus serveur obtient une nouvelle station fenêtre. Nous allons examiner les différents scénarios ci-dessous, mais tout d'abord nous allons étudier brièvement pourquoi COM lance les nouveaux processus contenant des objets de la classe demandée lorsqu'une instance de l'objet de classe est déjà enregistrée sous la forme d'une classe «usage multiple».

Premier, lorsqu'une classe COM (plus précisément, lorsqu'un AppID associée une classe COM) est enregistré avec le système pour être exécuté comme «l'utilisateur exécutant», l'administrateur système a défini une stratégie de sécurité spécifique par rapport à cette classe. La stratégie est qu'un activateur devrait recevoir un objet de classe à l'intérieur d'un processus qui s'exécute dans le même contexte de sécurité que le code d'activation.

Cette stratégie de sécurité peut entrer en conflit avec le comportement de serveur défini d'avoir qu'un objet de fabrique de classe pour toutes les demandes d'activation (comme indiqué par REGCLS_MULTIPLEUSE). COM en priorité la stratégie de sécurité sur le comportement de l'application. Par conséquent, usages multiples serveurs inscrits pour s'exécuter en tant que "utilisateur exécutant" ne se comportera pas conformément aux règles normales d'utilisation multiple. Un nouveau processus sera lancé pour chaque entité de sécurité activation.

Deuxièmement, si un processus ne pas lancé par COM dans un contexte de sécurité différent de celui spécifié pour le CLSID donné enregistre ce CLSID, cet enregistrement va fail(CoRegisterClassObject will return an error code CO_E_WRONG_SERVER_IDENTITY in this case). Et, si une demande d'activation arrive ultérieurement un nouveau processus sera lancé par COM avec le contexte de sécurité spécifié pour l'AppID/CLSID. COM ne peuvent pas faire confiance code appelant CoRegisterClassObject() (opération non sécurisée), il peut uniquement approuve le paramètre de Registre (le Registre est une base de données sécurisée) pour déterminer quel objet de classe à utiliser et comment l'exécuter. Ce comportement empêche l'usurpation à l'échelle de l'ordinateur illicite des objets de classe par des utilisateurs non autorisés.

Dans cette optique, nous revenir maintenant à la délivrance de lorsque les nouveaux processus et des stations window sont créées lorsque serveurs à utilisation multiple sont lancées par COM. Notez que le LUID du client n'a pas d'importance d'une manière dans le cas de la classe usages multiples.
  1. Identité de sécurité «Utilisateur interactif». Dans le cas où AppID d'une classe COM usage multiple est configuré pour s'exécuter en tant que l'identité "Utilisateur interactif", le tout premier processus du serveur et son objet de classe serviront par COM pour traiter toutes les demandes de l'activation suivante. Cette instance de serveur aura la station Windows interactive, le cas échéant (si aucun utilisateur n'a ouvert une session localement toutes les demandes d'activation échouera). Comme indiqué ci-dessus, si un processus pas lancé par COM et ne s'exécute pas dans la station Windows interactive enregistre le CLSID, cet enregistrement va échouer. Et, si une demande d'activation arrive plus tard, un nouveau processus sera lancé avec le contexte de sécurité de l'utilisateur interactif. Ce comportement empêche l'usurpation d'identité illicite des objets de classe. Dans la mesure où aucun processus de serveur supplémentaire ne sont jamais démarrés par COM, la question de nouvelles stations de fenêtre est hypothétiques. Le SID du client, ses LUID ou s'il s'agit de local ou distant n'a pas d'importance dans ce cas.
  2. Identité de sécurité «Cet utilisateur». De même, si une classe COM usage multiple de l'AppID est configuré pour exécuter en tant que «cet utilisateur» (ID de sécurité prédéfinis), le premier serveur traiter et son objet de classe sera utilisé par COM pour traiter toutes les demandes de l'activation suivante. Cette première instance de serveur aura sa propre station de fenêtre créée dans le cadre de la première création de processus. Dans la mesure où aucun processus de serveur supplémentaire ne sont jamais démarrés par COM, la question des stations de fenêtre supplémentaire est hypothétiques. Le SID du client, ses LUID ou s'il s'agit de local ou distant n'a pas d'importance dans ce cas. Notez qu'une nouvelle station de fenêtre va être créée lors du lancement de la première instance d'une classe/AppID configuré pour s'exécuter en tant que «Cet utilisateur», même si le même utilisateur est actuellement connecté dans la station Windows interactive. COM n'utilise jamais la station Windows interactive pour lancer un serveur configuré pour s'exécuter sous «Cet utilisateur» car qui entraînerait un comportement différent pour la classe en fonction de la délivrance indépendante de l'identité de l'utilisateur actuellement connecté. Comme indiqué ci-dessus, si un processus pas lancé par COM et non s'exécutant dans le compte spécifié dans «Cet utilisateur» tente d'inscrire le CLSID qui l'inscription échoue et si une demande d'activation arrive ultérieurement un nouveau processus seront lancés dans le compte «De cet utilisateur». Ce comportement empêche l'usurpation d'identité illicite des objets de classe. D'autre part, si le processus inscrit pour un CLSID/APPID donné est configuré pour s'exécuter en tant que «Cet utilisateur», est créé le compte d'utilisateur approprié par dans certains agent autres que COM (par exemple, il est exécuté par l'utilisateur interactif lorsque l'utilisateur interactif est le même utilisateur que «Cet utilisateur» ou il est démarré via CreateProcess() par un service s'exécutant dans le même contexte de sécurité en tant que «cet utilisateur») et il inscrit ses objets de classe REGCLS_MULTIPLEUSE, COM utilise l'objet de classe en cours d'exécution existant pour répondre aux requêtes d'activation entrants ultérieures à partir de n'importe quel client.
  3. Identité de sécurité "Lancement utilisateur". Dans ce cas, AppID de la classe prend lancer sous l'idenitity "Utilisateur exécutant" (qui est également appelé une classe "Activer comme Activator"). a. client local. En premier lieu, prenez en compte le cas de l'ordinateur local. Deux règles: 1. chaque client d'activation différente SID entraîne COM lancer une nouvelle instance du processus du serveur, même dans la même station Windows. 2. Même correspondance des identificateurs de sécurité (par exemple, le cas où le même utilisateur est connecté plusieurs fois à une seule machine NT), chaque station de fenêtre client local différent entraînera COM lancer une nouvelle instance du processus du serveur. En d'autres termes, lancement utilisateur identité usages multiples serveurs ne sont jamais partagés sur plusieurs stations window. Tous les processus client avec le même SID et la même fenêtre stations partagent un processus de serveur unique dans la même station Windows. Dans la mesure où le serveur de partage de la station de fenêtre du client aucune nouvelle station de fenêtre n'est créées. Par exemple, supposons que vous sont connectés de manière interactive en tant qu'a_domain\a_user. Vous exécutez plusieurs instances du client, qui se connecte à la même instance du serveur (qui comporte la station Windows interactive). Nous allons dire que vous avez maintenant un client, qui est un service qui est défini sur lancer démarrer sous a_domain\a_user. Ce service lance une nouvelle instance du serveur COM. Cela se produit car COM entraîne une nouvelle instance du serveur à lancer le processus de service ayant une station Windows autre que la station Windows interactive--même si l'identité du processus service(client) est identique à l'identité du processus de serveur en cours d'exécution (a_domain\a_user). Notez toutefois qu'aucune nouvelle station de fenêtre n'est créée pour le processus de serveur COM. Le serveur hérite toujours de la station du service. Si le service est défini pour démarrer sous LocalSystem et interagir avec le bureau (reportez-vous à boîte de à cocher «Autoriser Service à interagir avec Desktop» dans le service applet Panneau de configuration), puis le service s'exécutera dans la station Windows interactive ou winsta0. Dans ce cas COM sera toujours démarrer une nouvelle instance du serveur (les SID du client qui est LocalSystem dans ce cas est différent de celui de l'ID de sécurité du serveur qui est a_domain\a_user) dans la station Windows interactive. b. client à distance. Dans le cas de l'activation à distance, COM ignore la station de fenêtre du client parce que le client est distant, contrairement à la casse locale ci-dessus. La règle ici est que chaque client nouveau SID entraîne une nouvelle instance du processus du serveur à lancer et chaque nouveau processus de serveur obtiendra une nouvelle station de fenêtre. L'activation suivante demande par des clients distants avec le même que SID réutilise que le existant enregistré objet de classe, ainsi que ses processus et de la station Windows. Par exemple, supposons que vous êtes connecté en tant qu'a_domain\a_user sur 10 des machines différentes. Les clients à partir de ces machines se connectera à la même instance du serveur sur le serveur. Un client à partir d'une machine a_domain\b_user lancera une nouvelle instance de serveur et une nouvelle station de fenêtre. Les appelants distants avec le même SID en tant qu'utilisateur local qui a lancé le serveur COM enregistré pour le CLSID demandé réutilise l'objet de classe existant. Toutefois, l'ordre dans lequel le serveur COM est démarré est important dans ce cas. Si le serveur est lancé par le client local, le client distant avec le même SID se connecte à ce serveur. En revanche, si le serveur est lancé par le client distant, un client local avec le même SID démarrera une nouvelle instance du serveur. Cela revient aux règles de station de fenêtre mentionnés ci-dessus. Pour les clients locaux, la station de fenêtre du client et le serveur doit correspondre pour clients distants, que la station de fenêtre du client est ignorée. Par exemple, si a_domain\a_user client local lance tout d'abord le serveur, a_domain\a_user client distant se connecte au serveur. À l'inverse, si a_domain\a_user client distant lance tout d'abord le serveur, client local a_domain\a_user se lance une nouvelle instance de serveur et une nouvelle station de fenêtre. LUID du client n'a pas d'importance dans ce cas.
  4. Serveurs COM basées sur les services. Une classe/AppID de COM est empaqueté dans un service Win32 est par nécessité pratique un serveur usage multiple car services peuvent être lancés qu'une seule fois. Dans ce cas, à la première demande d'activation, un nouveau processus est lancé dans sa propre station Windows. Il existe deux exceptions à cela: a. Si le service est défini à lancer sous le compte LocalSystem, il héritera une station de fenêtre prédéfinis du système. b. Si le service est défini sur lancement sous le compte LocalSystem et peut interagir avec le bureau, il héritera de la station Windows interactive ou winsta0. Toutes les demandes de l'activation suivante, locaux ou distants, sont gérées par objet de classe du service. Comme indiqué ci-dessus, si un processus ne pas lancé par COM et s'exécute ne pas comme le service spécifié inscrit le CLSID, cet enregistrement échoue et si une demande d'activation arrive ultérieurement le service inscrit seront lancés. Ce comportement empêche l'usurpation d'identité illicite des objets de classe.

Classes de l'utilisation unique

Remarque : Single Use classes doivent être évités autant que possible. Inscription à usage unique est un paramètre hérité et est destinée à prendre en charge les anciennes applications COM et à faciliter le portage des applications non-COM existantes à COM. Il est fortement recommandé que nouvelles classes être conçu pour prendre en charge de l'enregistrement de la classe usage multiple d'objet. Ceci est particulièrement vrai dans le cas des serveurs avec une identité «Cet utilisateur», où les classes à usage unique provoquer exactement opposées effet des classes à usages multiples. Ils créent un nouveau serveur, processus et nouvelle station de fenêtre par l'activation et, comme nous abordons ci-dessous, cela peut entraîner des problèmes de ressource sous Windows NT.

Une classe à usage unique est celui qui est inscrit avec COM (via l'API CoRegisterClassObject()) spécifier l'indicateur REGCLS_SINGLEUSE. Pour une classe de ce type, COM commence toujours une nouvelle instance de processus de serveur de la classe pour chaque demande d'activation à partir de n'importe quel client (local ou distant). Aux fins de cet article, la question restante est : lorsque le serveur obtiendra une nouvelle station fenêtre ?
  1. Identité de sécurité «Utilisateur interactif». Prendre le cas dans lequel la classe à usage unique est définie par l'intermédiaire de son AppID pour démarrer sous l'identité «Utilisateur interactif». Dans ce cas, chaque nouvelle instance du processus du serveur partageront toujours la station Windows interactive, le cas échéant (si aucun utilisateur n'a ouvert une session localement toutes les demandes d'activation échouera). Aucune nouvelle station de fenêtre ne sera créée par COM.
  2. Identité de sécurité «Cet utilisateur». Examinons à présent le cas où les ID d'application de la classe COM à usage unique est configuré pour s'exécuter sous l'identité «Cet utilisateur». Dans ce cas, la règle est très simple. Chaque nouvelle activation par client lance un nouveau processus dans une nouvelle station de fenêtre. Cela est vrai quel que soit ou non l'utilisateur spécifié comme «Cet utilisateur» est connecté à la station Windows interactive au moment d'une des demandes d'activation.
  3. Identité de sécurité "Lancement utilisateur". a. client local. Dans le scénario de l'activation de machine locale, le processus serveur obtenez toujours la station de fenêtre du client. Aucune nouvelle station de fenêtre n'est jamais créée. Par exemple, supposons que vous sont connectés de manière interactive qu'a_domain\a_user et vous exécuter plusieurs instances du programme client. Chaque nouvelle instance obtenue du serveur obtiendra la station Windows interactive. Supposons maintenant que le client est un service s'exécutant sous le compte système local. Le serveur COM dans ce cas partageront la station Windows du processus de service. b. client à distance. Dans le cas d'activation à distance, COM ignore la station de fenêtre du client dans la mesure où le client est distant. Comme toujours, un nouveau processus d'instance de serveur sera démarré pour chaque activation à distance. Les règles sont: 1. pour chaque client distant nouveau SID, une nouvelle station de fenêtre sera créée pour le processus du serveur. 2. Pour chaque nouveau distant client LUID, une nouvelle station de fenêtre sera créée pour le processus de serveur. 3. Tous les clients distants avec la même paire SID/LUID créera serveurs partageant la même station Windows. Par exemple, vous êtes connecté sur l'ordinateur client distant comme a_domain\a_user. Ce client lance le serveur distant qui obtiennent une nouvelle station de fenêtre. Maintenant, si a_domain\a_user démarre une deuxième instance de l'application cliente à partir de la même machine client qui à son tour lance une nouvelle copie du serveur sur l'ordinateur distant, ce serveur partagent station de fenêtre du serveur d'origine. Maintenant supposons que vous vous connectez à un autre ordinateur à nouveau en tant qu'a_domain\a_user et exécuter le client à partir de là. L'instance de serveur correspondante aura une nouvelle station de fenêtre. Cela démontre que même si le SID du client sont identiques, dans la mesure où le deuxième client a une LUID différent, son processus de serveur obtiendra une nouvelle station de fenêtre.
  4. Serveurs COM basées sur les services. Classes à usage unique doivent jamais être implémentées en tant que services Windows NT. Il n'a pas de sens, car il n'est pas possible d'exécuter plusieurs instances d'un processus de service Windows NT.

Tableau scénarios d'agrégation

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

Fenêtre stations et les ressources de Windows NT

Dans cette section, nous allons examiner les implications de la création de nouvelles stations window sous Windows NT et qui doit incidence sur la configuration de votre serveur COM. Comme vous le verrez, il existe une limite au nombre de stations de fenêtre peut être créé sur un ordinateur Windows NT. Lorsque cette limite est dépassée, Windows NT échouera que COM a tenté de lancer une nouvelle instance du processus du serveur. En règle générale, un message d'erreur semblable à celui-ci s'affiche :
Initialisation de la bibliothèque de liens dynamiques
d:\winnt\system32\KERNEL32.dll a échoué. Le processus est
fin anormale.
Sous Windows NT, chaque station Windows possède au moins un bureau lui est associé. Windows NT utilise un segment de mémoire spécial pour toutes les applications windows exécutées sur un ordinateur de bureau. Par défaut, chaque segment de bureau consomme 3 Mo de mémoire. Windows NT a une limite non configurable de 48 Mo pour la création de segments de bureautiques. Cela signifie que le nombre maximal de stations de fenêtre peut être créé sur un ordinateur Windows NT est 16 (probablement moins dans la mesure où une station Windows peut contenir plus d'un bureau). Pour augmenter ce nombre, vous pouvez réduire la taille de segment de bureau par défaut en modifiant le Registre à l'aide de l'Éditeur du Registre.

Avertissement: À l'aide de l'Éditeur du Registre incorrectement peut causer de problèmes graves, à l'échelle du système peuvent vous obliger à réinstaller Windows NT. Microsoft ne peut pas garantir que les problèmes résultant de l'utilisation de l'Éditeur du Registre puissent être résolus. Utilisez cet outil à vos risques et périls.

La valeur nommée, vous devez modifier apparaît sous la clé suivante :
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
   Manager\SubSystems
				
vous devez modifier la valeur nommé "Windows". Il s'agit d'une chaîne REG_SZ. Modifiez la chaîne et recherchez «Shared Section = 1024, 3 072». Modifier cette option pour lire «Shared Section = 1024, 3072, 512». Vous devez redémarrer l'ordinateur pour que cette modification prenne effet. En apportant cette modification, vous spécifiez taille de tas de 3 Mo (valeur par défaut) pour le bureau de la station Windows interactive et 512 Ko pour tous les non - interactif ordinateurs de bureau (le premier paramètre est obsolète mais ne doit pas être modifié). Cette modification permettra la création d'approximativement moins de 48 Mo/512 Ko ou 96 stations window.

Remarque : Une station Windows peut contenir plusieurs ordinateurs de bureau qu'il contient. Dans la discussion de serveurs «Utilisateur exécutant» ci-dessus, chaque fois que la station Windows du processus client local est mentionnée, elle doit être considérée comme un formulaire plus court pour «station Windows et bureau». Paramètre "Lancement utilisateur" est vraiment destiné aux serveurs conscients DCOM non hérités et doit être utilisé rarement. Ces serveurs hérités comptent s'exécuter dans leur propre bureau. Ainsi, pour MULTIPLEUSE "Utilisateur exécutant" serveurs, chaque processus client dans un bureau différent dans la même station Windows entraîne un nouveau processus de serveur doit être démarré dans cet fenêtre station/bureau. Pour SINGLEUSE "Utilisateur exécutant" serveurs, là encore, le serveur hérite de la station/bureau de windows du processus client.

Dans Windows NT 4.0 Service Pack 4.0 COM tente de réutiliser des stations window. Antérieures à, si un serveur a la valeur RunAs un utilisateur spécifique et si plusieurs instances de processus du serveur sont lancés, chaque processus obtiendra son propre station Windows. Cela se traduit par la station Windows limitations décrivent ci-dessus. Dans le Service Pack 4, COM va tenter de créer tous les serveurs de RunAs (c'est-à-dire, pas "Activer comme Activator" ou "Utilisateur exécutant") qui sont définis pour s'exécuter sous le même utilisateur identité (ou jeton) dans la même station de fenêtre.

Ceci élimine la nécessité de modifier la taille de segment de bureau dans les cas où plusieurs processus de serveur exécutent avec le même jeton. Si, dans votre configuration, tous les serveurs sont la valeur RunAs le même utilisateur, ou de plusieurs instances du même processus de serveur RunAs exécuter, vous devez réduire la heapsize bureau comme suggéré dans l'article. Il est recommandé que vous laisser la valeur par défaut (3M) dans ce cas. Cela est dû au fait que si vous réduisez le segment de bureau, le système peut créer plus fenêtre stations/bureaux ; toutefois, le nombre de processus qui peuvent s'exécuter dans un fenêtre station/bureau devient progressivement plus petit.

En revanche, dans votre configuration, si vous disposez de plusieurs serveurs exécutant avec jetons différents, puis vous serez confrontés les limitations de station de fenêtre. Dans ce cas, vous devez suivre les suggestions de l'article permettant de réduire la taille de segment de bureau.

Références

Pour plus d'informations sur le problème du noyau de bureau, consultez l'article suivant dans la base de connaissances Microsoft :

142676Comment corriger les erreurs courantes du fichier User32.dll

Propriétés

Numéro d'article: 169321 - Dernière mise à jour: lundi 11 juillet 2005 - Version: 2.5
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft OLE 4.0 sur le système suivant
    • Microsoft Platform Software Development Kit-January 2000 Edition
Mots-clés : 
kbmt kbapi kbdcom kbenv kbinfo kbinterop kbkernbase kbprogramming kbusage KB169321 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 169321
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

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