rlsxr, we've warned everyone that the VM may not boot, but not necessarily will not. The problem is that when Windows boots it selects one of the standard supported video modes. After we initialize our video driver, Windows keeps refreshing image using its own frame buffer, and then copies it to ours. The function responsible for copying (dxgkrnl!PresentCddShadowBuffer) has several branches, where one is being selected according to both original and resulting frame buffer. There are changes in Windows 10 Creators Update in the logic responsible for copying an image from 24 to 32 bit buffer, which may results in system crash (BSoD) depending on the VM image size and view mode. I can give you more technical details about it, but I think it's not practically useful. What you say about nested virtualization indeed sounds concerning. Can you please send us technical data reports so we try to reproduce it with the same hardware and settings? Please send us two reports at the time of issue reproduction: one with disabled nested virtualization and one with enabled option. I personally will be very grateful to you! JK_1, you've also mentioned that the same workaround helped you. Can you please also send us reports? Please share the report IDs with me here.