Estás trabajando sin conexión, espera a que vuelva la conexión a Internet

INFORMACIÓN: Activación de servidores COM y estaciones de Windows NT

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

169321
Resumen
Cuando un cliente solicita un objeto de clase para una clase registrada, COM devuelve un objeto de clase existente o inicia un proceso que está registrado como que contiene el objeto de clase solicitada. El proceso de obtener una referencia de objeto de clase para un cliente solicitante (o no que da como resultado la creación del proceso o "iniciar") se denomina "activación".

Bajo ciertas condiciones, COM puede iniciar un nuevo proceso de servidor incluso cuando un objeto de clase existente se está ejecutando y se ha registrado como el uso de varios. Además, cuando COM crea un nuevo proceso se puede iniciar ese proceso en un nuevo entorno de seguridad conocido como "estación de ventana" en lugar de compartir una estación de ventana existente, como la estación de ventana interactiva. (Para obtener más información acerca de las estaciones de ventana, busque la documentación Win32 SDK para esa frase.)

Es importante comprender los algoritmos de COM para crear nuevos procesos y las estaciones de ventana durante una solicitud de activación por varias razones. En primer lugar, COM puede crear más de una instancia de proceso de un objeto de clase de uso múltiple debido a problemas de seguridad. En segundo lugar, los servidores de "uso único" se iniciará siempre en procesos independientes pero puede o no puede iniciar en estaciones de ventana independiente. Esta diferencia podría manifestarse al código de aplicación en ciertos casos inusuales, como cuando dos servidores COM intentan comunicarse a través de los mensajes de ventana o instalaciones de comunicación segura como COM o RPC. En tercer lugar, puesto que el número de estaciones de ventana que simultáneamente se pueden crear en Windows NT es limitado, es importante saber cuándo el servidor COM obtiene una nueva estación de ventana.

En este artículo examina activación diferentes escenarios y explica cuándo se crean nuevos procesos y las estaciones de ventana.
Más información
Cuando crea un nuevo proceso de servidor COM o asigna una nueva estación de ventana a un nuevo proceso de servidor depende de varios factores:
  1. La identidad de seguridad en el que la clase COM está establecida en iniciar. La identidad de una clase se puede establecer mediante la herramienta DCOMCNFG y se especifica mediante la RunAs denominado valor bajo la clave AppID de la clase.
  2. Uso único registro de uso múltiple de vs mediante objetos de clase.
  3. Identifier(SID) de seguridad del proceso de cliente (Esto es el valor numérico que representa a un determinado usuario cuenta/identidad o principal de seguridad en un entorno de Windows NT).
  4. El identificador de inicio de sesión (LUID) del cliente de proceso. (un nuevo identificador de inicio de sesión se genera para cada inicio de sesión único a un equipo que ejecuta Windows NT. Este inicio de sesión puede ser a través de un usuario escriba un nombre de usuario y una contraseña en el símbolo de inicio de sesión de NT o mediante una llamada a LogonUser de la API win32.)
  5. Activación remota de vs local.
  6. La estación de ventana del cliente.

Clases de uso múltiple

Una clase de uso múltiple es una clase que está registrada con COM (a través de API CoRegisterClassObject()) que especifica el indicador REGCLS_MULTIPLEUSE. Para una clase, COM normalmente utiliza la misma instancia del proceso del servidor para todas las solicitudes de activación cliente. Sin embargo, para las clases configuradas para ejecutarse en la seguridad de los usuarios iniciar y en unos de otros casos, COM inicia una nueva instancia de proceso del servidor a las solicitudes de activación del servicio. Cuando así se inicia una nueva instancia de proceso del servidor, es posible que el proceso de servidor obtiene también una nueva estación de ventana. Examinaremos los distintos escenarios siguientes, pero primero trataremos brevemente por qué COM inicia nuevos procesos que contiene objetos de la clase solicitada cuando una instancia del objeto de clase ya está registrada como una clase de "uso de varios".

