The latest versions of ImDisk exhibit some unexpected behavior when used to mount raw image containers hosted on a local hard disk (traditional, not SSD). I've confirmed that this behavior exists in ImDisk v2.0.6 and v2.0.9 and most likely originated from the 2.x rewrite of ImDisk. This behavior does not exist in ImDisk v1.9.4. I have observed this behavior on two different Windows 7 x64 machines. This behavior appears to be some kind of race condition and is only observable with operations on large files (> 10 GB).
To reproduce this problem, create a new file on your local hard disk (let's call it D: from now on, for brevity) to act as the raw image container. You can use these commands to do this:
fsutil file createnew D:\<filename> 64000000000
fsutil file setvaliddata D:\<filename> 64000000000
You may need to write zeroes to the first 512 bytes of the file to make sure ImDisk detects this as blank media. Right-click the created file and choose "Mount as ImDisk Virtual Disk. In the dialog box, size of image should be "(existing image file size)" and image offset should be 0. Leave other options default. (Let's call the mounted image partition E: from now on, for brevity.) Quick-format E: with the NTFS filesystem with default cluster size. Now let's assume we have a large file > 10 GB called D:\largefile. (You can use any large file on your PC to observe the problem behavior. And you can also re-use the fsutil commands above to create said large file.)
When I initiate a file copy D:\largefile to E:\largefile one of 2 things happens:
1. The file is copied normally at ~50MB/s. This is the expected behavior.
2. The file is copied normally for 1-2 seconds at ~50MB/s. The process copying the file (explorer or any other filemanager) then stops responding. It's now impossible to cancel the file copy through the process's GUI. (Since explorer does asynchronous file copies, it will continue responding, but the thread responsible for file copy will be frozen). ImDisk driver will proceed to write zeroes to the entire length of E:\largefile. (This should not occur since we do not want to fill the file with zeroes, but rather with its actual data from D:\largefile. This is the redundant container writing behavior.) Resmon.exe shows the writing activity coming from the system process (PID 4). On one machine, zeroes are written at ~50MB/s and the hard disk D: is at 100% utilization. On another machine, zeroes are written at ~5MB/s, with D: utilization at 5%. As you can see, this makes ImDisk essentially unusable when dealing with large files. Once zeroes are written to the entire length of E:\largefile, the process copying the file unfreezes and the copying proceeds normally at ~50MB/s and can be cancelled. If I were to forcefully dismount E:\ (see below on how to do this) while zeroes are being written, when I re-mount it and look at the contents of E:\largefile, its first ~50MB are filled with actual data from D:\largefile. The rest is zeroes. This is the data that was copied before the strange race condition occurred causing the ImDisk driver to start writing zeroes to the entire length of the file.
When I try to delete E:\largefile (or any large file on the mounted partition) the following behavior happens consistently:
The deletion appears to happen normally. The file disappears and the file manager GUI is responsive. 1-2 seconds later ImDisk starts writing zeroes to the entire length of the deleted E:\largefile. Same as above: [On one machine, zeroes are written at ~50MB/s and the hard disk D: is at 100% utilization. On another machine, zeroes are written at ~5MB/s, with D: utilization at 5%.] If I try to initiate any other I/O request to the mounted image, or try to dismount it, before the zero-writing completes, the file manager will become unresponsive until all zeroes are written.
Now for the really bad part: while the ImDisk driver is writing the zeroes, it will sometimes simply stop (another race condition?). Hard disk D: utilization drops to 0%, there's no I/O activity to E: anymore. File manager will remain frozen, and any process that tries to as much as enumerate E: will also freeze. This is the kernel-level I/O deadlock behavior. If I were to shut down Windows at this point, it too will freeze at "Shutting Down...".
It is usually possible to recover from this deadlock by forcefully dismounting the host hard drive D: with a command like
chkdsk D: /x
Sometimes, though, this too will fail, and now any enumeration of D: will also lead to deadlock.
As you can see this makes ImDisk 2.x essentially useless if you need it for working with large files on local hard-disk hosted containers, forcing me to keep using v1.9.4. I sure hope I'm not the only one who can reproduce this problem.
If you're still with me, thank you for reading all this, and, of course, huge thanks to Olof Lagerkvist for creating this tool in the first place. It's been immensely useful to me for many years now and is one of the first things I install on any new machine, together with the drivers
Edited by pter6464, 14 December 2016 - 12:50 AM.