none
Pantalla azul granja rdp RRS feed

  • Pregunta

  • Hola

    Actualmente tengo una granja de rdp (5 Servidores virtuales Server 2012 r2) que se reinician de manera aleatoria. Aproximadamente se conectan 50 usuarios remotamente. 

    A continuación adjunto infomacion de bluescreen. Agradecería cualquier ayuda si existe algun hotfix o actualización que mitigue el error. Muchas gracias.

    Debugging Details:
    ------------------

    ==================================================
    Dump File         : 090319-6046-01.dmp
    Crash Time        : 3/09/2019 4:57:18 p. m.
    Bug Check String  : REFERENCE_BY_POINTER
    Bug Check Code    : 0x00000018
    Parameter 1       : 00000000`00000000
    Parameter 2       : ffffe001`da20d080
    Parameter 3       : 00000000`00000010
    Parameter 4       : 00000000`00000001
    Caused By Driver  : rdbss.sys
    Caused By Address : rdbss.sys+316f1
    File Description  : 
    Product Name      : 
    Company           : 
    File Version      : 
    Processor         : x64
    Crash Address     : ntoskrnl.exe+1403a0
    Stack Address 1   : 
    Stack Address 2   : 
    Stack Address 3   : 
    Computer Name     : 
    Full Path         : 
    Processors Count  : 4
    Major Version     : 15
    Minor Version     : 9600
    Dump File Size    : 307.984
    Dump File Time    : 3/09/2019 4:59:32 p. m.
    ==================================================
    • Editado Jonathan_PP martes, 17 de septiembre de 2019 20:42
    martes, 10 de septiembre de 2019 22:09

Respuestas

  • Esta ya es otra canción. Aunque el .dmp apunta a un componente y un servicio de Windows ya hay reportes recientes de este error y sobre quien esta detrás.

    El driver de Windows: rdbss.sys

    El servicio: Rx Acquire Fcb

    En el foro en ingles encontré varios hilos al respecto, el que me parece mas relevante es este:

    RDS Servers Events 7011, 7046 - BSOD rdbss.sys
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/86f3ca6b-f780-4618-a595-9818ab36bb4b/rds-servers-events-7011-7046-bsod-rdbsssys?forum=winserverTS

    La solución la encontró el mismo usuario que inicio el hilo, Tee-Eff. El escenario es similar, el sistema esta instalado en una maquina virtual de VMWare. Al parecer esta relacionado con Acrobat Reader (¿Cuando funcionara bien esta cosa?) De modo que con la el cambio en la configuración de Acrobat o la modificación del registro que propone el problema debería estar resuelto:


    Saludos cordiales. Ivan

    • Marcado como respuesta Jonathan_PP jueves, 19 de septiembre de 2019 14:25
    domingo, 15 de septiembre de 2019 16:41