Primero, cuando una clase COM (de forma más precisa, cuando un AppID asociada con una clase COM) está registrado con el sistema que se ejecute como "usuario inicial", el administrador del sistema ha establecido una determinada directiva de seguridad con respecto a esa clase. La directiva es que un activador debe recibir un objeto de clase dentro de un proceso que se está ejecutando en el mismo contexto de seguridad que el código de activación.

Esta directiva de seguridad puede entran en conflicto con el comportamiento definido por el servidor de tener sólo un objeto de fábrica de clase para todas las solicitudes de activación (como se indica por REGCLS_MULTIPLEUSE). COM da prioridad a la directiva de seguridad sobre el comportamiento de la aplicación. Como resultado, uso de varios servidores registrados para ejecutarse como "usuario inicial" no se comportan según a las reglas normales de uso múltiple. Se iniciará un nuevo proceso para cada principal de seguridad de activación.

En segundo lugar, si un proceso que inicia COM que se ejecuta en un contexto de seguridad distinto del especificado para el CLSID especificado no registra ese CLSID, que el registro volverá fail(CoRegisterClassObject will return an error code CO_E_WRONG_SERVER_IDENTITY in this case). Y, si más adelante llega una solicitud de activación COM se iniciará un nuevo proceso con el contexto de seguridad especificado para el CLSID/AppID. COM no puede confiar en código llamando CoRegisterClassObject() (una operación no segura), sólo puede confiar en la configuración del registro (el registro es una base de datos segura) para determinar qué objeto de clase se va a utilizar y cómo ejecutarlo. Este comportamiento impide que todo el equipo ilícito la suplantación de objetos de clase por usuarios no autorizados.

