Large fixed-size allocations and high-throughput writes cause a freeze on macOS

Hello.
I am currently evaluating SoftPerfect RAM Disk, and I am very impressed—it is an excellent product. There is just this one issue I would like to see resolved:

SoftPerfect RAM Disk (macOS) - System-wide Freeze with Large Fixed-Size Allocations and High-Throughput Writes

Summary:
Creating a fixed-size (non-dynamic) RAM disk above a certain size causes a complete, unrecoverable system freeze on macOS. A 2 GB fixed allocation works fine; but larger sizes (over 14 GB) freeze the entire machine right at/just after the mount operation, before any data is written to the disk.
Separately, with Dynamic Allocation enabled, a very high-throughput or very large single write into the RAM disk can also trigger the same class of freeze.
The unresponsiveness is system-wide, not limited to the RAM Disk application or the UI, and requires a hard power cycle to recover, with no kernel panic log ever generated. This system is a Hackintosh with 128 GB RAM, and I understand official support may be limited for non-Apple hardware. However, on the same hardware, at equal or greater I/O load, Apple's native 'mount_tmpfs' and an APFS RAM disk (via 'hdiutil'/'diskutil') do not exhibit this issue, which points to something specific to SoftPerfect RAM Disk's macOS driver rather than the underlying hardware or macOS itself.

I've isolated the fixed-allocation threshold, testing from a freshly booted system each time:
- 14 GB fixed allocation: mounts successfully, no freeze.
- 16 GB fixed allocation: freezes the entire system, every time.

I will be happy to:
- Run further tests to help isolate the exact size threshold at which fixed allocation starts failing.
- Provide full system diagnostics or 'ioreg'/'kextstat' output.
- Test a pre-release or debug build if that would help track this down.

Attachment: [detailed_report.md]

Also, I have a feature request: Custom mount options / mount point.
For scratch and cache use, I'd love to be able to mount a RAM disk with options like nobrowse (hidden from Finder), noatime, and noowners, and to specify a custom mount point instead of /Volumes/<Label>. I tried doing this manually: the disk does appear as a normal /dev/diskXX block device, so in principle diskutil mount -mountOptions noatime,noowners,nobrowse -mountPoint ... should work. But the moment I run diskutil unmount on it, ramdiskd tears the device down entirely (the /dev node disappears), so there's no device left to re-mount with my own options. So this really needs to be an option the app passes at mount time. Even just exposing nobrowse and a custom mount point in the UI would be fantastic. (A "prevent accidental unmount" option would also be welcome, though nobrowse alone would go a long way by keeping it out of Finder.)

Thank you for the exceptionally detailed and well-researched report. The comparisons against tmpfs and the APFS ram:// disk, and the work you've done to rule out RAM stability, were immensely helpful. The 14/16 GB freeze boundary you pinned down lined up precisely with what we were seeing on our large-memory test machine.

We've just published a new snapshot with fixes for the issues you reported, and the new options added.

Advanced Disk Settings now have a Mount Options button that opens a small dialog where you can tick Hide the volume from Finder (nobrowse), Do not update file access times (noatime), and Ignore file ownership (noowners).
Note: nobrowse now genuinely hides APFS volumes in Finder. As macOS auto-mounts a fresh APFS volume visibly before we can set the flag, the disk briefly appears and then disappears at creation. That one-second flash is expected, and the volume ends up hidden.

The custom mount point feature is not in this build yet, but it's on our to-do list.
For now, the simplest workaround is a symlink: mount the RAM disk at '/Volumes/<label>' as usual and symlink your app's scratch or cache path to it, for example:

ln -s /Volumes/scratch ~/Library/Caches/YourApp

Just make sure the disk is mounted (set it to start automatically) before the app opens the cache.

I'm happy to report that the snapshot build is working excellently on my 128 GB machine. After the clean install, everything that used to freeze now works, and I've put it through a fairly thorough set of tests. Thank you for the outstanding support and the quick fix - this has been one of the best vendor support experiences I've had.