I use Citrix XenServer 5.5 and on a Windows Server 2008 R2 Guest there is installed Xentools 5.5, for a year all works well. After a restart we get a BSOD with Stop Code 7B, it is a problem with the Citrix pv-driver I think, but how can I delete this driver without GUI, safe mode also bring up a BSOD.
So I install a second Windows Server on same VM and can access the filesystem of the Guest. In the Windows/System32/driver I delete xenvbd.sys and scsifilt.sys in the registry I delete everything I found with xenvbd or scsifilt, but the BSOD is still here.
The Windows Startuprepair and sfc /scannow dosent help.
Update: All known Snapshots are with the same Issue
Restore the server from a known good backup.
If you install the Xen PV driver on a guest and you get the BSOD with stop 7B it is possible that the driver is corrupt or some files are missing. First you should find out the version of the driver: go to filesystem and get properties of - for example - xenvbd.sys then go to your XenTools Installdisk and search for the following Files:
After copy this files to Windows\System32\Drivers\ you can start your Guest in safe mode. Now you can install a newer version of the Xentools from safemode (you find a install file on Xentools that works also in safemode) and you will get some errors. Don't reboot your server. Deinstall this Programm now and a cleanup will starts, all corrupt or missing files and registry Entries will delete and cleanup your installation.
Now reboot and it works!
I'm glad the problem is resolved, and I'm upvoting the question. Not because the solution would be of any redeeming value to others, but due to this should serve as a cautionary tale.
There are two things that should not have occurred.
One, system changes that modify system files or registry settings should be validated, and that validation should include that the system and the change performs as expected after a restart.
Two, "testing" the change on a similar system or a one-off copy frequently identifies these types of issues.
Number two may not have been directly relevant in this scenario, but is frequently relevant in environments where numer one is lacking.
I would speculate that the system may have worked fine if restarted after the initial change, but something was whacked in the year that transpired.
This is why when I get involved in an activity that includes a system modification, my first step is to restart the server to ensure that if there are any issues like this, they aren't linked to what I am doing.