Todas las respuestas

  • Hola     Jonathan_PP


    Gracias por levantar tu consulta en los foros de TechNet. Con respecto a la misma, te comparto con base a la consulta de un especialista  te comento lo siguiente: 

    1. Revisar el driver  rdbss.sys y actualizarlo ya que probablemente esté desactualizado
    2. te comparto el siguiente enlace que puede serte útil:   https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x18--reference-by-pointer

     

    Gracias por usar los foros de TechNet.

    Pablo Rubio

     _____

     

    Por favor recuerde "Marcar como respuesta" las respuestas que hayan resuelto su problema, es una forma común de reconocer a aquellos que han ayudado, y hace que sea más fácil para los otros visitantes encontrar la solución más tarde. 

     

    Microsoft ofrece este servicio de forma gratuita, con la finalidad de ayudar a los usuarios y la ampliación de la base de datos de conocimientos relacionados con los productos y tecnologías de Microsoft.  

     

    Este contenido es proporcionado "tal cual" y no implica ninguna responsabilidad de parte de Microsoft.

    miércoles, 11 de septiembre de 2019 15:29
    Moderador
  • Muchas gracias por tu respuesta Pablo.

    El hotfix que actualiza dicho driver ya esta aplicado en el servidor. Hay algun otro metodo para actualizar dicho driver?

    Muchas gracias por tu ayuda.

    miércoles, 11 de septiembre de 2019 16:04
  • 1. Si esta utilizando whocrashed o algún programa similar nunca encontrara la causa de los errores. En absolutamente todas las pruebas que hice con ese software siempre apuntaba, tal como en su caso, a ntoskrnl.exe (Parte del Núcleo de Windows, casi nada).
    Así mismo rdbss.sys (Redirected Drive Buffering Subsystem) es un controlador interno del sistema operativo mas no señala quien esta detrás de esos cuelgues.

    Si esos resultados fuesen valederos tendríamos una seria epidemia de cuelgues y protestas masivas, cosa que no esta ocurriendo.

    Si desea tener idea del error e intentar solucionarlo necesita una herramienta valida, la version mas reciente de Windbg se obtiene desde este vinculo:
    •Get Debugging Tools for Windows (WinDbg) from the SDK: version 1903
    https://developer.microsoft.com/windows/downloads/windows-10-sdk
    (If you just need the Debugging Tools for Windows 10, and not WDK 10 or Visual Studio Community 2015, you can install the tools as a standalone component from Windows SDK. In the installation wizard, select Debugging Tools for Windows, and deselect all other components.)

    Un buen manual para configurar y utilizar WinDbg, aunque escrito en tiempos de Windows XP esta vigente (excepto el vinculo de descarga):
    BSOD - Pantalla azul - Analizar el error
    http://jmtella.com/jmt/page/BSOD-Pantalla-azul.aspx


    2. Olvide los minidump, si desea tener algún resultado analice el MEMORY.DMP que esta localizado el C:\Windows


    Saludos cordiales. Ivan

    • Propuesto como respuesta Pablo RubioModerator miércoles, 11 de septiembre de 2019 21:34
    • Votado como útil Jonathan_PP jueves, 12 de septiembre de 2019 17:33
    • Propuesto como respuesta Pablo RubioModerator jueves, 12 de septiembre de 2019 21:06
    • Votado como útil Jonathan_PP martes, 17 de septiembre de 2019 20:42
    miércoles, 11 de septiembre de 2019 16:15
  • 1. Si esta utilizando whocrashed o algún programa similar nunca encontrara la causa de los errores. En absolutamente todas las pruebas que hice con ese software siempre apuntaba, tal como en su caso, a ntoskrnl.exe (Parte del Núcleo de Windows, casi nada).
    Así mismo rdbss.sys (Redirected Drive Buffering Subsystem) es un controlador interno del sistema operativo mas no señala quien esta detrás de esos cuelgues.

    Si esos resultados fuesen valederos tendríamos una seria epidemia de cuelgues y protestas masivas, cosa que no esta ocurriendo.

    Si desea tener idea del error e intentar solucionarlo necesita una herramienta valida, la version mas reciente de Windbg se obtiene desde este vinculo:
    •Get Debugging Tools for Windows (WinDbg) from the SDK: version 1903
    https://developer.microsoft.com/windows/downloads/windows-10-sdk
    (If you just need the Debugging Tools for Windows 10, and not WDK 10 or Visual Studio Community 2015, you can install the tools as a standalone component from Windows SDK. In the installation wizard, select Debugging Tools for Windows, and deselect all other components.)

    Un buen manual para configurar y utilizar WinDbg, aunque escrito en tiempos de Windows XP esta vigente (excepto el vinculo de descarga):
    BSOD - Pantalla azul - Analizar el error
    http://jmtella.com/jmt/page/BSOD-Pantalla-azul.aspx


    2. Olvide los minidump, si desea tener algún resultado analice el MEMORY.DMP que esta localizado el C:\Windows


    Saludos cordiales. Ivan

    Muchas gracias por tu respuesta Ivan.

    Actualmente estoy descargando el wsdk para analizar el archivo MEMORY.DMP, estare posteando el resultado de lo que obtenga.

    Gracias.

    • Propuesto como respuesta Pablo RubioModerator miércoles, 11 de septiembre de 2019 21:34
    • Votado como útil Jonathan_PP jueves, 12 de septiembre de 2019 12:52
    • Propuesto como respuesta Pablo RubioModerator viernes, 13 de septiembre de 2019 17:07
    • Votado como útil Jonathan_PP martes, 17 de septiembre de 2019 20:43
    miércoles, 11 de septiembre de 2019 19:37
  • Cordial Saludo.

    A continuacion adjunto resultado de analizar memory.dmp

    ---------

    0: kd> !object ffffe0002b445080
    Object: ffffe0002b445080  Type: (ffffd001d434c000) 
        ObjectHeader: ffffe0002b445050 (new version)
        HandleCount: 0  PointerCount: 1
    0: kd> !trueref ffffe0002b445080
    ffffe0002b445080: HandleCount: 0 PointerCount: 1 RealPointerCount: 1

    0: kd> !findhandle ffffe0002b445080
    Object ffffe0002b445080 has no outstanding handles.

    • Propuesto como respuesta Pablo RubioModerator jueves, 12 de septiembre de 2019 17:23
    • Votado como útil Jonathan_PP jueves, 12 de septiembre de 2019 17:33
    • Propuesto como respuesta Pablo RubioModerator jueves, 12 de septiembre de 2019 21:06
    • Votado como útil Jonathan_PP viernes, 13 de septiembre de 2019 12:52
    jueves, 12 de septiembre de 2019 14:00
  • Cordial Saludo.

    Aun se presentan los reinicios inesperados con el mismo error descrito al hacer el debug sobre el archivo memory.dmp

    Desearia saber si hay algo mas que se pueda realizar. Gracias.

    • Propuesto como respuesta Pablo RubioModerator viernes, 13 de septiembre de 2019 17:07
    • Votado como útil Jonathan_PP martes, 17 de septiembre de 2019 20:43
    viernes, 13 de septiembre de 2019 14:43
  • Lo que muestra en su mensaje no tine sentido sin el resto. A ver, tal como explica el articulo, luego de realizar el análisis se ejecuta el comando:  !analyze -v  que debería mostrar algo como esto:

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver has failed to complete a power IRP within a specific time.
    Arguments:
    Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
    Arg2: ffffe000c0b52060, Physical Device Object of the stack
    Arg3: fffff80119f1f990, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
    Arg4: ffffe000bb313a70, The blocked IRP

    Y mas abajo:

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: ZTEusbwwan

    IMAGE_NAME:  ZTEusbwwan.sys

    Si esta ultima información es dudosa o no apareciera, se debe analizar el Arg que muestre esta linea Address of the IRP. en este caso se procede:

    > !IRP xxxxxx

    Aunque en esta muestra el componente esta ya identificado: ZTEusbwwan.sys es parte de los drivers de un modem USB.Si no logra hacer el análisis puede copiar el texto al Block de notas y subirlo a algún servidor de archivos como Dropbox o OneDrive y nos deja el vinculo de descarga para echarle un ojo.


    Saludos cordiales. Ivan

    viernes, 13 de septiembre de 2019 16:00
  • Hola Ivan muchas gracias por tu respuesta. 

    A continuacion adjunto el archivo completo. De antemano muchas gracias.

    3: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    REFERENCE_BY_POINTER (18)
    Arguments:
    Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
    Arg2: ffffe001da20d080, Object whose reference count is being lowered
    Arg3: 0000000000000010, Reserved
    Arg4: 0000000000000001, Reserved
    The reference count of an object is illegal for the current state of the object.
    Each time a driver uses a pointer to an object the driver calls a kernel routine
    to increment the reference count of the object. When the driver is done with the
    pointer the driver calls another kernel routine to decrement the reference count.
    Drivers must match calls to the increment and decrement routines. This bugcheck
    can occur because an object's reference count goes to zero while there are still
    open handles to the object, in which case the fourth parameter indicates the number
    of opened handles. It may also occur when the object's reference count drops below zero
    whether or not there are open handles to the object, and in that case the fourth parameter
    contains the actual value of the pointer references count.

    Debugging Details:
    ------------------

    GetUlongPtrFromAddress: unable to read from fffff801a9968308

    KEY_VALUES_STRING: 1


    PROCESSES_ANALYSIS: 1

    SERVICE_ANALYSIS: 1

    STACKHASH_ANALYSIS: 1

    TIMELINE_ANALYSIS: 1


    DUMP_CLASS: 1

    DUMP_QUALIFIER: 400

    BUILD_VERSION_STRING:  9600.19395.amd64fre.winblue_ltsb.190606-0600

    SYSTEM_MANUFACTURER:  VMware, Inc.

    VIRTUAL_MACHINE:  VMware

    SYSTEM_PRODUCT_NAME:  VMware Virtual Platform

    SYSTEM_VERSION:  None

    BIOS_VENDOR:  Phoenix Technologies LTD

    BIOS_VERSION:  6.00

    BIOS_DATE:  12/12/2018

    BASEBOARD_MANUFACTURER:  Intel Corporation

    BASEBOARD_PRODUCT:  440BX Desktop Reference Platform

    BASEBOARD_VERSION:  None

    DUMP_TYPE:  2

    BUGCHECK_P1: 0

    BUGCHECK_P2: ffffe001da20d080

    BUGCHECK_P3: 10

    BUGCHECK_P4: 1

    CPU_COUNT: 4

    CPU_MHZ: 8fc

    CPU_VENDOR:  GenuineIntel

    CPU_FAMILY: 6

    CPU_MODEL: 2d

    CPU_STEPPING: 2

    CPU_MICROCODE: 6,2d,2,0 (F,M,S,R)  SIG: 2000055'00000000 (cache) 2000055'00000000 (init)

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT_SERVER

    BUGCHECK_STR:  0x18

    PROCESS_NAME:  svchost.exe

    CURRENT_IRQL:  0

    ANALYSIS_SESSION_HOST:  PORTATIL-ITC06

    ANALYSIS_SESSION_TIME:  09-12-2019 15:28:40.0086

    ANALYSIS_VERSION: 10.0.18362.1 x86fre

    LAST_CONTROL_TRANSFER:  from fffff801a977d95d to fffff801a975a3a0

    STACK_TEXT:  
    ffffd000`21ad7e88 fffff801`a977d95d : 00000000`00000018 00000000`00000000 ffffe001`da20d080 00000000`00000010 : nt!KeBugCheckEx
    ffffd000`21ad7e90 fffff801`a9663042 : 00000000`00000002 fffff801`77e316f1 ffffc1d1`40980088 ffffc1d1`9724a888 : nt! ?? ::FNODOBFM::`string'+0xe82d
    ffffd000`21ad7ed0 fffff801`a9662ea3 : 00000000`0000eb01 00000000`00000001 00000000`00000001 00000000`00000002 : nt!ExpApplyPriorityBoost+0x16a
    ffffd000`21ad7f40 fffff801`a96703ea : ffffe001`b8fcf3c0 ffffe001`cc09d090 ffffe001`00000001 fffff801`00000001 : nt!ExpWaitForResource+0x673
    ffffd000`21ad7ff0 fffff801`77e33a67 : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`c0000055 : nt!ExAcquireResourceExclusiveLite+0x1da
    ffffd000`21ad8060 fffff801`77e41b5e : ffffc000`e72e3ab0 ffffe001`acd4e201 ffffe001`d1232e10 ffffe001`d1232a10 : rdbss!__RxAcquireFcb+0xe7
    ffffd000`21ad80e0 fffff801`793bc2d6 : ffffe001`d1232a10 ffffe001`bc22e010 ffffe001`00000001 ffffe001`ac6e3b01 : rdbss!RxFinalizeConnection+0x21e
    ffffd000`21ad81a0 fffff801`793bc447 : ffffe001`b5a55af0 ffffe001`ac6e3b60 ffffe001`ac6e3a90 00000000`00000000 : rdpdr!DrDeleteAllConnections+0x1a6
    ffffd000`21ad8210 fffff801`793c192f : ffffe001`b5a55af0 ffffd000`21ad8320 ffffd000`21ad82d0 00000000`00000003 : rdpdr!DrSession::Disconnect+0x83
    ffffd000`21ad8250 fffff801`793c2312 : ffffe001`ac6e3a90 00000080`59f3f168 00000080`59f3f170 ffffe001`b5a55af0 : rdpdr!DrSessionManager::OnDisconnect+0x67
    ffffd000`21ad8280 fffff801`793c358b : 00000000`00000000 00000000`00000010 ffffc000`c2aef6e0 00000000`00000003 : rdpdr!DrOnSessionDisconnect+0x10a
    ffffd000`21ad82d0 fffff801`77e4c474 : 00001ffe`531bca00 ffffe001`b5a55af0 ffffe001`dc2ca370 ffffe001`acd4e040 : rdpdr!DrDevFcbXXXControlFile+0x3cb
    ffffd000`21ad8350 fffff801`77e325b2 : 00000000`0024a463 ffffe001`dc2ca4d0 0000000c`00000003 ffffd000`00000002 : rdbss!RxXXXControlFileCallthru+0xe4
    ffffd000`21ad8390 fffff801`77e01cea : ffffe001`dc2ca370 ffffe001`acd4e040 ffffe001`b5a55af0 ffffe001`dc2ca370 : rdbss!RxCommonDevFCBIoCtl+0x1c2
    ffffd000`21ad8400 fffff801`77e3228d : 00000000`00000000 00000000`00000000 00000000`00000000 fffff801`a9a1a7bc : rdbss!RxFsdCommonDispatch+0x4fa
    ffffd000`21ad8580 fffff801`793bb175 : ffffc000`c2aef6e0 00000000`00000000 fffff801`793b7010 00000000`00000000 : rdbss!RxFsdDispatch+0xed
    ffffd000`21ad85f0 fffff801`785d64c5 : ffffe001`ace6f410 ffffe001`accf2da0 ffffe001`dc2ca370 ffffe001`acd3e0c0 : rdpdr!DrPeekDispatch+0x175
    ffffd000`21ad86a0 fffff801`785d66a2 : ffffc000`beb27800 fffff801`785cd000 00000000`00000000 ffffe001`a9b835e0 : mup!MupiCallUncProvider+0x1b5
    ffffd000`21ad8710 fffff801`785d6283 : 00000000`00000000 ffffe001`a9abd140 ffffe001`dc2ca370 ffffd000`21ad87b8 : mup!MupStateMachine+0xd2
    ffffd000`21ad8750 fffff801`77201101 : ffffe001`a9b835e0 ffffe001`ace6f410 ffffd000`21ad8891 00000000`00000000 : mup!MupFsdIrpPassThrough+0x93
    ffffd000`21ad87b0 fffff801`a9a9f0af : 00000000`00000002 ffffd000`21ad8891 ffffe001`acd49240 0000001e`0012019f : fltmgr!FltpDispatch+0xf1
    ffffd000`21ad8810 fffff801`a9aa0018 : ffffe001`acd49204 ffffe001`acd49240 ffffe001`ad23dcf0 ffffe001`acd49240 : nt!IopSynchronousServiceTail+0x32b
    ffffd000`21ad88e0 fffff801`a9a6f8a6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0xdb8
    ffffd000`21ad8a20 fffff801`a976a2e3 : ffffe001`aac52080 ffffd000`21ad8b80 ffffd000`21ad8aa8 00000080`00000000 : nt!NtDeviceIoControlFile+0x56
    ffffd000`21ad8a90 00007ffa`6f8907ca : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
    00000080`59f3f048 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffa`6f8907ca


    THREAD_SHA1_HASH_MOD_FUNC:  e1ce6ed0bf513f181d08908207c6e07b67c8f42e

    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  c693ceced8fd2be46825ba21ba3d4d2b1bf56582

    THREAD_SHA1_HASH_MOD:  3fdd3014925fc94f4dfb43f0a49896e787e5c4c4

    FOLLOWUP_IP: 
    rdbss!__RxAcquireFcb+e7
    fffff801`77e33a67 440fb6f0        movzx   r14d,al

    FAULT_INSTR_CODE:  f0b60f44

    SYMBOL_STACK_INDEX:  5

    SYMBOL_NAME:  rdbss!__RxAcquireFcb+e7

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: rdbss

    IMAGE_NAME:  rdbss.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  5a4b1af3

    IMAGE_VERSION:  6.3.9600.18895

    STACK_COMMAND:  .thread ; .cxr ; kb

    BUCKET_ID_FUNC_OFFSET:  e7

    FAILURE_BUCKET_ID:  0x18_rdbss!__RxAcquireFcb

    BUCKET_ID:  0x18_rdbss!__RxAcquireFcb

    PRIMARY_PROBLEM_CLASS:  0x18_rdbss!__RxAcquireFcb

    TARGET_TIME:  2019-09-03T21:57:18.000Z

    OSBUILD:  9600

    OSSERVICEPACK:  19395

    SERVICEPACK_NUMBER: 0

    OS_REVISION: 0

    SUITE_MASK:  16

    PRODUCT_TYPE:  3

    OSPLATFORM_TYPE:  x64

    OSNAME:  Windows 8.1

    OSEDITION:  Windows 8.1 Server TerminalServer

    OS_LOCALE:  

    USER_LCID:  0

    OSBUILD_TIMESTAMP:  2019-06-06 11:46:22

    BUILDDATESTAMP_STR:  190606-0600

    BUILDLAB_STR:  winblue_ltsb

    BUILDOSVER_STR:  6.3.9600.19395.amd64fre.winblue_ltsb.190606-0600

    ANALYSIS_SESSION_ELAPSED_TIME:  bbf

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:0x18_rdbss!__rxacquirefcb

    FAILURE_ID_HASH:  {e2688e42-1abf-a0e7-2a21-11e57f3c2a16}

    Followup:     MachineOwner
    ---------

    3: kd> !object ffffe001da20d080
    GetUlongFromAddress: unable to read from fffff801a9968010
    Could not read ObjectType address
    3: kd> !irp ffffe001da20d080
    Irp is active with 0 stacks 0 is current (= 0xffffe001c35fc900)
     Mdl=ffffe001da20d088: No System Buffer: Thread ffffe001da20d118:  Irp stack trace.  
         cmd  flg cl Device   File     Completion-Context

    Irp Extension present at 0x000001:
    3: kd> !thread ffffe001da20d118
    GetPointerFromAddress: unable to read from fffff801a9968000
    ffffe001da20d118 is not a thread object, interpreting as stack value...
    Unable to read @ fffff801a98c4340
    TYPE mismatch for thread object at ffffe001da20d118

    • Propuesto como respuesta Pablo RubioModerator viernes, 13 de septiembre de 2019 20:46
    • Votado como útil Jonathan_PP martes, 17 de septiembre de 2019 20:43
    viernes, 13 de septiembre de 2019 16:09
  • Esta ya es otra canción. Aunque el .dmp apunta a un componente y un servicio de Windows ya hay reportes recientes de este error y sobre quien esta detrás.

    El driver de Windows: rdbss.sys

    El servicio: Rx Acquire Fcb

    En el foro en ingles encontré varios hilos al respecto, el que me parece mas relevante es este:

    RDS Servers Events 7011, 7046 - BSOD rdbss.sys
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/86f3ca6b-f780-4618-a595-9818ab36bb4b/rds-servers-events-7011-7046-bsod-rdbsssys?forum=winserverTS

    La solución la encontró el mismo usuario que inicio el hilo, Tee-Eff. El escenario es similar, el sistema esta instalado en una maquina virtual de VMWare. Al parecer esta relacionado con Acrobat Reader (¿Cuando funcionara bien esta cosa?) De modo que con la el cambio en la configuración de Acrobat o la modificación del registro que propone el problema debería estar resuelto:


    Saludos cordiales. Ivan

    • Marcado como respuesta Jonathan_PP jueves, 19 de septiembre de 2019 14:25
    domingo, 15 de septiembre de 2019 16:41
  • Hola IvanCG muchas gracias por la respuesta.

    Efectivamente todos los servidores de la granja tienen la versión de Acrobat Reader mencionada, ya realicé el procedimiento sobre el registro de todos los servidores, voy a dejar en prueba unos días. 

    Estaré escribiendo nuevamente de ser solucionado el inconveniente o si se vuelve a presentar,

    Saludos.

    martes, 17 de septiembre de 2019 20:41
  • Hola a todos.

    Efectivamente llevo 3 días sin reinicio en los servidores, por lo cual asumo que el problema era con el Acrobat Reader, (Que pesadilla).

    Muchas gracias a todos por la atención y ayuda.

    jueves, 19 de septiembre de 2019 14:27
  • Hola a todos.

    Efectivamente llevo 3 días sin reinicio en los servidores, por lo cual asumo que el problema era con el Acrobat Reader, (Que pesadilla).

    Muchas gracias a todos por la atención y ayuda.

    Me alegra de veras.

    La pena es que las alternativas al Acrobat padecen de los mismos problemas y casi los mismos agujeros de seguridad, La lista de vulnerabilidades de Foxit Reader,el mejorcito de esos,es para marearse.


    Saludos cordiales. Ivan

    jueves, 19 de septiembre de 2019 16:23