Both images were formatted as NTFS. I originally did this through the RAM Disk software, however after it loaded the drives with corrupt images a few times, I tried reformatting the mounted drives in Windows using the built in tools and then letting the results be saved back to the images on the disc. The results seem to have been the same either way.

Both images are used as the basis for boot time disks.

The 7 GB image is more reliable than the 20 GB, but not infalliable either.
The 7 GB primarily supports all the random things that happen (cache, temp directories etc).
The 20 GB primarily supports the Data repositry for BOINC (World Community Grid) and is used as a scratch disc for video editing and so forth.

I have just reformatted both using FAT32 (formatted through the RAM Disk software). Touch wood, these seem to be loading and unloading just fine (but I have only rebooted twice).

this issue happened to me too.
I've been using it for several weeks. It works quite well until this morning I started my PC and found the RAMDISK drive not accessible. When I clicked on the RAMDISK drive it asked me to format the disk. It seems that the image is currpted.

The "automatically save to image" function *is* broken on both Windows 7 x64 and Windows 8.1 x64. Thankfully I've not had any data corruption. However when it starts writing to the image file, if there is any activity on the ramdisk it will start throwing "disk is read only" I/O errors. I am running 3.4.3 x64 and have sent a separate ticket about this.

I have image corruption issues all the time as well to this day. Does the "hard disk emulation" option get rid of this problem entirely, or does anyone still experience data corruption issues?

Also how does hard disk emulation affect random 4K r/w performance? I have a software that creates a single temp file, that contains up to thousands of appended temporary files it constantly modifies (rewriting the file entirely), so i'd want to make sure, that hard disk emulation doesn't nullify the benefit of not having to wear down my NAND cells too quickly.

I've been using it for several weeks. It works quite well until this morning I started my PC and found the RAMDISK drive not accessible. When I clicked on the RAMDISK drive it asked me to format the disk. It seems that the image is corrupted.

Exact same problem here. I had version 3.4.5 when it happened. I just updated to current version (3.4.6) to see if this would magically solve it. It didn't.
The RAM Disk software seems to load the image file correctly (green icon in GUI), but the drive is not accessible as mentioned above. Is there a check to see if the image file is really corrupt and is there any way to repair it?

I used the export function to create an XML file which I took to create a new RAM disk. The corresponding image file is 4 KB larger than the old (broken) one, i.e. the old image file has a size of 8.388.616 KB while the new one has a size of 8.388.612 KB. I don't have neither CCleaner nor TuneUp installed. Finally I used HxD hex editor to check for the file for zeros. Yes, zeros almost everywhere, only a few bytes in the beginning are not zeros. Looks like, there isn't anything to be repaired ...

The longer I think about it, I think I narrowed my problem down. I was running out of space on my drive C: the other day. C: is where I save the image file to. I changed my RAM recently to 16 GB and presumably in the moment the RAM Disk Software tried to save the image file to C:, Windows took the chance of free space and increases the file size for pagefile.sys and hiberfil.sys leaving not enough space for the RAM disk image file.

My presumption is that if the software is set up to write the image file every X minutes, it'll delete the image file right before it writes it again. It could be that moment the hard drive runs out of space so the file could not be written safely. At least that would be plausible to me. Is there check in Softperfect RAMDisk whether there is enough space left at all on the harddrive when re-writing the image file?

It does not re-write the image file actually. It does differential writes, that is only writes blocks that have changed in memory since the file was last read or flushed to the disk. I'll ask our RAM Disk developer to comment on this.

Finally I used HxD hex editor to check for the file for zeros. Yes, zeros almost everywhere, only a few bytes in the beginning are not zeros.

I couldn't reproduce this issue. Could you give us more detailed information about your system's version, installed applications, loaded modules, etc. You can run msinfo32, then select Save from the File menu and send us the .nfo file by email or post it here. Also, can you remember the options that you have specified while creating RAM disk at the time when the issue has occurred?

Quote

Marzl

My presumption is ... it'll delete the image file right before it writes it again.

No, RAM Disk does not delete image file before writing, because each time it only writes modified blocks. Furthermore, you can't delete image file while it is mounted as it is opened and locked by the kernel process, and thus this can't result in a corrupted image.

I've just had the same problem. I've been using SoftPerfect RAM Disk for 2 months more or less and it is the second time that it happens to me. I've checked the old file and it has some information so I would like to recover it. How can I do it?

Try a third-party disk mount utility that supports entering an offset, like OSFMount, in which you need to enter the offset of 4096 bytes to the data when mounting the image file. An image file is essentially a 4K header followed by raw disk data.

If OSFMount cannot mount the image at the 4096 bytes offset, I am afraid the file system and data may be damaged beyond repair.

Hi, folks!
Sorry for that huge delay. I ran msinfo32 but saw a lot of personal data I don't like to share (paranoia :-/).

OSFMount solved it for me.

Although I set up a new RAM disk the last time, I still had a backup of the broken image file. Today that newer RAM disk broke, too, most likely by a different issue (will answer in a different thread). I tried OSFMount but it didn't work for the current RAM disk. Out of curiosity I tried it on the backup and that worked out great.

I just gave it a try, but it didn't work. OSFMount did not recognize the file system properly. In your screenshot under "File system (detected)" it says "NTFS/HPFS/exFAT", here it says "N/A". When I tried chkdsk as was suggested as next step it returned "CHKDSK is not available for RAW drives".

I had this issue with 3.4.6 under Windows 8.1 and Windows 10. The disk itself doesn't become corrupted, but files inside do. A simple chkdsk fixes it, but of course you may lose files still (thankfully not too much of an issue for me, though very annoying sometimes). I am not sure that I've seen the problem in 3.4.7 under Windows 10 yet, but I'll report if I do.

I also couldn't uninstall the software to upgrade on Windows 10 and had to manually delete the registry entries and go into safe mode to delete the driver files.

Today I found this warning log in my event viewer (drive H is the RAM drive):

Quote

The system failed to flush data to the transaction log. Corruption may occur in VolumeId: H:, DeviceName: \\Device\\00000072.
({Write Protect Error}
The disk cannot be written to because it is write protected. Please remove the write protection from the volume %hs in drive %hs.)

It appears I have received this quite a few times during apparently normal operation.

Today I found this warning log in my event viewer (drive H is the RAM drive):
The system failed to flush data to the transaction log. Corruption may occur in VolumeId: H:, DeviceName: \\Device\\00000072.
({Write Protect Error}
The disk cannot be written to because it is write protected. Please remove the write protection from the volume %hs in drive %hs.)

It appears I have received this quite a few times during apparently normal operation.

It's by design. Writing to the disk is blocked when the data is being saved to to an image file file (as otherwise it would result in an inconsistent image).

If this is not suitable, I would recommend not to use an image file and use a file-level backup utility like Robocopy or Unison.

That is good to know. My image just became corrupted and unrecoverable just now using the latest version 3.4.7. I recently had just recreated it under the new version, and let the new version format it and everything. Automatic save feature set to 5 minutes, and not a removable drive. :/