New native NVMe driver in Windows 25H2
4 posts
I don't know if this can somehow improve RAMDisk speeds even more in terms of IOPS, but there is a new native NVMe driver in Windows 25H2.
I noticed in Device Manager events tab this entry "Device ROOT\SCSIADAPTER\0000 was configured", which may be somehow related to older and slower SCSI drivers. But I don't know how this works with RAMDisk, so I'm just letting you know. :-)
Thanks for the suggestion! We've looked into the new Native NVMe feature in Windows Server 2025 and so far it looks like it won't benefit RAM Disk.
The native NVMe driver (nvmedisk.sys) is designed specifically for physical NVMe SSDs. It eliminates the SCSI translation layer that Windows previously used when communicating with NVMe hardware, resulting in lower latency and higher IOPS for those devices.
RAM Disk doesn't use NVMe or SCSI protocols for its direct I/O volumes. Instead, it handles read/write requests directly through memory operations, which is already the most efficient path possible in Windows. There's no protocol translation overhead to eliminate. The SCSI device you mentioned is only used when Hard Disk Emulation is enabled.
In essence, the native NVMe feature solves a bottleneck that doesn't exist for RAM disks — we're already operating at pure memory speed without any storage protocol in the way.
Would this be of benefit if it were used with the HDD emulation, so instead of using SCSI it is using the NVME instead? As of right now, I have an application I must run with HDD emulation enabled, and wouldn't mind a speed boost if it was possible.
Unfortunately, this isn't something we can take advantage of. Microsoft's Native NVMe stack is designed exclusively for real physical NVMe hardware — it talks directly to PCIe controllers and doesn't provide any interface for virtual or software-defined devices like a RAM disk. There is simply no way to plug into it.
Our driver uses SCSI emulation because that's the only model Windows offers for creating virtual disk devices, and this isn't likely to change any time soon. The good news is that the SCSI layer adds negligible overhead in our case — since there's no actual hardware involved, the SCSI commands are handled directly in memory without any real translation cost. The bottleneck, if any, would be memory bandwidth, not the SCSI abstraction.