Thanks for the detailed report - it actually points straight at the cause. Manual image-backed RAM disks are still fully supported. Nothing is wrong with your image file (as you correctly deduced).
What changed and why
In a recent build we closed a local security hole in the kernel driver. Previously, when a RAM disk was mounted with an image file, the driver opened that image file using the SYSTEM account, ignoring the file's normal Windows permissions. That meant a standard (non-administrator) user could ask the driver to read or write
any file on the machine as SYSTEM = a privilege-escalation risk.
The hardened driver now opens the image file using the permissions of whoever launched the mount:
- At Startup / Automatic mounts are performed by the background service, which runs as SYSTEM, so they still open the file and work exactly as before. That's why switching P: to "At Startup" fixed it.
- Manual mounts (from the GUI, or via ramdiskctl) now run under your own user account. If your account doesn't have read and write access to G:\PortableApps.img, the call to open is refused with "C0000022 (Access Denied)".
The mount needs write access, not just read, because the RAM disk saves your changes back to the image on dismount/shutdown. A file sitting in the root of a drive (like
G:) very often grants standard users read-only access, which is almost certainly what you're seeing.
How to fix it
Do any of these:
- Give your user account full access to the image file
Right-click G:\PortableApps.img → Properties → Security → Edit → select your user → tick Modify (read and write) → OK. Do the same on its containing folder if needed. The manual mount will then succeed. This is the most likely single fix. - Leave the disk set to "At Startup"
This mounts the image as SYSTEM at boot (which you've confirmed works). If you don't specifically need to mount/unmount it on demand, this is the simplest option. - Keep using a batch file with ramdiskctl, but note the difference between two features and run it correctly.
There are two distinct ways to put an image file on a drive letter, and they are not the same thing:
- Image-backed RAM disk (load) - the image is read into RAM, and the drive runs entirely from memory (fast; changes are written back to the image when you save/dismount). This is what your P: disk is configured as, and what the old ramdisk.exe /mount:P did.
- Mounting an image (mount-image) - the drive reads and writes directly to the file on disk, with no RAM used. This is what your new batch file called, so it behaved differently from your original setup.
To reproduce your original behaviour, use
load:
"C:\Program Files\SoftPerfect RAM Disk\ramdiskctl.exe" load "G:\PortableApps.img" --letter P
timeout /t 5 /nobreak >nul
start P:\Start.exe
Because the mount still runs as your user, this batch file must either be run as Administrator (right-click → Run as administrator), or you must grant your account write access to the image as described above. With one of those in place, the
load command will succeed and
P:\Start.exe will launch as before.
Sorry for the disruption; the change was a necessary security fix, but as you can see the workflow you had is still fully available.