MountMgr reparsepoint mount

NTFSD
1

So I have been using chatGPT to try to debug why my code does not work when creating a volume mounted on a directory.
I create a top device, which is assigned "\DosDevices\E:".
then I create a sub-device, which I want to mount on "\DosDevices\E:\dataset".

So according to chatGPT, I should do:

Create my new (sub)device;

"\Device\Volume{3fe4a1af-988f-3c6a-93c0-6c75d96902db}"

First we check the device is ready.

IOCTL_MOUNTMGR_QUERY_POINTS:
         # DeviceName              # SymbolicLinkName
point 4: '\Device\Volume{0b1bb601-af0b-32e8-a1d2-54c167af6277}' '\??\Volume{df46d386-2857-11ef-82bd-58961d57db67}'
point 5: '\Device\Volume{0b1bb601-af0b-32e8-a1d2-54c167af6277}' '\DosDevices\E:'
point 6: '\Device\Volume{3fe4a1af-988f-3c6a-93c0-6c75d96902db}' '\??\Volume{df46d39b-2857-11ef-82bd-58961d57db67}'
point 7: '\Device\Volume{3fe4a1af-988f-3c6a-93c0-6c75d96902db}' '\DosDevices\F:'

Excellent, so it was assigned "\DosDevices\F:".

Then we remove mapping "\DosDevices\F:".

IOCTL_MOUNTMGR_DELETE_POINTS:
struct PMOUNTMGR_MOUNT_POINT, PMOUNTMGR_MOUNT_POINTS

point->SymbolicLinkName: "\DosDevices\F:"
point->SymbolicLinkNameOffset: 0x18
point->SymbolicLinkNameLength: 0x1c 
point->DeviceName: "\Device\Volume{3fe4a1af-988f-3c6a-93c0-6c75d96902db}"
point->DeviceNameOffset: 0x34
point->DeviceNameLength: 0x68
totalLength: 0x9c

** ntstatus = STATUS_SUCCESS;

IOCTL_MOUNTMGR_QUERY_POINTS:
         # DeviceName              # SymbolicLinkName
point 4: '\Device\Volume{0b1bb601-af0b-32e8-a1d2-54c167af6277}' '\??\Volume{df46d386-2857-11ef-82bd-58961d57db67}'
point 5: '\Device\Volume{0b1bb601-af0b-32e8-a1d2-54c167af6277}' '\DosDevices\E:'
point 6: '\Device\Volume{3fe4a1af-988f-3c6a-93c0-6c75d96902db}' '\??\Volume{df46d39b-2857-11ef-82bd-58961d57db67}'

So far, so good. We managed to affect a change with MountMgr.

We create the reparsepoint junction, probably does not get used yet.

FSCTL_SET_REPARSE_POINT:
poa.ObjectName: "\??\E:\\dataset"
MountPointReparseBuffer.PathBuffer: "\??\Volume{df46d39b-2857-11ef-82bd-58961d57db67}\"
MountPointReparseBuffer.PrintName: "BOOM/dataset"

** ntstatus = STATUS_SUCCESS;

Then chatGPT says I should create point, and then announce it. It also
claims I should use a trailing backslash.

IOCTL_MOUNTMGR_CREATE_POINT
struct MOUNTMGR_CREATE_POINT_INPUT

  point->DeviceName: "\??\Volume{df46d3a7-2857-11ef-82bd-58961d57db67}\"
  point->DeviceNameOffset : 8
  point->DeviceNameLength : 0x62
  point->SymbolicLinkName: "\DosDevices\E:\dataset"
  point->SymbolicLinkNameOffset : 0x6a
  point->SymbolicLinkNameLength : 0x2c
totalLength: 0x96

** ntstatus = STATUS_SUCCESS;

and the second call:

IOCTL_MOUNTMGR_VOLUME_MOUNT_POINT_CREATED:
struct MOUNTMGR_VOLUME_MOUNT_POINT_INPUT

   mountpoint->SourceVolumeName: "\??\Volume{df46d39b-2857-11ef-82bd-58961d57db67}\"
   mountpoint->SourceVolumeNameOffset: 8
   mountpoint->SourceVolumeNameLength: 0x64
   mountpoint->TargetVolumeName: "\DosDevices\E:\dataset"
   mountpoint->TargetVolumeNameOffset: 0x6c
   mountpoint->TargetVolumeNameLength: 0x2e
