PVS image process gets BSOD on boot up

In this case, the problem was a mismatch of the vm parameters on the maintenance VM being used in the process. The maintenance vm was the one that the administrator always used historically for imaging and updating images. It was likely created before the Current Update (CU2 was applied).

You can verify if this is the issue affecting your imaging process:

From an SSH prompt on a Citrix Hypervisor host, collect the UUID of an old VM that you might be using. Remember when typing these commands, that xe is case sensitive.

This will return the UUID of the vm.

Then, query for the vm parameters like this:

Here is a sample out put from a lab machine:

xe vm-list name-label=WIN-Group-TD

uuid ( RO) : 6e3b4afc-7266-2f1d-b969-6b58e249f803

name-label ( RW): WIN-Group-TD

power-state ( RO): running

Then query for the vm parameters like this:

xe vm-param-get param-name=platform uuid=6e3b4afc-7266-2f1d-b969-6b58e249f803

timeoffset: -7443; device-model: qemu-upstream-compat; videoram: 8; hpet: true; acpi_laptop_slate: 1; secureboot: false; viridian_apic_assist: true; apic: true; device_id: 0002; cores-per-socket: 2; viridian_crash_ctl: true; pae: true; vga: std; nx: true; viridian_time_ref_count: true; viridian_stimer: true; viridian: true; acpi: 1; viridian_reference_tsc: true

Then perform the same steps for a NEW VM. Copy the results out to a text file so that you can carefully compare the outputs.

Keep an eye out for “secureboot: false”. This might be the cause of the BSOD when using an old VM.

If there is any difference, you mit find that you need to create new vm’s for imaging tasks, or possibly even for streaming if the old target devices are not working.