Ok, turns out it is a known bug... Curious if there are any solutions?
Indeed, I'm using Windows 8.1 x64. Indeed I have auto save on. I had it on 1 minute, currently I'm testing with 20 minutes interval. I don't often reboot, so this 'testing' will take a while. Indeed I use NTFS for R: and FAT32 for copy S: . Indeed, non of the images use hard disk emulation (though I'm testing that now too). I have set both images to be boot images... Both are approx. 5 GB in size. I also have a 10 GB TEMP Ram-drive T: - contents aren't saved, I never had to "format" that drive... It's always there, working but empty, after reboot.
Quote
Ben
I've had this problem as well, but only since installing Win 8.1. Most of the time when I boot, the RAM disk is corrupted, so I need to restore it from a backup. (After that it works fine). I'm going to try bumping up the "Save contents to associated image" option from 1 to 10 minutes and see how that goes. Any other suggestions?
I saw in another thread a question about logon vs boot images. Which would you suggest?
Quote
Andrew
We seem to have found the bug, but could anyone who experienced image file size growth please confirm the following:
1. You had set up the RAM disk to periodically save data to an associated image file.
and/or
2. The image file became corrupted after the system had been restarted or turned off/on.
Thank you.
(me: exactly!)
This tip might help recovering data:
Quote
Andrew
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.
Interesting... I think

Will run a hex edit next time too... See what it gives!
Quote
Marzl
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 ...
Same questions...
Quote
Asagrim
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.
Thanks!
Some updates on this bug would be great.
Thank you all,
Devvie