virtualbox.org

The NVMe emulation of VirtualBox 5.1.4 is apparently not yet compatible with the generic Windows 10 NVMe driver (stornvme.sys).

Steps to reproduce (Test host was Windows 10 Pro 1511 x64):
- Select some existing VM with Windows 10 (x64) guest.
- Add new virtual NVMe controller.
- Add one SSD to this controller.
- Boot the guest.

Result: The Windows guest freezes during boot screen. Same happens if only the NVMe controller is added, but no disk.

The build of the Windows 10 guest does not matter. Problem could be reproduced with 1507, 1511 and 1607.

Booting some recent Linux Live CD/DVD in the same VM works. The /dev/nvme0{,n1} nodes appear and could be accessed. Running "smartctl -x /dev/nvme0" also works, but occasionally returns bogus info when reading the NVMe SMART or Error Log.

Thanks for any help.

Thanks for the report, should be fixed in the next maintenance release. Please try a testbuild from https://www.virtualbox.org/wiki/Testbuilds.

Problem persists with test build 5.1.x revision 110927.

Please attach a VBox.log from a run with the testbuild.

After changing number of virtual CPUs from 1 to 2 (or more), Win 10 boots successfully. The virtual NVMe SSD works as expected then.

Interestingly the boot freeze could not be reproduced if #CPUs is turned back to 1 after the first boot with NVMe disk. Possibly some subtle timing problem when stornvme.sys is still unconfigured.

Thanks für the feedback, too bad you can't reproduce the hang with a single core anymore.

The freeze could be reproduced by restoring the snapshot which was taken after adding the NVMe SSD. Here the results in detail (Win10-1607, snapshots at 'X'):

shutdown -s --X--> Add NVMe Ctrl+SSD --X--> Add CPU --> Boot OK --> shutdown -s --> Remove CPU --> Boot OK(!) --> ...
              |                        +--------------> Boot freeze (see attached log)
              +---------------------------------------> Boot OK --> ...

Freeze occurred before log reports "Guest seems to be unresponsive".

Meantime I found another method to prevent the boot freeze without adding another CPU: Change the start type of the stornvme.sys driver from "demand" to "boot" before adding the NVMe controller:

C:\> sc qc stornvme
...
        TYPE               : 1  KERNEL_DRIVER
        START_TYPE         : 3   DEMAND_START
...
C:\> sc config stornvme start= boot
...
C:\> sc qc stornvme
...
        START_TYPE         : 0   BOOT_START
...
C:\> shutdown -s

There is possibly some problem in Windows itself when the driver is enabled after initial boot phase and only one CPU is present. Such a problem would possibly never occur on real hardware because single core machines are very rare now...