"Driver initialisation failed" on one Dell machine with Gen8 CPU

I just upgraded my license from 1-user to 5-user, because I like your program enough to use it in more applications.

I'm having auto-startup problems, though:

1. I had an older version of v4 installed on my Gen13 Dell Optiplex running Win11 Pro x64. I upgraded to the latest version from your site today. Everything works perfectly.

2. I had the older version on a Gen12 Dell Optiplex to test it. Upgrading the version did not work, but completely uninstalling the old version, then re-installing the new version works.

3. I have a 3rd PC, a Gen8 Dell Optiplex Micro 5050. RAM Disk v4 installs OK, but it will not run from auto-start --

* When Windows starts, I get an error message on the display, "Driver initialisation failed." If I open the RAM Disk console, all items are greyed out. I cannot create a RAMdisk or do anything else until I exit the app and start it again.

* When I open the app after Windows is running, everything works perfectly, every time! This includes execution of a program listed in the Autorun area. The only downside is that RAM Disk remains maximized afterwards, requiring user intervention.

* I tried uninstalling, rebooting, and reinstalling the latest version of RAM Disk. This did NOT fix any problem; the error message still appears at each Windows start, and the RAM drive is not created.

* I tried creating an 'At Login' RAM disk (vs. At Startup). This did NOT fix the problem.

So, it seems that everything about your program works, but not automatically on Windows startup on this particular machine. Do you have any ideas of what could be happening? Is there a command line switch to open RAM Disk later, but close the UI?


I found a hack to get it to work for my situation, since the RAMdisk is not actually used immediately on boot:
1. I created a new RAMdrive as AtStartup.
2. I disabled the 'Launch automatically with Windows' option in Settings. (Your manual says this is not required for AtStartup disks, although it appears to launch the RAM Drive app.)
3. Since the app is no longer starting with Windows, the Applications feature no longer works. I created a batch file to copy the necessary data into the RAMdrive and added it to the Windows Startup folder.

I still would be interested in understanding what is going on here; and to test any fixes you might suggest. The RAM Disk app starts fine with my other machines, all of which are running Win11 Pro x64.

It seems that for some reason Windows initializes the RAM disk driver with a delay. Therefore, at the time you log in, it is not yet running, but it starts shortly afterward.

There are a couple of registry tweaks you could try. We will provide more details shortly.

Thank you for the prompt reply. Interesting about the delay: I took a look at the three different systems to look for major differences, and one thing that popped out to me was mulitthreading - or maybe more specifically, the lack of it on the Gen8 CPU. All three units are i5-class, but of course that varies between generations:
i5-13500T -- 14 CPUs (6 Power + 8 Efficiency), 20 threads
i5-12500T -- 6 CPUs, 12 threads
i5-8600 -- 6 CPUs, 6 threads (no multithreading)

Could RAM Disk be stuck in a queue at startup? I do have a number of startup tasks running.

Thanks for the additional information. Yes, a large number of startup tasks can be a factor here.

Here are two registry tweaks you could try:

1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SPVVEngine change the Start value from 2 to 1.
2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SPVDPort remove the Group parameter.

I would probably recommend doing (1) first and reboot. Then, if it's still not working as expected, try (2) and reboot again.

Please let us know how it works for you.

Fix #1 (change SPVVEngine start value) worked perfectly!
I can now select 'Open automatically with Windows,' and the RAM Disk applet starts without the initialisation error. I have also returned the startup tasks for the drive to the Applications list (vs. using a separate batch file). Thank you for your help.

Just curious: from a layman's point of view, what are we doing here? Does changing Start from 2 to 1 increase the task priority, or slow things down? It's at a point where the difference isn't even noticeable to the boot process; I'm just trying to better understand.

The possible values for Start are:

0 (SERVICE_BOOT_START)
The driver or service is loaded by the boot loader. This option is typically reserved for file system drivers, such as those required for the computer to access the boot volume.

1 (SERVICE_SYSTEM_START)
The driver or service is loaded during system initialization at the time of kernel initialization. This setting is used for drivers that are critical to the system's operation and must be loaded immediately after the boot loaders have completed their tasks.

2 (SERVICE_AUTO_START)
The driver or service is automatically started by the Service Control Manager during system startup. This is the default setting for many drivers and services that do not require immediate activation under the previous two conditions.

We believe some earlier versions of Windows 10 had a bug in the file system driver initialization order. If our driver was loaded under the setting 1 (SERVICE_SYSTEM_START), it failed to create any folders because the file systems were not yet initialized. The workaround we employed was to load the driver as 2 (SERVICE_AUTO_START). It appears that this bug has been resolved by Microsoft, and now we need to determine when this happened and whether we can revert to using SERVICE_SYSTEM_START by default, ensuring that your issue does not recur.

Makes sense. If you update the app, will the new version automatically switch to Mode 1 for all my machines, or do I need to edit their Registries? Or does it even matter, in a practical situation?

We conducted tests on various Windows 10 versions, starting with version 1507 released in 2017, and discovered that creating folders on FAT32 RAM disks was not possible due to a bug in those versions. However, Microsoft resolved this issue in version 1809 and later, released in 2018, and now everything functions correctly with SERVICE_SYSTEM_START.

Given the very small number of users still operating such old versions of Windows 10, we have decided to make SERVICE_SYSTEM_START the default setting to prevent this issue from recurring.

To avoid creating disruptions for existing users, installing the updated version will not switch the setting to SERVICE_SYSTEM_START in the existing installations. This change will only affect new installations, when the drivers are registered in the system.

You are welcome to apply this change to all your machines, although it probably won't make any difference, as on your other machines everything is already currently working well.