Como desinstalar todos os drivers Citrix do Windows Server 2008 R2 Guest se o BSOD estiver no modo de segurança?

Question

Eu uso o Citrix XenServer 5.5 e em um Windows Server 2008 R2 Guest há o Xentools 5.5 instalado, por um ano tudo funciona bem. Depois de um reinício, recebemos um BSOD com Stop Code 7B, é um problema com o Citrix pv-driver eu acho, mas como posso excluir este driver sem GUI, modo de segurança também trazer um BSOD.

Então eu instalo um segundo Windows Server na mesma VM e posso acessar o sistema de arquivos do Visitante. No Windows / System32 / driver eu excluir xenvbd.sys e scsifilt.sys no registro eu apago tudo que encontrei com xenvbd ou scsifilt, mas o BSOD ainda está aqui.

O Windows Startuprepair e o auxílio sfc / scannow ajudam.

Atualização: Todos os instantâneos conhecidos estão com o mesmo problema

    

Answer 1

Se você instalar o driver PV do Xen em um convidado e obtiver o BSOD com a parada 7B, é possível que o driver esteja corrompido ou que alguns arquivos estejam faltando. Primeiro você deve descobrir a versão do driver: vá para o sistema de arquivos e obtenha propriedades de - por exemplo - xenvbd.sys, em seguida, vá para o seu XenTools Installdisk e procure os seguintes arquivos:

xenutil.sys
xenvtchn.sys
xenvbd.sys
scsifilt.sys

Depois de copiar esses arquivos para o Windows \ System32 \ Drivers \, você pode iniciar seu Guest no modo de segurança. Agora você pode instalar uma versão mais recente do Xentools a partir do modo de segurança (você encontrará um arquivo de instalação no Xentools que também funciona no modo de segurança) e você obterá alguns erros. Não reinicie seu servidor. Deinstall este programa agora e uma limpeza será iniciado, todos os arquivos corrompidos ou ausentes e entradas do Registro irá excluir e limpar sua instalação.

Agora reinicie e funcione!

    

Answer 2

Restaurar o servidor a partir de um backup válido conhecido.

    

Answer 3

Fico feliz que o problema tenha sido resolvido e estou fazendo a pergunta. Não porque a solução seria de qualquer valor redentor para os outros, mas devido a isso deve servir como um conto preventivo.

Existem duas coisas que não deveriam ter ocorrido.

Um, as alterações do sistema que modificam os arquivos do sistema ou as configurações do registro devem ser validadas, e essa validação deve incluir que o sistema e a alteração tenham o desempenho esperado após a reinicialização.

Dois, "testando" a alteração em um sistema semelhante ou em uma cópia única freqüentemente identificam esses tipos de problemas.

O número dois pode não ter sido diretamente relevante neste cenário, mas é freqüentemente relevante em ambientes onde o número um está faltando.

Eu especularia que o sistema pode ter funcionado bem se reiniciado após a mudança inicial, mas algo aconteceu no ano que aconteceu.

É por isso que quando me envolvo em uma atividade que inclui uma modificação no sistema, meu primeiro passo é reiniciar o servidor para garantir que, se houver algum problema como esse, eles não estejam vinculados ao que estou fazendo.