RAM Disk contents lost after reboot

Often, after a reboot, it turns out my ram disk is unformatted and the contents are lost. Which is strange, I automatically save to ram disk every 1 minute...

What should I do to prevent this? I often have 2 ram disks, that should be mirrored, from which the first 1 (the one I actually use as a profile folder for Chrome) often loses its contents... Open for suggestions, while I twinkle with some settings...

Devvie

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

Quote

shurikenix

Windows 7 x64 installed on SSD, SP RAM disk v. 3.4.6, (MB ASRock z87 pro)
If size of pagefile.sys set to zero or selected by Windows, ramdisk works fine, otherwise Windows crashed on boot. I try many values of pagefile - 512MB, 1024MB, 4096MB - nothing changes. Without ramdisk Windows works correctly with any size of pagefile.

I checked, pagefiles not enabled on RAM disks (disabled). So should be good and not the cause for my losses...

Might be the problem with my boot disks too? My server takes a long time to boot after enabling RAM Disks...

Quote

Andrew

We have been able to reproduce this issue and no further information is needed at this stage. So far it looks like the problem is caused by the time it takes to allocate a large RAM block (not the size of the disk). Perhaps the kernel cancels the RAM disk creation and continues to boot after a timeout. We need some time to add logging and see when and how this happens.

Though my images are relatively small (tests ranged from 2GB to 10GB: all ranges had problems), it still could be the root of the bug. Images are stored on single disk 1TB, 7200 RPM. Server OS runs on RAID 10 (2x2 disks).

My not-to-be-saved-or-remembered TEMP drive T: works like a charm...

Devvie

I think the bug is unresolved, still?

From administrator:

Quote

No, sorry. Still haven't found a good way to allocate this much memory on startup

Could you tell us how much memory should work? How much will be allocated at boot time? Win Server 2012 R2, x64, 128GB RAM.

It seems to depend on a specific system, you can find the maximum disk size for your system with trial-and-error.

As to the damaged volume images, it's not clear why this occurs. I would probably recommend to use a file-level syncing tool like rsync or unison to sync a RAM disk and a hard drive location.

Quote

Andrew

It seems to depend on a specific system, you can find the maximum disk size for your system with trial-and-error.

System like in hardware / chipset or like in Windows version?

Quote

Andrew

As to the damaged volume images, it's not clear why this occurs.

that's not fun to hear!

Quote

Andrew

I would probably recommend to use a file-level syncing tool like rsync or unison to sync a RAM disk and a hard drive location.

I meant to say... Both image files are separate but I copy the FILES from first ramdisk R: to my second ramdisk S: - so not to lose contents of my Chrome cache when, after reboot, the image becomes unformatted again :/

And I have a separate script (robocopy) that once in a while makes a copy of the images themselves. That seems to work just fine, even when auto-save is set to 1 minute (copying an image file takes longer than that, but despite the write lock I don't see any problems there... Though I'm still testing my scripts... I'll repost if indeed copying them image files causes problems too).

So in the end... Development has been pretty much halted because of these bugs? Or am I completely wrong here?

Thanks for the quick replies! Appreciated,

Devvie

Quote

Devnullius

So in the end... Development has been pretty much halted because of these bugs? Or am I completely wrong here?

You are wrong here, the development of this product is still in progress. But it's pretty hard to fix errors in kernel-mode drivers, especially if they are not reproducible in the test systems.