RtlVolumeDeviceToDosName() doesn't return for USB 2.0-based disk devices

NTFSD
1

Hi All,

Our product includes a filter driver which is used to track the pathnames of
files opened by processes. We’ve noticed a problem that seems to only occur
when hooking disks attached to the machine by a USB 2.0 connection. I’m
hoping somebody might be able to suggest what’s causing this.

We register a completion routine for IRP_MN_MOUNT_VOLUME IRPs. In this
completion routine we first check that we’re at PASSIVE_LEVEL and then call
RtlVolumeDeviceToDosName() on the device object to obtain the drive letter
of the newly mounted volume. This normally works fine, but for disks
connected by USB 2.0, RtlVolumeDeviceToDosName() hangs and never returns.
Connecting the same disk hardware to a USB 1.1 port does not produce this
error.

Can anybody suggest what I should do to debug this? Your help would be
greatly appreciated.

Thanks,

Richard Cartwright
Spherical Technology Pty Ltd
www.sphericaltech.com

2

> connected by USB 2.0, RtlVolumeDeviceToDosName() hangs and never

returns.

What will “!process 0 7” say?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

3

> > connected by USB 2.0, RtlVolumeDeviceToDosName() hangs and never

>returns.

What will “!process 0 7” say?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Hi Maxim,

I did a process dump as you suggested. Below is the stack trace of the
relevant system thread, edited for readability. STHook is my driver. My call
to RtlVolumeDeviceToDosName calls through to IoVolumeDeviceToDosName which
ends up in MountMgr!MountMgrDeviceControl waiting on something which never
happens. What can I make of this?

Thanks,
Richard

nt!KiSwapContext+0x2f (FPO: [EBP 0xf8b88300] [0,0,4])
nt!KiSwapThread+0x6b (FPO: [0,0,0])
nt!KeWaitForSingleObject+0x1c2
MountMgr!MountMgrDeviceControl+0x2e
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IoVolumeDeviceToDosName+0x155
STHook!STGetVolumeName+0x4b
STHook!STMountComplete+0xe7
nt!IopfCompleteRequest+0xa2
Fastfat!FatCompleteRequest_Real+0x49
Fastfat!FatCommonFileSystemControl+0x58
Fastfat!FatFsdFileSystemControl+0x85
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
STHook!STHookSystemHookDispatch+0x27c
STHook!STDispatch+0x42
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
sr!SrFsControlMount+0x9b
sr!SrFsControl+0x4b
nt!IopfCallDriver+0x31 (FPO: [0,0,0])
nt!IopMountVolume+0x1b9
nt!IopCheckVpbMounted+0x5e
nt!IopParseDevice+0x3c6
nt!ObpLookupObjectName+0x53c
nt!ObOpenObjectByName+0xea
nt!IopCreateFile+0x407
nt!IoCreateFile+0x8e
nt!NtOpenFile+0x27
nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ f8b88bc0)
nt!ZwOpenFile+0x11 (FPO: [6,0,0])
VolSnap!VspDeleteDiffAreaFilesWorker+0xa0
nt!IopProcessWorkItem+0x13
nt!ExpWorkerThread+0xef
nt!PspSystemThreadStartup+0x34
nt!KiThreadStartup+0x16

4

This thread might be helpful
http://www.osronline.com/showThread.cfm?link=65760

“Richard Cartwright” wrote in message
news:xxxxx@ntfsd…
> Hi All,
>
> Our product includes a filter driver which is used to track the pathnames
> of
> files opened by processes. We’ve noticed a problem that seems to only
> occur
> when hooking disks attached to the machine by a USB 2.0 connection. I’m
> hoping somebody might be able to suggest what’s causing this.
>
> We register a completion routine for IRP_MN_MOUNT_VOLUME IRPs. In this
> completion routine we first check that we’re at PASSIVE_LEVEL and then
> call
> RtlVolumeDeviceToDosName() on the device object to obtain the drive letter
> of the newly mounted volume. This normally works fine, but for disks
> connected by USB 2.0, RtlVolumeDeviceToDosName() hangs and never returns.
> Connecting the same disk hardware to a USB 1.1 port does not produce this
> error.
>
> Can anybody suggest what I should do to debug this? Your help would be
> greatly appreciated.
>
> Thanks,
>
> Richard Cartwright
> Spherical Technology Pty Ltd
> www.sphericaltech.com
>
>

