none
WINDOWS 2000 SERVER CON PANTALLAZO AZUL AL CERRAR SESION TERMINAL SERVER --- SESSION_HAS_VALID_VIEWS_ON_EXIT RRS feed

  • Pregunta

  • HOLA TENGO UN PROBLEMA , CUANDO LOS USUARIOS DE TERMINAL SERVER CIERRAN SESION, EL SERVIDOR DA UNA PANTALLAZO AZUL QUE PONE SESSION_HAS_VALID_VIEWS_ON_EXIT 0X000000BA.

    Tengo WINDOWS 2000 SERVER ORIGINAL instalado con sus respectivas licencias de terminal server originales.

    El tema es que todo iba bien hasta hace 2 semanas que ha empezado a fallar de repente.

    El problema es aleatorio, a veces no pasa y otras muchas si.

    No se que hacer, he leido en muchos foros y no doy con el problema.

    Para este problema he leido que hay un hotfix para windows 2003 server y lo resuelve, el problema es que tengo windows 2000 server

    Por lo que he leido en algun foro dice que puede ser de algun controlador ( grafica, printer ), el tema es que no se ha hecho nada y ademas esta virtualizado con vmware y los drivers que tiene son de vmware tools para windows 2000.

    y ha estado funcionando bien un monton de tiempo.

    Sabeis si hay algun parche o solucion para erradicar el problema?

    Estoy desesperado ya que microsoft no me da soporte telefonico porque esta obsoleto y eso que tengo todo original y no puedo formatear el server.

    Por favor AYUDA.

    lunes, 21 de abril de 2014 11:09

Respuestas

  • Ciertamente Windows 2000 es demasiado antiguo. Habría que obtener un volcado de memoria del kernel para intentar analizarlo (un minidump puede resultar insuficiente). Un fallo SESSION_HAS_VALID_VIEWS_ON_EXIT implica que un controlador no ha liberado todas las vistas de archivos mapeados en memoria al finalizar la sesión. ¿Seguro que no ha habido algún movimiento reciente en relación con controladores de impresora, por ejemplo?

    Por lo pronto, en Inicio, Configuración, Panel de control, Sistema, pestaña Avanzado, Inicio y recuperación, debería estar configurado el volcado de memoria del kernel en %SystemRoot%\MEMORY.DMP (%SystemRoot% representaría en este caso la ruta C:\WINNT). Si no existiera ya el archivo Memory.dmp en C:\WINNT con una fecha reciente, habría que esperar a que se volviera a producir el fallo.

    Probablemente las versiones más recientes de las herramientas de depuración de Windows ya no sean compatibles con sistemas Windows 2000, ni siquiera para el análisis de volcados de memoria. El SDK de Windows 7 incluye la versión 6.12.2.633 que sí puede depurar Windows 2000, pero el programa de instalación del SDK requiere Windows XP o posterior. Por tanto, veo tres opciones:

    • ejecutar la instalación del SDK de Windows 7 en otro equipo con al menos Windows XP y conexión a Internet activa, marcando solamente el componente Debugging Tools for Windows, y trasladar allí el volcado Memory.dmp para analizarlo.
    • descargar e instalar a a mano en el sistema Windows 2000 el paquete MSI de los depuradores de Microsoft, ya que es compatible. El SDK de Windows 7 lo obtiene de la siguiente ruta:
      http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebugToolsRedist/cab1.cab
      Se debe extraer del archivo cab1.cab el fichero WinSDK_debuggingtools_x86_msi_FL y añadirle la extensión .msi para poder ejecutarlo.
    • enviar el archivo Memory.dmp, comprimido, a un servicio de alojamiento de archivos como Dropbox, OneDrive, Google Drive, etc., y compartir un enlace público de descarga. El espacio de memoria del kernel de un servidor podría contener alguna información comprometedora, aunque es difícil saberlo a ciencia cierta.

    Desconozco cómo se depura un fallo del tipo SESSION_HAS_VALID_VIEWS_ON_EXIT, pero he encontrado algunas pistas en un artículo de asistencia de HP. Suponiendo que esté configurado el entorno de depuración Windbg correctamente, la consabida orden !analyze -v no va a suponer un gran avance. En el resumen del informe de error, el tercer argumento (Arg3) es importante. También se puede obtener con la orden .bugcheck, siendo el penúltimo número. Habría que explorar esa zona de memoria con dc (seguido del tercer argumento, como en dc 987654f0, por ejemplo) y buscar valores que parezcan direcciones del kernel, superiores a 8000000 hexadecimal y además acabando en 0, 4, 8 o C (alineadas a 4 bytes, 32 bits). Entonces, para cada dirección encontrada, se usa la orden !ca seguida de la misma (por ejemplo, !ca 873b1fac). Entre la información técnica debería mostrarse el nombre y la ubicación del archivo mapeado, permitiendo conjeturar alguna hipótesis.

    Si los nombres y las rutas de los archivos "mapeados" sugieren archivos de controladores de impresora, convendría relacionarlos con la información de la clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers.


    No puedo garantizar a priori que mis respuestas sean exactas y acordes a los problemas descritos, pero por lo menos yo no las voy marcando como propuestas o definitivas sin saber si han sido útiles o no. Sobre todo no me gusta que lo hagan los moderadores. Tampoco vinculado a Microsoft.

    • Propuesto como respuesta Uriel Almendra lunes, 21 de abril de 2014 17:58
    • Marcado como respuesta Uriel Almendra martes, 22 de abril de 2014 13:15
    lunes, 21 de abril de 2014 17:32