Ich verwende Citrix XenServer 5.5 und auf einem Windows Server 2008 R2-Gast ist Xentools 5.5 installiert, seit einem Jahr funktioniert alles gut. Nach einem Neustart erhalten wir einen BSOD mit Stoppcode 7B, ich denke, es liegt ein Problem mit dem Citrix PV-Treiber vor, aber wie kann ich diesen Treiber ohne GUI löschen, der abgesicherte Modus bringt auch einen BSOD.
Also installiere ich einen zweiten Windows-Server auf derselben VM und kann auf das Dateisystem des Gasts zugreifen. Unter Windows/System32/Treiber lösche ich xenvbd.sys und scsifilt.sys in der Registrierung. Ich lösche alles, was ich mit xenvbd oder scsifilt gefunden habe, aber der BSOD ist immer noch da.
Die Windows-Startup-Reparatur und sfc /scannow helfen nicht.
Aktualisieren: Alle bekannten Snapshots haben das gleiche Problem
Antwort1
Stellen Sie den Server aus einer bekanntermaßen funktionierenden Sicherung wieder her.
Antwort2
Wenn Sie den Xen PV-Treiber auf einem Gast installieren und der BSOD mit Stopp 7B auftritt, ist der Treiber möglicherweise beschädigt oder es fehlen einige Dateien. Zuerst sollten Sie die Version des Treibers herausfinden: Gehen Sie zum Dateisystem und rufen Sie die Eigenschaften von – beispielsweise – xenvbd.sys auf. Gehen Sie dann zu Ihrer XenTools-Installationsdiskette und suchen Sie nach den folgenden Dateien:
xenutil.sys
xenvtchn.sys
xenvbd.sys
scsifilt.sys
Nachdem Sie diese Dateien nach Windows\System32\Drivers\ kopiert haben, können Sie Ihren Gast im abgesicherten Modus starten. Jetzt können Sie eine neuere Version der Xentools aus dem abgesicherten Modus installieren (Sie finden eine Installationsdatei auf Xentools, die auch im abgesicherten Modus funktioniert) und Sie werden einige Fehlermeldungen erhalten. Starten Sie Ihren Server nicht neu. Deinstallieren Sie dieses Programm jetzt und eine Bereinigung wird gestartet, alle beschädigten oder fehlenden Dateien und Registrierungseinträge werden gelöscht und Ihre Installation bereinigt.
Jetzt neu starten und es funktioniert!
Antwort3
Ich bin froh, dass das Problem gelöst ist, und bewerte die Frage positiv. Nicht, weil die Lösung für andere von Nutzen wäre, sondern weil sie als warnendes Beispiel dienen sollte.
Es gibt zwei Dinge, die nicht hätten passieren dürfen.
Erstens sollten Systemänderungen, die Systemdateien oder Registrierungseinstellungen verändern, überprüft werden. Bei dieser Überprüfung sollte auch geprüft werden, ob das System und die Änderung nach einem Neustart wie erwartet funktionieren.
Zweitens werden Probleme dieser Art häufig dadurch identifiziert, dass man die Änderung auf einem ähnlichen System oder einer einmaligen Kopie „testet“.
Nummer zwei war in diesem Szenario möglicherweise nicht direkt relevant, ist jedoch häufig in Umgebungen relevant, in denen Nummer eins fehlt.
Ich würde vermuten, dass das System bei einem Neustart nach der ersten Änderung möglicherweise einwandfrei funktioniert hätte, aber in dem Jahr, in dem dies geschah, ist irgendetwas schiefgelaufen.
Wenn ich an einer Aktivität teilnehme, die eine Systemänderung beinhaltet, starte ich daher zuerst den Server neu, um sicherzustellen, dass etwaige Probleme dieser Art nicht mit meiner Tätigkeit zusammenhängen.