STOP c00002e2 after changing SCSI Controller to PVSCSI

Today I changed the SCSI controller type for my Windows VMs in my lab from LSI SAS to PVSCSI. Because the VMs were installed with LSI SAS, I used the procedure described in VMware KB1010398 (Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters) to change the SCSI controller type. The main problem is, that Windows doesn’t have a driver for the PVSCSI installed. You can force the installation of the driver using this procedure (taken from KB1010398):

1. Power off the virtual machine.
2. Create a new temporary 1GB disk(SCSI 1:0) and assign a new SCSI controller (default is LSI LOGIC SAS).
3. Change the new SCSI controller to PVSCSI for the new SCSI controller.
4. Click Change Type.
5. Click VMware Paravirtual and click OK.
6. Click OK to exit the Virtual Machine Properties dialog.
7. Power on the virtual machine.
8. Verify the new disk was found and is visible in Disk Management. This confirms the PVSCSI driver is now installed.
9. Power off the virtual machine.
10. Delete the temporary 1GB vmdk disk and associated controller (SCSI 1:0).
11. Change the original SCSI controller(SCSI 0:X) to PVSCSI as detailed in Steps 3 to 5.
12. Power on the virtual machine.

Please note, that this change is not a supported method to change the controller type. Usually you should install a server with disks already attached to a PVSCSI controller.

The problem

I changed the controller type for a couple of VMs using the above described method. This worked really fine until I changed the controller type of my Domain Controller. The DC failed to boot with the new controller. I changed the controller type back to LSI SAS and the VM started without problems. A change in the type of controller led to another BSoD (Blue Screen of Death). But it was not the usual STOP 0x0000007B.

STOP: c00002e2 Directory Services could not start because of the following error:

A device attached to the system is not functioning.

Error Status: 0xc000000f. Please shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.

Something new… I booted into Directory Services Restore Mode (DSRM) and logged in with my directory services restore mode password (I hope you remember your password…).

I checked the disks and found my SYSVOL volume offline.

I usually let DCPROMO install the NTDS and SYSVOL onto a separate drive instead using the system volume. In my case this drive was offline! This causes that Windows failed to start.

The solution

The solution was simple: Bring the volume online and reboot the VM.

Windows started without problems and the AD was also okay.

Final words

I think it’s clear, that you can’t replace the controller type without additional steps. And it should also be clear, that changing the controller type isn’t a good idea until you’re really know what you’re doing. I also think that it’s unsupported to change the controller type (but I haven’t found a statement if it’s supported or not). I did this a couple of times and I never had problem with the above described procedure. In this case, the problem is related to the controller type change. The cause for the BSoD was the offline NTDS/ SYSVOL volume. Bringing the volume online in DSRM solved the problem.