Con eso en mente, ahora volvemos al problema de cuando se crean nuevos procesos y las estaciones de ventana cuando se inician los servidores de uso múltiple mediante COM. Observe que el LUID del cliente no importa de cualquier forma en el caso de uso múltiple de clase.
  1. Identidad de seguridad de "Usuario interactivo". En el caso donde está configurado el AppID de la clase de COM de uso múltiple para ejecutarse como la identidad "Usuario interactivo", el primer proceso del servidor y su objeto clase se utilizará por COM para atender todas las solicitudes de activación posteriores. Esta instancia de servidor tendrá la estación de ventana interactiva, si existe uno (si ningún usuario ha iniciado sesión localmente, todas las solicitudes de activación producirá). Como se indicó anteriormente, si no se inicia un proceso por COM y no está ejecutando en la estación de ventana interactiva registra el CLSID, producirá que el registro. Y, si más adelante llega una solicitud de activación, se iniciará un nuevo proceso con el contexto de seguridad del usuario interactivo. Este comportamiento impide que la suplantación ilícito de objetos de clase. Puesto que ningún proceso de servidor adicional nunca se inicia mediante COM, la pregunta de nuevas estaciones de ventana es discutible. El SID del cliente, su LUID o si es local o remoto no importa en este caso.
  2. Identidad de seguridad "Este usuario". De forma similar, si una clase de COM de uso múltiple de AppID está configurado para ejecutarse como "este usuario" (un ID de seguridad predefinidas), el primer servidor de proceso y su objeto de clase se utilizará por COM para atender todas las solicitudes de activación posteriores. Esta primera instancia de servidor tendrá su propia estación de ventana creado como parte de la primera creación del proceso. Puesto que ningún proceso de servidor adicional nunca se inicia mediante COM, la pregunta de estaciones de ventana adicionales es discutible. El SID del cliente, su LUID o si es local o remoto no importa en este caso. Observe que se se creará una nueva estación de ventana al iniciar la primera instancia de una clase o AppID configurado para ejecutarse como "Este usuario", incluso si el mismo usuario está iniciado sesión en el winstation interactivo. COM utiliza nunca el winstation interactivo para iniciar un servidor configurado para ejecutarse como "Este usuario" porque tendría como resultado un comportamiento diferente para la clase según el problema no relacionado de la identidad del usuario actualmente conectado. Como se indicó anteriormente, si no se inicia un proceso por COM y no está ejecutando en la cuenta especificada en "Este usuario" intenta registrar el CLSID, que producirá un registro y si una solicitud de activación más tarde llega un nuevo proceso se iniciará en la cuenta "Este usuario". Este comportamiento impide que la suplantación ilícito de objetos de clase. Por otro lado, si el proceso registrado para un CLSID/APPID especificado está configurada para ejecutarse como "Este usuario", se crea en la cuenta de usuario adecuados por algún agente distinto de COM (por ejemplo, se ejecuta por el usuario interactivo cuando el usuario interactivo es el mismo usuario que "Este usuario" o se inicia a través de CreateProcess() por un servicio está ejecutando en el mismo contexto de seguridad como "este usuario") y a continuación, registra sus objetos de clase REGCLS_MULTIPLEUSE, COM utilizará el objeto de clase de ejecución existente para satisfacer solicitudes de activación entrantes posteriores desde cualquier cliente.
  3. Identidad de seguridad "Iniciar el usuario". En este caso, el AppID de la clase se establece en iniciar en el idenitity "Usuario inicial" (también conocido como es una clase de "Activar como activador"). cliente a. local. Primero, considere el caso de equipo local. Hay dos reglas: 1. cada cliente de activación diferentes SID provocará COM iniciar una nueva instancia de proceso del servidor incluso en la misma estación de ventana. 2. Incluso para coincidencia de SID (como el caso donde el mismo usuario ha iniciado sesión en más de una vez un único equipo NT), cada estación de ventana de cliente local diferente provocará COM iniciar una nueva instancia de proceso del servidor. En otras palabras, iniciar los servidores de uso múltiple de identidad de usuario nunca se comparten entre estaciones de ventana. Todos los procesos de cliente con el mismo SID y el mismo estaciones de ventana compartirán un proceso de servidor único en la misma estación de ventana. Puesto que el servidor comparte la estación de ventana del cliente no se crean estaciones de ventana nueva. Por ejemplo, supongamos que haya interactivamente iniciado la sesión como a_domain\a_user. Ejecutar varias instancias del cliente, todos los cuales se conectarán a la misma instancia del servidor (que tiene la estación de ventana interactiva). Ahora supongamos que tiene un cliente, que es un servicio, que se establece para iniciar iniciar bajo a_domain\a_user. Este servicio iniciará una nueva instancia del servidor COM. Esto sucede porque COM provocará una nueva instancia del servidor que se iniciará debido a que el proceso de servicio tiene una estación de ventana distinta de la estación de ventana interactiva--incluso aunque la identidad del proceso service(client) es la misma como la identidad del proceso de servidor de ejecución (a_domain\a_user). Sin embargo, tenga en cuenta que ninguna estación de ventana nueva se crea para el proceso de servidor COM. El servidor todavía heredarán la estación de ventana del servicio. Si el servicio está configurado para iniciar bajo LocalSystem y para interactuar con el escritorio (consulte cuadro de verificación "Permitir servicio para interactuar con Desktop" en el servicio de subprograma en el panel de control), a continuación, el servicio se ejecute en la estación de ventana interactiva o winsta0. En este caso COM todavía iniciará una nueva instancia de éste (SID del cliente que es LocalSystem en este caso es distinto del SID del servidor que es a_domain\a_user) en la estación de ventana interactiva. cliente remoto b.. En el caso de activación remota, COM pasa por alto la estación de ventana del cliente porque el cliente es remoto, a diferencia del caso local anterior. La regla aquí es que cada cliente nuevo SID provocarán una nueva instancia de se iniciará el proceso de servidor y cada proceso de servidor nuevo obtendrá una nueva estación de ventana. Activación posteriores solicitudes por los clientes remotos con el mismo que SID reutilizará que la existente registrado objeto de clase, así como su estación de ventana y el proceso. Por ejemplo, suponga que ha iniciado como a_domain\a_user en 10 equipos diferentes. Los clientes de todos estos equipos se conectarán a la misma instancia del servidor en el equipo servidor. Un cliente desde un equipo a_domain\b_user iniciará una nueva instancia de servidor y una nueva estación de ventana. Los llamadores remotos con el mismo SID que un usuario local que ha iniciado el servidor COM registrado para el CLSID solicitado volverá a utilizar el objeto de clase existente. Sin embargo, el orden en que se inicia el servidor COM es importante en este caso. Si el servidor se inicia primero por el cliente local, el cliente remoto con el mismo SID se conectará a este servidor. Por otro lado, si el servidor se inicia primero por el cliente remoto, un cliente local con el mismo SID iniciará una nueva instancia del servidor. Esto vuelve a las reglas de estación de ventana mencionadas. Para los clientes locales, la estación de ventana del cliente y el servidor debe coincidir, para clientes remotos que se omite la estación de ventana del cliente. Por ejemplo, si a_domain\a_user cliente local inicia primero el servidor, a_domain\a_user de cliente remoto se conectará al servidor. Por el contrario, si a_domain\a_user de cliente remoto inicia primero el servidor, cliente local a_domain\a_user se iniciará una nueva instancia de servidor y una nueva estación de ventana. LUID del cliente no se importa en este caso.
  4. Servidores de COM basados en servicios. Un COM clase/AppID que está empaquetado en un servicio Win32 es necesidad práctica un servidor de uso múltiple desde servicios se pueden iniciar sólo una vez. En este caso, en la primera solicitud de activación se inicia un nuevo proceso en su propia estación de ventana. Hay dos excepciones a esta: a. Si el servicio está establecido para iniciar bajo la cuenta LocalSystem, heredará una estación de ventana predefinida del sistema. b. Si el servicio está establecido para iniciar bajo la cuenta LocalSystem y puede interactuar con el escritorio, heredará la estación de ventana interactiva o winsta0. Todas las solicitudes posteriores de activación, ya sea local o remoto, se controlan mediante objeto de clase del servicio. Como se indicó anteriormente, si un proceso que no se inicia por COM y no se ejecuta como el servicio especificado registra el CLSID, que el registro fallará y si una solicitud de activación más tarde llega servicio registrado se iniciará. Este comportamiento impide que la suplantación ilícito de objetos de clase.

