Utilizo Citrix XenServer 5.5 y en un Windows Server 2008 R2 Guest está instalado Xentools 5.5, durante un año todo funciona bien. Después de reiniciar, obtenemos un BSOD con código de parada 7B, creo que es un problema con el controlador Citrix pv, pero ¿cómo puedo eliminar este controlador sin GUI? El modo seguro también muestra un BSOD.
Entonces instalo un segundo servidor Windows en la misma máquina virtual y puedo acceder al sistema de archivos del invitado. En Windows/System32/driver elimino xenvbd.sys y scsifilt.sys en el registro. Elimino todo lo que encontré con xenvbd o scsifilt, pero el BSOD todavía está aquí.
La reparación de inicio de Windows y sfc /scannow dosent ayudan.
Actualizar: Todas las instantáneas conocidas tienen el mismo problema
Respuesta1
Restaure el servidor a partir de una copia de seguridad en buen estado.
Respuesta2
Si instala el controlador Xen PV en un invitado y obtiene el BSOD con parada 7B, es posible que el controlador esté dañado o que falten algunos archivos. Primero debe averiguar la versión del controlador: vaya al sistema de archivos y obtenga las propiedades de, por ejemplo, xenvbd.sys, luego vaya al disco de instalación de XenTools y busque los siguientes archivos:
xenutil.sys
xenvtchn.sys
xenvbd.sys
scsifilt.sys
Después de copiar estos archivos a Windows\System32\Drivers\, puede iniciar su Guest en modo seguro. Ahora puede instalar una versión más nueva de Xentools desde el modo seguro (encontrará un archivo de instalación en Xentools que también funciona en modo seguro) y obtendrá algunos errores. No reinicies tu servidor. Desinstale este programa ahora y se iniciará una limpieza; todos los archivos y entradas de registro corruptos o faltantes se eliminarán y limpiarán su instalación.
¡Ahora reinicia y funciona!
Respuesta3
Me alegro de que el problema se haya resuelto y estoy votando a favor de la pregunta. No porque la solución tenga algún valor redentor para otros, sino porque debería servir como advertencia.
Hay dos cosas que no deberían haber ocurrido.
Primero, los cambios del sistema que modifican los archivos del sistema o la configuración del registro deben validarse, y esa validación debe incluir que el sistema y el cambio funcionen como se espera después de un reinicio.
En segundo lugar, "probar" el cambio en un sistema similar o en una copia única identifica con frecuencia este tipo de problemas.
Es posible que el número dos no haya sido directamente relevante en este escenario, pero con frecuencia lo es en entornos donde falta el número uno.
Yo especularía que el sistema pudo haber funcionado bien si se reinició después del cambio inicial, pero algo se estropeó en el año que transcurrió.
Es por eso que cuando me involucro en una actividad que incluye una modificación del sistema, mi primer paso es reiniciar el servidor para asegurarme de que, si hay algún problema como este, no esté relacionado con lo que estoy haciendo.