Eu uso o Citrix XenServer 5.5 e em um Windows Server 2008 R2 Guest está instalado o Xentools 5.5, por um ano tudo funciona bem. Após a reinicialização, obtemos um BSOD com Stop Code 7B, acho que é um problema com o driver Citrix pv, mas como posso excluir esse driver sem GUI, o modo de segurança também abre um BSOD.
Então instalo um segundo Windows Server na mesma VM e posso acessar o sistema de arquivos do Guest. No Windows/System32/driver eu apago xenvbd.sys e scsifilt.sys no registro apago tudo que encontrei com xenvbd ou scsifilt, mas o BSOD ainda está aqui.
A ajuda do Windows Startuprepair e sfc /scannow dosent.
Atualizar: Todos os instantâneos conhecidos apresentam o mesmo problema
Responder1
Restaure o servidor a partir de um backup em bom estado.
Responder2
Se você instalar o driver Xen PV em um convidado e obtiver o BSOD com parada 7B, é possível que o driver esteja corrompido ou alguns arquivos estejam faltando. Primeiro você deve descobrir a versão do driver: vá para o sistema de arquivos e obtenha as propriedades de - por exemplo - xenvbd.sys, em seguida, vá para o disco de instalação do XenTools e procure os seguintes arquivos:
xenutil.sys
xenvtchn.sys
xenvbd.sys
scsifilt.sys
Depois de copiar esses arquivos para Windows\System32\Drivers\ você pode iniciar seu Guest no modo de segurança. Agora você pode instalar uma versão mais recente do Xentools no modo de segurança (você encontra um arquivo de instalação no Xentools que funciona também no modo de segurança) e obterá alguns erros. Não reinicie seu servidor. Desinstale este programa agora e uma limpeza será iniciada, todos os arquivos e entradas de registro corrompidos ou ausentes serão excluídos e limparão sua instalação.
Agora reinicie e funciona!
Responder3
Estou feliz que o problema tenha sido resolvido e estou votando positivamente na pergunta. Não porque a solução tenha algum valor redentor para outros, mas devido a isso deveria servir como um conto de advertência.
Há duas coisas que não deveriam ter ocorrido.
Primeiro, 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 funcionem conforme o esperado após uma reinicialização.
Segundo, “testar” a mudança em um sistema semelhante ou em uma cópia única frequentemente identifica esses tipos de problemas.
O número dois pode não ter sido diretamente relevante neste cenário, mas é frequentemente relevante em ambientes onde o número um está ausente.
Eu especularia que o sistema pode ter funcionado bem se reiniciado após a alteração inicial, mas algo aconteceu no ano que aconteceu.
É por isso que quando me envolvo em uma atividade que inclui uma modificação do sistema, meu primeiro passo é reiniciar o servidor para garantir que, se houver algum problema como esse, ele não esteja relacionado ao que estou fazendo.