Clases de uso único

Nota: Las clases de único uso deben evitarse tanto como sea posible. Registro de uso único es una configuración heredada y está diseñado para admitir las aplicaciones COM antiguas y para facilitar la migración de aplicaciones de COM no heredadas a COM. Se recomienda encarecidamente que se diseñe nuevas clases para admitir registro de objeto de clase de uso múltiple. Esto es especialmente cierto en el caso de servidores con identidad "De este usuario", donde las clases de uso único hacen que las opuestas efecto de clases multiuso exactas. Crearán un nuevo servidor proceso y nueva estación de ventana por activación y, como veremos a continuación, esto puede causar problemas de recursos en Windows NT.

Una clase de uso único es aquel que está registrado con COM (a través de la API CoRegisterClassObject()) que especifica el indicador REGCLS_SINGLEUSE. Para una clase, COM siempre iniciará una nueva instancia de proceso de servidor de la clase para cada solicitud de activación desde cualquier cliente (local o remoto). ¿Para los fines de este artículo, es la cuestión restante: cuando el servidor obtendrá también una nueva estación de ventana?
  1. Identidad de seguridad de "Usuario interactivo". Tomar el caso en el que la clase de uso único se establece a través de su AppID iniciar bajo la identidad "Usuario interactivo". Para este caso, cada nueva instancia del proceso del servidor siempre compartirán la estación de ventana interactiva, si existe una (si ningún usuario ha iniciado sesión localmente, todas las solicitudes de activación producirá). No se creará ninguna nueva estación de ventana por COM.
  2. Identidad de seguridad "Este usuario". Ahora, considere el caso donde AppId de la clase de COM de uso único está configurado para ejecutarse bajo la identidad "De este usuario". En este caso, la regla es muy sencilla. Cada nueva activación de cliente inicia un proceso nuevo en una nueva estación de ventana. Esto es cierto independientemente de si el usuario especificado como "Este usuario" ha iniciado sesión en la estación de ventana interactiva en el momento de cualquiera de las solicitudes de activación.
  3. Identidad de seguridad "Iniciar el usuario". cliente a. local. En el escenario de activación de equipo local, el proceso del servidor siempre obtendrá la estación de ventana del cliente. Nunca se crean no estaciones de ventana nueva. Por ejemplo, supongamos que haya interactivamente iniciado la sesión como a_domain\a_user y ejecutar varias instancias del programa cliente. Cada nueva instancia resultante del servidor obtendrá la estación de ventana interactiva. Ahora suponga que el cliente es un servicio ejecutándose bajo la cuenta local del sistema. En este caso el servidor COM compartirán la estación de ventana del proceso de servicio. cliente remoto b.. En el caso de activación remota, COM omite la estación de ventana del cliente, puesto que el cliente es remoto. Como siempre, se iniciará un nuevo proceso de instancia de servidor para cada activación remota. Las reglas son: 1. para cada cliente remoto SID nuevo, se creará una nueva estación de ventana para el proceso del servidor. 2. Para cada cliente remoto LUID nuevo, se creará una nueva estación de ventana para el proceso del servidor. 3. Todos los clientes remotos con el mismo par de SID/LUID creará los servidores que comparten la misma estación de ventana. Por ejemplo, ha iniciado en el equipo cliente remoto como a_domain\a_user. Este cliente inicia el servidor remoto que obtendrá una nueva estación de ventana. Ahora, si a_domain\a_user se inicia una segunda instancia de la aplicación de cliente desde el mismo equipo cliente que a su vez inicia una nueva copia del servidor en el equipo remoto, este servidor compartirán estación de ventana del servidor original. Ahora suponga que inicie sesión en otro equipo nuevo como a_domain\a_user y ejecutar al cliente desde allí. La instancia del servidor correspondiente tendrá una nueva estación de ventana. Esto demuestra que incluso si el SID del cliente son los mismos, ya que el segundo cliente tiene un LUID diferente, su proceso de servidor obtendrá una nueva estación de ventana.
  4. Servidores de COM basados en servicios. Nunca se deben implementar las clases de uso único como servicios de Windows NT. No tiene sentido, ya no es posible ejecutar varias instancias de un proceso de servicio de Windows NT.

