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

[jrmoore]

Hi, I'm sorry about the undescriptive bug report title, but I couldn't think of anything better.

A while ago I filed a report at ImDisk Toolkit's tracker, through which I'm using the ImDisk driver.

Basically, I have setup a RAM disk that's always recreated at startup with user temporary directories pointing to it (i.e., R:\Temp), 8 GB, using AWE and being dynamic in terms of memory. It works great most of the times, but some applications seem to have a hard time working with it.

These are some of the error messages that are shown:

The first one belongs to the current graphic driver installer from Intel, it states that the application is in an unauthorized location, whatever that means. Also from Intel, their oneAPI compiler package installer complains X MB of space are needed, even when it was virtually empty. In both cases I had to move things out of the RAM disk for them to work.

The behavior is similar in a way to what I encountered years ago when Process Hacker was updating and %TEMP% pointed to inside the RAM disk, I reported it over at their forums, and their developer kind of explained what the problem was, so I could report it properly, but I completely forgot about it. The reply is here, in case it's still relevant (it seems to have to do with IOCTLs): https://wj32.org/processhacker/forums/viewtopic.php?t=3419#p10644

I don't know if you guys are aware of the issue(s), but I just stumbled upon this project here and seeing there seems to be active development I thought of referencing it here too. The third picture belongs to another case that exhibits the same behavior, I had to temporarily switch the TEMP environmental variables to a real disk to be able to continue with that installation.

Could you please look into it? Don't hesitate to let me know if you need more data samples, or you want logs of some sort, I would gladly do trial and error for you with debug builds of the driver. It needn't be signed, I could self sign them and make sure Windows trusts that signature to do the testing, or enable installation of unsigned drivers for the tests.

Thank you for your time by the way.

[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.

[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.

[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]

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.

[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.

[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]

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.