The BSOD SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (CVhdMp.sys) is seen when booting up a VM in PVS using an App Layering image.

It is also possible to just simply get a BSOD with a Stop Code of 0x0000007B. However, this is fairly generic. If you see this stop code and "ERROR: BNIStack failed, network stack could not be initialized" then this solution likely will apply. This message may not be seen on the same BSOD. It could come up on a following boot up and can be seen with a black screen instead of a blue screen. The key point here is, if you see the BNI Stack message at all during a bootup, then this solution may apply.

The issue seems to be regarding the PVS template, the OS/Platform layer, or both.

Solution 1

The first scenario that was seen for this issue is outlined in Jira UNI-45882. The issue here is related to PVS requiring the VMXnet3 NIC to be in the correct PCI slot address of 192 on the PVS template. A PVS template is simply a VM in vSphere that is a VMware template. Any VM can be used for this but some of the known requirements are as follows. It must have a VMXnet3 NIC as PVS does not support E1000 and is very sensitive to VM's that have had an E1000 assigned. The NIC must be using PCI address 192 and the SCSI controller should be on 160. To check this please have the template VM powered down (you may need to convert the template VM back to a normal VM first). Then select Edit Settings > Options > General > Configuration. The ethernet0.pciSlotNumber should be 192 and scsi0.pciSlotNumber should be 160. If you do not see the SCSI line then add a SCSI device and select a CD as that device to the VM and power it on. It will boot to the PXE boot screen, just power it down at that point. You should now have an SCSI controller and see the configuration entries with the correct numbers. Make this VM a template again and the image should boot (there are a few other steps in PVS that I do not have documented but the customer should know how to apply the new template and boot from the Unidesk image).

Solution 2

In this case, the customer had two NICs in their PVS template. This is one of many valid PVS configurations. The first NIC is used for the PXE boot and likely will not have any additional network access beyond that. The second is for general data and should be used the same as your standard NIC when accessing the network. The template may still need to be modified per solution 1 before the image will boot.

The customer reported the following got them up and running:

1. Created a new OS version. Booted the packaging VM and checked the NIC. Only one present but was connected to data vLAN, not PVS. Edited VM settings so this NIC was connected to PVS streaming LAN. 
2. Shut down VM. Checked config parameters to see ensure the ethernet0 was at pci192. It was.
3. Booted VM. Clicked finalize.
4. Finalised OS layer on ELM.
5. Repeated steps 2-4 on platform layer that contains VDA and PVS drivers.
6. Created a new template with OS new layer.
7. Published to PVS with new platform layers.
8. I didn't have any PVS targets so I ran XenDesktop Setup Wizard to create a target. After initial automatic boot and shutdown to format the write cache I started VM and it booted.
9. Logged in successfully and checked build. All components present and both NICs present and connected correctly.

NOTES:

I have a feeling you do not need to create a new OS layer as he did in step 1. Likely you only need to add a version to the platform layer and make the vLAN changes as he outlined. Our code is doing a lot in the platform layer regarding NIC merge and Unidesk 4 OS layers should be platform agnostic. Unidesk as of 4.0.3 and for the foreseeable future, by design, will only provide you with a single NIC when editing a layer. This is fine. The key seems to be that the packaging machine for the platform layer must have the "data" vLAN set and not the PVS PXE boot vLAN.

Solution 3

Make sure the hypervisor tools are installed and working.  Check device manager and confirm the active NIC is the correct NIC.  If you see a 3rd party NIC like Realtek or Intel instead of Xen PV device or VMXNet3, then the tools are not installed/working. Having the wrong NIC will cause this BSOD. 

Solution 4

If the above solutions do not work, another option is to publish the image to your hypervisor and then use the PVS imaging wizard to upload the image to PVS.     
 

The BSOD SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (CVhdMp.sys) is seen when booting up a VM in PVS using a App Layering image.