Tabla de escenarios Summarizing

---------------------------------------------------------------------------
       |                      Multiple-Use Server       |             (class factory has requested reuse)       |                       Activation Modes       |-------------------------------------------------------------------       |   Interactive     | As "This       |As "Launching    | Win32Client |      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-------|                   |                |-----------------| existingRemote |                   |                | 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    | Win32Client |      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   |				
---------------------------------------------------------------------------

Recursos de Windows NT y estaciones de ventana

En esta sección, examinaremos las implicaciones de creación de nuevas estaciones de ventana en Windows NT y cómo que debe afectan a la configuración del servidor COM. Como verá, tiene un límite al número de estaciones de ventana que se pueden crear en un equipo Windows NT. Cuando se supera dicho límite, Windows NT producirá un intento de COM de iniciar una nueva instancia de proceso del servidor. Normalmente, aparece un mensaje de error similar al siguiente:
Inicialización de la biblioteca de vínculos dinámicos
No se pudo d:\winnt\system32\kernel32.dll. El proceso es
Fin anómalo.
En Windows NT, cada estación de ventana tiene al menos un escritorio asociado con él. Windows NT utiliza un montón de memoria especial para todas las aplicaciones de windows que se ejecutan en un escritorio. De forma predeterminada, cada montón del escritorio consume 3 MB de memoria. Windows tiene un límite no configurable de 48 MB para crear montones de escritorio. Esto significa que el número máximo de estaciones de ventana que se pueden crear en un equipo Windows NT es 16 (probablemente menos como una estación de ventana puede contener más de un escritorio). Para aumentar este número, puede reducir el tamaño del montón de escritorio predeterminado modificando el registro mediante el Editor del registro.

