PVS targets give a blue screen error code 7B when on Xenserver 6.1 or later hypervisor.

Note the VM's unique identifier (UUID): in XenCenter, select the VM in the left-hand tree view. Click the General tab and record the UUID shown. You can also obtain this by using the xe vm-list command.
Modify the VM's device_id parameter: on the XenServer host's console, type one of the following commands:

xe vm-param-remove uuid=<VM UUID> param-name=platform param-key=device_id

or,

xe vm-param-set uuid=<vm_uuid> platform:device_id=0001

or,

xe vm-param-set uuid=<vm_uuid> platform:device_id=0002

---

Problem Cause

XenServer has a PV disk, and this disk is known by the system to be sitting on a piece of (virtual) hardware with a device_id of 0002. 
If you delete the device_id configuration (essentially setting it to 0001) after the reboot, there is a new piece of virtual hardware, 0001 (which won't have anything installed on it because the system hasn't booted yet) 
The place where windows expects to find the disk (0002) has gone missing (specifically in your scenario) . 
Which means Windows can't continue to boot up (and so the drivers can't reinstall onto device 0001) [and you get the 7B bluescreen]
-This is basically xentools behavior
-Xenbus is the driver which handles it
So, removing the device_id will help xenbus to boot with expected device_id field which lets the windows to boot properly without any issues .
 
The device_id value of a VM determines how certain hardware is emulated and presented the VM.  Changing the device_id will result in different devices being reported in lscpci (Linux VMs) and Device Manager (Windows VMs).


So, in this case , the hardware was being emulated and presented to the VM incorrectly even though the VM definition was the same .

PVS targets give a Blue screen error code 7B when on Xenserver 6.1 or later hypervisor.