ntstatus = STATUS_SUCCESS;

So finally, we call IOCTL_MOUNTMGR_QUERY_POINTS again to list:

point 4: '\Device\Volume{0b1bb601-af0b-32e8-a1d2-54c167af6277}' '\??\Volume{ba95a227-3694-11ef-82bd-58961d57db67}'
point 5: '\Device\Volume{0b1bb601-af0b-32e8-a1d2-54c167af6277}' '\DosDevices\E:'
point 6: '\Device\Volume{3fe4a1af-988f-3c6a-93c0-6c75d96902db}' '\??\Volume{df46d3a7-2857-11ef-82bd-58961d57db67}'

And I was hoping for another line, for "\DosDevices\E:\dataset" but I appeared to have failed.

$ mountvol
    \\?\Volume{ba95a227-3694-11ef-82bd-58961d57db67}\
        E:\

    \??\Volume{df46d3a7-2857-11ef-82bd-58961d57db67}\
        *** NOT MOUNTABLE UNTIL A VOLUME MOUNT POINT IS CREATED ***

Only hint I have so far, I thought I had "created a volume mount point".

I have tried using "device_name", instead of the "symboliclinkname". No errors, but no progress.

Can anyone see what could be wrong? Are the IOCTL calls used the ones I am supposed to use?
I don't suppose FileSpy can capture requests to MountMgr? Would be most useful to be able to see NTFS communication when mounting a sub-volume.

Could our AI overlords not be as imposing as we thought?

(Edit, it was eating too many backslashes, so put in code blocks)

2

Sorry, need to back this up...What are you trying to do exactly? Is this all just from user mode using existing devices? Or are you trying to do this from kernel mode using your own custom device objects?

3

From kernel, my own device objects.

4

Ah interesting. Always saw MountMgr as this dark secret complicated part, with a tightly controlled unknowable database. Then I came across mountmgr.c on github and it really is quite small, and easy to follow. The database even appears to be in the Registry. Let's have another go at this.

6

So mountmgr is certainly happier, but I must still be doing something wrong. I was hoping I would even be able to run "diskpart; list volume" and see my device.

What are the secrets needed to be considered a fully fledged mounted volume?

7

Volumes in Windows have a Device Interface GUID of GUID_DEVINTERFACE_VOLUME. This is what's used to search for volumes either directly (via SetupDi) or indirectly (via WMI).

In terms of terminology, these volumes may or may not have Mount Points (e.g. C:) and may or may not have file systems mounted on them.

8

So perhaps it's not how I present my strings to MountMgr that goes wrong, with further arguing with chatgpt, this came out:

 chatgpt suggests:

To use PnPUtil, open a Command Prompt with administrative privileges and use the following command:
    pnputil /enum-devices /connected
OK having just created my first volume to attempt to mount, and pnputil says:
Instance ID:                ROOT\OpenZFS\0000
Device Description:         Unknown
Class Name:                 Unknown
Class GUID:                 Unknown
Manufacturer Name:          Unknown
Status:                     Problem
Problem Code:               28 (0x1C) [CM_PROB_FAILED_INSTALL]
Check the Event Viewer for any error messages or warnings related to your driver or device installation.

The EventViewer has:
Driver Name: oem3.inf
Class Guid: {71a27cdd-812a-11d0-bec7-08002be2092f}
Service: OpenZFS
Lower Filters: 
Upper Filters: 
Problem: 0x0
Problem Status: 0xC00000E5
The 0xC00000E5 status code is STATUS_IO_TIMEOUT, indicating that a time-out occurred while attempting to install
the driver. This suggests that there might be an issue during the initialization or setup of the device, 
particularly when creating the DeviceObject and preparing it for use as a volume.

Is there a way to get even more information out of the problem? Certainly nothing is slow, but I think mountmgr.c timeout is 1s, but presumably it is more about what I reply.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.