Miniport for Volumes?

NTFSD
1

Going back over working code to make it less hacky.

I have a situation where I want to mount a filesystem, that does not have a direct disk device under it.
The steps involved as I understand it something along the lines of:

  1. ???
  2. Receive (IRP_MJ_FILE_SYSTEM_CONTROL,IRP_MN_MOUNT_VOLUME)
  3. Attach my FSD
  4. Handle IRPs related to filesystem

Currently for “1” I call IoCreateDeviceSecure(FILE_DEVICE_DISK), + IoCreateSymbolicLink() and attempt to handle the
IRPs that come in for the “disk device”. Following example of winbtrfs, but there appears to be cracks. MountMgr is
never entirely happy with it nor the driveletter it gets. There are other possible issues as well, like that I can not get $Recycle.Bin to work.

I could spend more time debugging, trying to figure out if I reply incorrectly to some IRPs etc, but, I think
someone once recommended I use miniport to create the Volume, and attach my FSD. Could that work? Is that
a better way to go?

I have familiarised myself with a miniport example, and if I go through the steps:

  1. setup targetid+lun (0,0) and handle requests
  2. allow offset 0, size 512, to be written, and “read” back. Return zeros for everything else.
  3. possibly handle offset 0xe00, 0x10000 for efi and backup tables
  4. use DiskManager to Iinitialise Disk (writes offset 0, size 512)
  5. use DiskManager to create SimpleVolume (no filesystem) writes 0xe00.
  6. Receive (IRP_MJ_FILE_SYSTEM_CONTROL,IRP_MN_MOUNT_VOLUME)

It seems a little OverTheTop to use miniport for this, it creates a (fully working) \PHYSICALDRIVE after all, then having to
remember the partitiontable (or even just reply with a generated one) seems a little cumbersome. Maybe this direction wont lead to something
better and cleaner.

Is there an API framework I should be using to create the Volume to attach my FSD to? Presumably RAID managers, and RAM disks
have to do something similar, are there examples of that?

What path would the more seasoned developers take?

2

We’ve been through all this before.

To repeat what I wrote some time ago: File systems in Windows do not typically have “direct disk devices” under them. File systems mount on volumes, which are comprised of one or more components typically implemented as partitions. Partitions are sub parts of disks, which are addressed though some sort of storage adapter.

If you want to create a virtual disk device, you want to create a StorPort Miniport. We wrote a series of articles about this, and even provided an example, something like ten years ago… you can find it here. It should still be mostly correct. A final update to the project is here.

Again… instead of ”just writing some code” I’d suggest you do some actual design/architecture to make whatever your doing fit properly into the world of Windows.

Peter

3

If I understand you correctly, you wish to create a device similar to those created by the Volume Manager (volmgr.sys) but which have no underlying disk device. You may look into VeraCrypt source code for that.

As for MountMgr, AFAIK you have two options:

  1. register and enable GUID_DEVINTERFACE_VOLUME (MountMgr will be notified and kindly responds with some IRPs),
  2. you may inform MountMgr (\Device\MountPointManager) about your device via IOCTL_MOUNTMGR_CREATE_POINT. There are possibly some other MountMgr IOCTLs you may find very useful.

I would prefer the first option since the interface arrival notification is broadcasted to all parties interested in it. The only “problem” with this method is tha your device need to be PnP. AFAIK, TrueCrypt/VeraCrypt create legacy devices (non-PnP) represent their encrypted containers, so have a look in their direction.

4

Thank you Martin, it does seem clear that nobody uses miniport for just the Volume side of things, and registering with MountMgr does/will/should work, I most likely have some issues to fix to make things like recycle.bin to work.