5

Hi Lyndon,

Thanks for your help. I guess that pretty much explains it.

Regards,
Richard

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Lyndon J. Clarke
Sent: Thursday, 18 May 2006 9:38 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] RtlVolumeDeviceToDosName() doesn’t return for USB
2.0-based disk devices

This thread might be helpful
http://www.osronline.com/showThread.cfm?link=65760

“Richard Cartwright” wrote in message
> news:xxxxx@ntfsd…
> > Hi All,
> >
> > Our product includes a filter driver which is used to track the
> pathnames
> > of
> > files opened by processes. We’ve noticed a problem that seems to only
> > occur
> > when hooking disks attached to the machine by a USB 2.0 connection. I’m
> > hoping somebody might be able to suggest what’s causing this.
> >
> > We register a completion routine for IRP_MN_MOUNT_VOLUME IRPs. In this
> > completion routine we first check that we’re at PASSIVE_LEVEL and then
> > call
> > RtlVolumeDeviceToDosName() on the device object to obtain the
> drive letter
> > of the newly mounted volume. This normally works fine, but for disks
> > connected by USB 2.0, RtlVolumeDeviceToDosName() hangs and
> never returns.
> > Connecting the same disk hardware to a USB 1.1 port does not
> produce this
> > error.
> >
> > Can anybody suggest what I should do to debug this? Your help would be
> > greatly appreciated.
> >
> > Thanks,
> >
> > Richard Cartwright
> > Spherical Technology Pty Ltd
> > www.sphericaltech.com
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@spherical.com.au
> To unsubscribe send a blank email to xxxxx@lists.osr.com

6

It turns out the when I followed Neal’s recommendations in the thread that
Lyndon referred me to (below), the problem still occurs.

I now do the following:

  1. In my completion routine for IRP_MN_MOUNT_VOLUME I attach my filter
    device object and cache the storage-stack device object in my device
    extension.

  2. In the first IRP_MJ_CREATE on the volume, I use
    IoVolumeDeviceToDosName().

  3. I find the same problem for each of the two volumes (partitions) on my
    USB 2.0 hard disk. ie IoVolumeDeviceToDosName() hangs and never returns.

Any further suggestions would be greatly appreciated.

Thanks,
Richard Cartwright
Spherical Technology Pty Ltd
www.sphericaltech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Lyndon J. Clarke
Sent: Thursday, 18 May 2006 9:38 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] RtlVolumeDeviceToDosName() doesn’t return for USB
2.0-based disk devices

This thread might be helpful
http://www.osronline.com/showThread.cfm?link=65760

“Richard Cartwright” wrote in message
> news:xxxxx@ntfsd…
> > Hi All,
> >
> > Our product includes a filter driver which is used to track the
> pathnames
> > of
> > files opened by processes. We’ve noticed a problem that seems to only
> > occur
> > when hooking disks attached to the machine by a USB 2.0 connection. I’m
> > hoping somebody might be able to suggest what’s causing this.
> >
> > We register a completion routine for IRP_MN_MOUNT_VOLUME IRPs. In this
> > completion routine we first check that we’re at PASSIVE_LEVEL and then
> > call
> > RtlVolumeDeviceToDosName() on the device object to obtain the
> drive letter
> > of the newly mounted volume. This normally works fine, but for disks
> > connected by USB 2.0, RtlVolumeDeviceToDosName() hangs and
> never returns.
> > Connecting the same disk hardware to a USB 1.1 port does not
> produce this
> > error.
> >
> > Can anybody suggest what I should do to debug this? Your help would be
> > greatly appreciated.
> >
> > Thanks,
> >
> > Richard Cartwright
> > Spherical Technology Pty Ltd
> > www.sphericaltech.com
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@spherical.com.au
> To unsubscribe send a blank email to xxxxx@lists.osr.com