Virtual disk using existing virtual volume as backing store.

[navkumar20]

Consider using an existing NTFS/ReFS virtual volume (\Device\VirtVol1) as a backing file for the virtual disk created by AIM.

aim_ll -a -F \Device\VirtVol1 -o ro

Two cases NTFS and ReFS:

NTFS:

In my tests, the above created disk correctly shows up as NTFS if the virtual volume was NTFS. But if the readonly flag (-o ro) is removed then the phdskmnt.sys driver fails NTWriteFile with random "access denied" (0xC0000022) errors and in the end the disk shows up as RAW.

ReFS:

The created disk always shows up as an uninitialized disk (no MBR/GPT) with/without readonly flag and needs to be formatted which defeats the purpose of using the pre-existing virtual volume.

Is there a way to get the created disk show up as ReFS volume mirroring the virtual volume (\Device\VirtVol1) just like NTFS, instead of an uninitialized disk?

This test is similar to the following workaround claimed to make this work but doesn't actually work as per my tests (i only get an uninitialized disk):

https://sourceforge.net/p/veracrypt/discussion/technical/thread/88b66508d3/#32a0

[LTRData]

Windows write-protects volume objects while a file system is mounted on that volume, which is why you get write failures in your first example. I would think that you could solve this by offline the volume first by sending an IOCTL_VOLUME_OFFLINE to it first. That will make sure that Windows will not try to mount any file system on it. Maybe this will help in both your cases, but I am unsure about ReFS, I know that ReFS has had several problems with several steps of virtualization with another mounted file system somewhere in the stack.

May I ask why you want to do this? Maybe there is an easier and more reliable way to solve your actual problem here!

[navkumar20]

Ok, i will try the "volume offline" workaround. But even with the "readonly" flag the "uninitialized disk" issue is still there with ReFS - it is readily apparent on following the simple steps in this link:

https://sourceforge.net/p/veracrypt/discussion/technical/thread/88b66508d3/#32a0

Unfortunately, my tests only end up in an uninitialized disk contrary to the ReFS volume claimed above. I also created a simple virtual volume mirroring an existing ReFS volume and see the same behaviour on running the AIM cmd with the virtual volume.

Summary:

1. "\Device\VirtVol1" is NTFS virtual volume:

aim_ll -a -F \Device\VirtVol1 -o ro Success in getting NTFS virtual volume on the created disk.

2. "\Device\VirtVol1" is ReFS virtual volume:

aim_ll -a -F \Device\VirtVol1 -o ro Created disk shows up as uninitialized.

Hope i have made the requirement and issue clear.

[LTRData]

Another problem here could be that this emulates one disk volume as a disk. There will be no partition table or anything like that on your virtual disk, the entire emulated disk will consist of a file system. That means that it requires the file system to be capable of mounting the entire disk instead of a partition.

I just checked by mounting a simple image file with only an ReFS image on it. That is, no partition table, not a "full-disk" image, and that would not work either. Apparently ReFS does not support mounting on a full disk, it requires a partition or disk volume.

[navkumar20]

That then looks like another undocumented ReFS quirk! Sigh. The VeraCrypt devs looked confident of their workaround so who knows if something changed in ReFS itself in a year. Would you be able to suggest any workaround for this? Is it even possible for AIM have an option to set up a minimum MBR partition table for ReFS in the driver itself? In the end, the goal is to have a ReFS virtual volume have a disk underneath to avoid the PNP bugcheck/error on trying to mount the volume as detailed in that VeraCrypt thread.

[LTRData]

Not sure really. I would try ImDisk in "parallel mode" instead of AIM in this case. imdisk -a -o par -F \Device\VirtVol1 -m# Have you tried that? Since ImDisk emulates a disk volume instead of a whole disk, ReFS will generally mount file systems in cases like this just fine. And with the -o par option ImDisk sends requests directly down the stack to the driver for the underlying image "file", in this case the underlying volume, which means that there will be a device stack under the virtual volume so that ReFS typically will be happy about it.

Just something to try, at least.

[navkumar20]

Hi Olof, I ran the imdisk command using the imdisk.sys driver with the VeraCrypt virtual volume. Btw, i see that VeraCrypt already does a (StackSize += 6) on the created device object.

imdisk -a -o par -F \Device\VeraCryptVolumeZ -m #:

For the NTFS virtual volume (Z:), the device got created (\Device\ImDisk0) with a new letter (J:) but accessing J:\ in explorer gives error "access denied".

ImDisk: Passing DesiredAccess=0xc0000000 ShareAccess=0x5 CreateOptions=0x868 ImDisk: File '\Device\VeraCryptVolumeZ' opened successfully.

There are many errors like STATUS_FILE_LOCK_CONFLICT, STATUS_UNSUCCESSFUL, STATUS_END_OF_FILE, STATUS_ACCESS_DENIED:

ImDiskReadWriteLowerDeviceCompletion: Parallel I/O failed with status 0xc0000054 ImDiskReadWriteLowerDeviceCompletion: Parallel I/O failed with status 0xc0000001 ImDiskReadWriteLowerDeviceCompletion: Parallel I/O failed with status 0xc0000011 ImDiskReadWriteLowerDeviceCompletion: Parallel I/O failed with status 0xc0000022

For the ReFS virtual volume (Z:), the device got created with a new letter (J:) but crashed immediately.

I see the same behaviour NTFS (errors), ReFS (crash) with another virtual volume created with a test driver other than VeraCrypt. The crash details are in the attached file "ReFs crash with imdisk.txt"

It seems ReFS broke many existing drivers.

ReFs crash with imdisk.txt

[LTRData]

Thanks for testing. You still need to offline the underlying volume using IOCTL_VOLUME_OFFLINE though. That will always be needed when you try to remount a file system over and existing volume like this.

[navkumar20]

I ran imdisk again with "ro" and in initial tests there has been no failure or crash in either NTFS or ReFS.

imdisk -a -o par,ro -F \Device\VeraCryptVolumeZ -m #:

I can see the new devices at J:\, but trying to understand what exactly was accomplished here, how is it different from the virtual volume itself, and does it really have a device node underneath as intended in the proposed SCSI disk AIM solution (which unfortunately does not work for ReFS as detailed earlier). You said there will be device stack with the imdisk solution but an explanation will help while i try to understand it myself. Thanks!

[LTRData]

It simulating attach to underlying device stack by forwarding requests directly down to the underlying device stack. That is, it does not queue the requests, it just forwards them, pretty much like it would have done to an underlying disk if it was a volume that was a partition of a physical disk.

To be able to do that safely, it adds enough I/O stack size to support the entire device stack for the underlying device. A side-effect of that is that drivers above, such as NTFS or ReFS, will see a large device stack where they could manipulate stack positions just like if it would have been attached to a physical disk.