There is some sort of problem when accessing elements inside an ImDisk based disk.

[jrmoore]

There is some sort of problem when accessing elements inside an ImDisk based disk.

[LTRData]

I stopped the development of ImDisk pretty much 10 years ago except for some smaller tweaks in some places.

I decided to keep it available because it is frequently used on very old versions of Windows and I wanted to keep it compatible like that and not implement new things that could break the old logic and compatibility in any way. It is in my opinion unnecessary complicated to try to start with a project like ImDisk and implement all modern requirements when that is something you get automatically with a driver design based on for example a SCSI miniport.

I then started development of what is now Arsenal Image Mounter. There are links in the README for this repository. It is fully compatible, emulates complete disks, can mount lots of different image file formats as well as RAM disks etc. I use it a lot myself too. It does not have any synchronization features though, I use the RAM disk feature only for temporary things like TEMP directory, some browser cache etc. But it works perfectly in that way and it is very actively developed and I must say we provide very good support for it too.

[LTRData]

Yes, in a way it would probably be nice to have something like ImDisk Toolkit but for Arsenal Image Mounter instead. Both ImDisk and Arsenal Image Mounter have been largely focused on backup/recovery/sysprep/forensics from start of development, with RAM disk features added at a later point. I have never used ImDisk Toolkit myself, but it seems nice and easy to use.

The way I use RAM disks with Arsenal Image Mounter is that I create a dynamically expanding vhd image file with the files I want to have in the RAM disk from start. Then mount that image with the RAM disk based on vhd feature in AIM, or by scheduling a command line to run at computer startup:
aim_ll -a -f \\?\vhdaccess\??\awealloc\??\C:\imagefile.vhd -m R:

Not very intuitive etc, but it works. It creates a dynamically allocated AWE based RAM disk.

I will probably soon put together an FAQ with commands like this similar to the existing FAQ for ImDisk.

[Gitoffthelawn]

A FAQ for AIM would be a wonderful addition.

Like @jrmoore, I took a close look at AIM. It is incredibly impressive and powerful. My hat is off to Olof for such an amazing product. Yet the steps required to simply create a RAM disk were not intuitive. And I could never find sync functionality (which, reading the above, I now understand does not exist).

I think a FAQ would be great, along with basic sync functionality.

Another idea is to release a subset of AIM that is intended to simply create a RAM disk. I think it would be quite popular and could even serve as a way to make many people aware of AIM.

[jrmoore]

The way I use RAM disks with Arsenal Image Mounter is that I create a dynamically expanding vhd image file with the files I want to have in the RAM disk from start. Then mount that image with the RAM disk based on vhd feature in AIM, or by scheduling a command line to run at computer startup: aim_ll -a -f \\?\vhdaccess\??\awealloc\??\C:\imagefile.vhd -m R:

Not very intuitive etc, but it works. It creates a dynamically allocated AWE based RAM disk.

Almost! I gave it all a try again, but disregarding the UI using the CLI to install the driver and aim_ll.exe with a similar line to create the RAM disk and it worked! I had to create the VHD beforehand with the size I wanted, format it and create a Temp file inside, now I understand what the "template" meant in the UI.

However, it seems the automounting flag isn't currently implemented, so after I reboot the drive isn't added and %Temp% points to non-existent folders, but it's pretty much what I wanted to accomplish with ImDisk.

I was worried that by using a file as backing it would mean that whatever I copied in the RAM disk would be written there in a situation of low RAM or something, but I think the VHD is just for the initial structure and nothing else, which is the main point for me since I want it to be volatile and not being written anywhere.

I'm looking into adding a script to the boot process (have to look where to, the earlier the better) to have the disk up and running for everything that needs access to the temporary folders and I'm done. Well... and check that things work as expected, which was what the initial bug report was about 😅, but I could already see it being a "real" disk in the Task Manager view, for example, identified as an HDD instead of SSD, but I think it could be inconsequential.

Thanks a lot!

[LTRData]

This is a very well known problem. ImDisk is based on a very old driver design and is not recommended on modern versions of Windows. It lacks lots of features that many modern applications expect to be supported.

[jrmoore]

Oh! I see, because I saw a recent comment about updating the toolchain of the solution I thought it was in active development.

The problem is hard to fix then, right? Do you know of any other RAM disk implementation that would be suitable for use on modern versions of Windows? I was using ImDisk through the ImDisk Toolkit as my go to, I always keep temp folders over there and use that drive for most things.

It's too bad it can't be fixed.

[jrmoore]

Sadly, at least for me, Arsenal Image Mounter doesn't seem to be a good fit, I find it very complicated and seems to be oriented to something else entirely (forensics?).

It's odd that I find myself in a situation when I don't even know where to click, but I felt that way with it. Plain RAM disk creation seems to be an afterthought, there are a couple of entries in some menus for it one that just asks for its size and allocates the whole block all at once and another to use a VHD template (?). No option to choose drive letter, autocreation on boot, AWE so memory isn't paged, dynamic memory usage, etc.

On first boot there's a dialog about a driver being needed and it offers to auto install it, but if we wanted to uninstall it... I couldn't find any option for it in the UI. Although looking at the GitHub repo I found many other things in there that aren't linked to in the site, like a command line binary to uninstall the driver (the graphical one throws an exception for some reason). So there's that possibility.

There seems to be a low level binary to interact with the driver as well, aim_ll.exe, not included in the official distribution, but when I ran it with /? to get some help on its usage I was overwhelmed by the options and wouldn't even know what to do 😟.

To be honest, even if ImDisk is outdated in its design and lacks many things I find it way more user friendly thanks to the ImDisk Toolkit's RAM configuration UI. It's just tick, tick, tick, set size, click OK and we're done.

For now I think I will continue to use ImDisk, even if unreliable while I look for a suitable replacement. But thanks for the recommendation! Since Arsenal's is in active development I'm sure something more user friendly will appear at some time, perhaps with an installer as well, so I'll keep my eye out for it.

[LTRData]

Thanks! I hope that someone could create a user interface for such features like was done with ImDisk Toolkit. I remember that the interest for ImDisk really took off when ImDisk Toolkit was made available, because it was a bit complicated to use before.

Personally I do not really find a sync feature useful but I realize that some users really like to synchronize data back and forth between their RAM disks and permanent storage instead of just using RAM disks for temporary storage. It is a bit difficult to implement though and it has taken a large amount of work for ImDisk Toolkit developer to implement it there too. I cannot see that happen in AIM in any near future.

But we have lots of other interesting features in the pipeline and a new release coming out soon. For instance, a feature to expose physical disks attached to the system as virtual image files, to make it easier to analyze disks and file systems, create image files etc.

[LTRData]

Sounds great! To have it automatically load at system startup, I usually just create a scheduled task with that command line and set it to run at system startup.

The thing that makes it using the vhd as template and just use it for creation of the RAM disk is the "awealloc" piece of the path. It copies the vhd file structure into an AWE allocated RAM block that is then dynamically expanded as the vhd expands in memory when files are copied to the RAM disk. When you delete files from it, the TRIM instructions sent from NTFS causes blocks to be deallocated and memory freed.