Interfacing with the nt mount manager - invalid device returned for vol arrival

NTDEV
1

Hello all,

I’m refreshing some legacy code we have that creates a virtual drive to access our file-based storage containers.

As part of the refresh I’m trying to use the mount manager. As I understand it, the process I need to undergo is this:

  1. Create my device (IoCreateDeviceSecure in my case)
  2. Send a volume arrival notification (MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION) to mountmgr.sys with the nt device path for the device - in my case \Devices\Antony\mounteddrive1
  3. That should generate some mount manager IOCTLs for my device:
    IOCTL_MOUNTDEV_QUERY_DEVICE_NAME
    IOCTL_MOUNTDEV_QUERY_UNIQUE_ID
    IOCTL_MOUNTDEV_QUERY_SUGGESTED_LINK_NAME
  4. I can then issue a IOCTL_MOUNTMGR_CREATE_POINT containing the device name and the NT-namespace win32 name I’d like it to link to - so \Devices\Antony\mounteddrive1 and \DosDevices\Z:

This is the procedure I’m currently working through - however, I’ve noticed a strange problem occuring. I realised that my initial unicodestring.length property was returning 4 for the device name, so the mountmgr was not receiving the full device string. However, it did succesfully complete 3 and create a \DosDevices\Volume{GUID} device, not symlinked to anything.

I corrected that, and now I receive C0000034 errors - object not found.

So, my questions then are:

  1. Since my device exists and using the old DefineDosDevice mechanism I can mount it, what am I missing? Anything?
  2. Is my understanding of how to interface with the mount manager correct?

Thanks for your help,

Antony

2

I really dislike the idea of bumping my thread, but, can nobody really help?

3

Basically, all your steps are correct.
Do you say that IOCTL_MOUNTMGR_CREATE_POINT fails from 0xC0000034 or is it
different fn which fails?

I’d suggest you to recheck IOCTL_MOUNTMGR_CREATE_POINT input buffer +
buffersize. See how you handle IOCTL_MOUNTDEV_QUERY_DEVICE_NAME and
IOCTL_MOUNTDEV_QUERY_UNIQUE_ID, especially in the case where output buffer
is smaller than your name (you must return sizeof + STATUS_BUFFER_OVERFLOW).

You can also debug mountmgr code which returns that error code - it’s not
too hard, especially with public symbols.

Petr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
antony.vennard+xxxxx@gmail.com
Sent: Wednesday, April 25, 2012 4:43 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Interfacing with the nt mount manager - invalid device
returned for vol arrival

Hello all,

I’m refreshing some legacy code we have that creates a virtual drive to
access our file-based storage containers.

As part of the refresh I’m trying to use the mount manager. As I understand
it, the process I need to undergo is this:

  1. Create my device (IoCreateDeviceSecure in my case) 2. Send a volume
    arrival notification (MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION) to mountmgr.sys
    with the nt device path for the device - in my case
    \Devices\Antony\mounteddrive1 3. That should generate some mount manager
    IOCTLs for my device:
    IOCTL_MOUNTDEV_QUERY_DEVICE_NAME
    IOCTL_MOUNTDEV_QUERY_UNIQUE_ID
    IOCTL_MOUNTDEV_QUERY_SUGGESTED_LINK_NAME
  2. I can then issue a IOCTL_MOUNTMGR_CREATE_POINT containing the device
    name and the NT-namespace win32 name I’d like it to link to - so
    \Devices\Antony\mounteddrive1 and \DosDevices\Z:

This is the procedure I’m currently working through - however, I’ve noticed
a strange problem occuring. I realised that my initial unicodestring.length
property was returning 4 for the device name, so the mountmgr was not
receiving the full device string. However, it did succesfully complete 3 and
create a \DosDevices\Volume{GUID} device, not symlinked to anything.

I corrected that, and now I receive C0000034 errors - object not found.

So, my questions then are:

  1. Since my device exists and using the old DefineDosDevice mechanism I can
    mount it, what am I missing? Anything?
  2. Is my understanding of how to interface with the mount manager correct?

Thanks for your help,

Antony

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Hello,

Thanks for your reply. It’s the MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION that fails with c0000034. Looking through the calls with pdb, the structure of the message being sent seems fine - as compared to the truecrypt driver, which achieves the same thing.

I am wondering, therefore, if it is something to do with the device itself - it’s just created with a call to IoCreateDeviceSecure. I’ve looked over various samples and they all seem to make reference to physical device objects - I am wondering if there’s something I’m missing in this area?

My other line of investigation is to check if the subdirectory, or permissions, are interfering in some way.

Thanks for any assistance you can provide :slight_smile: Much appreciated.

(For what it’s worth, the CREATE_POINT call really is broken - it’s not writing the fields to the correct places - but with the notification message failing anyway, I’ve still got a problem even after I’ve fixed it).

Antony

5

Ok, quick update - I’ve fixed both VOLUME_ARRIVAL_NOTIFICATION (returns 0 and ??\Volume{guid} appears in WinObj) which appears to be right.

QuerySugggestedLinkName needs to return an overflow if the mount manager doesn’t allocate a big enough buffer - now doing this too (I think that’s what you alluded to).

Finally, create mount point - still a no-go unfortunately. I’ve reviewed the structure I was creating and it was wrong before; now it looks like this:

…$….D.o.s.
D.e.v.i.c.e.s..
R.:..D.e.v.i.c.
e..A.n.t.o.n.y.
.D.i.s.k.1…

Which is comparable to what truecrypt is doing:

db fffff88006192200
fffff88006192200 08 00 1c 00 24 00 30 00-5c 00 44 00 6f 00 73 00 ....$.0.\.D.o.s. fffff88006192210 44 00 65 00 76 00 69 00-63 00 65 00 73 00 5c 00 D.e.v.i.c.e.s..
fffff88006192220 49 00 3a 00 5c 00 44 00-65 00 76 00 69 00 63 00 I.:.\.D.e.v.i.c. fffff88006192230 65 00 5c 00 54 00 72 00-75 00 65 00 43 00 72 00 e..T.r.u.e.C.r.
fffff88006192240 79 00 70 00 74 00 56 00-6f 00 6c 00 75 00 6d 00 y.p.t.V.o.l.u.m. fffff88006192250 65 00 49 00 00 00 00 00-00 00 00 00 00 00 00 00 e.I…
fffff88006192260 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ fffff88006192270 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 …

However, I’m now getting C0000033 STATUS_OBJECT_NAME_INVALID as a response to this request.

Since the data in the CREATE_POINT structure looks valid, I can only conclude I must be setting the offsets incorrectly - but I’m not sure how I should be setting them. Truecrypt, before making its call to mountmgr.sys, sets the length of the input (r9 register) to 54 - but I can’t see how that number relates to the structure.

I’ve also tried altering the devices from \Device\Antony\Disk1 to \Device\AntonyDisk1 just in case - no different.

I don’t think I’m very far off.

Antony