AVISO: Utilizar el Editor del Registro incorrectamente puede provocar problemas graves en todo el sistema que le obliguen a reinstalar Windows NT para corregirlos. Microsoft no puede garantizar la solución de los problemas resultantes del uso del Editor del Registro. Utilice esta herramienta bajo su responsabilidad.

El valor con nombre, deberá modificar aparece en la siguiente clave:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session   Manager\SubSystems				
tiene que modificar el valor con nombre "Windows". Es una cadena REG_SZ. Edite la cadena y busque "Shared sección = 1024, 3072". Modificar esta opción para leer "Shared sección = 1024, 3072, 512". Deberá reiniciar el equipo para que este cambio surta efecto. Al realizar este cambio, está especificando 3 MB (predeterminado) tamaño del montón de escritorio de la estación de ventana interactiva y 512 KB para todos los no - interactivo escritorios (el primer parámetro está obsoleto pero no debe cambiarse). Este cambio permitirá la creación de aproximadamente menos 48 MB y 512 KB o 96 estaciones de ventana.

Nota: Una estación de ventana puede contener varios escritorios dentro de él. En la discusión de servidores de "Usuario inicial" anterior, siempre que se menciona la estación de ventana del proceso de cliente local, se debe considerar como un formulario más corto "estación de ventana y escritorio". Configuración de "Iniciar el usuario" realmente está destinado a heredados no DCOM compatibles con servidores y debe utilizarse de rara vez. Dichos servidores heredados esperan ejecutar en sus propios escritorios. Por lo tanto, para MULTIPLEUSE "Usuario inicial" servidores, cada proceso de cliente en un escritorio diferente dentro de la misma estación de ventana provoca el nuevo proceso de servidor se inició en ese escritorio y estación de ventana. Para SINGLEUSE "Usuario inicial" servidores, de nuevo, el servidor herede el escritorio y estación de ventanas del proceso del cliente.

En Windows NT 4.0 Service Pack 4.0, COM intenta reutilizar las estaciones de ventana. Antes a esto, si un servidor se establece a ejecutar como un usuario específico y se inician varias instancias de proceso del servidor, cada proceso obtendrá su propia estación de ventana. Esto conduce a la estación de ventana limitaciones se describen anteriormente. En el SP4, COM intentará crear todos los servidores de RunAs (es decir, no "Activar como activador" o "Usuario inicial") están configurados para ejecutarse en el mismo usuario identidad (o símbolo (token)) en la misma estación de ventana.

Esto elimina la necesidad para ajustar el tamaño de montón de escritorio en aquellos casos donde en que varios procesos de servidor se ejecutan con el mismo testigo. Si en su configuración, todos los servidores se establecen a RunAs el mismo usuario o varias instancias del mismo proceso del servidor RunAs ejecutar, no debería reducir el heapsize de asistencia al cliente superior como se sugiere en el artículo. Se recomienda que lo deje el valor predeterminado (3 M) en este caso. Esto es debido a que, si reduce el montón del escritorio, el sistema puede crear más estaciones de ventana y escritorios; sin embargo, el número de procesos que pueden ejecutarse en un estación de ventana y escritorio convertirá en progresivamente más pequeño.

Por otro lado, en la configuración, si tiene varios servidores que ejecutan con diferentes tokens, a continuación, se enfrentará las limitaciones de estación de ventana. En este caso, debe seguir las sugerencias en el artículo para reducir el tamaño del montón de escritorio.
Referencias
Para obtener información adicional acerca del problema montón de escritorio, consulte en contacto con el siguiente artículo en Microsoft Knowledge Base:

142676Cómo corregir errores comunes de archivo de User32.dll

Advertencia: este artículo se ha traducido automáticamente

Propiedades

Id. de artículo: 169321 - Última revisión: 07/11/2005 19:06:47 - Revisión: 2.5

  • Microsoft OLE 4.0
  • kbmt kbapi kbdcom kbenv kbinfo kbinterop kbkernbase kbprogramming kbusage KB169321 KbMtes
Comentarios