IoVolumeDeviceToDosName & USB hard disk

NTFSD
1

i am calling IoVolumeDeviceToDosName from InstanceSetup routine. It’s working fine for all the USB hard disks.
But i encountered a problem with Seagate USB hard disk only on Windows XP SP2. The “Safely Remove Hardware” icon
in the system tray becomes unresponsive whenever i plug in that USB hard disk.

i also checked with swapbuffers sample in wdk which calls RtlVolumeDeviceToDosName from InstanceSetup routine.
it also produces the same problem.

i checked with !locks command which produces following output

kd> !thread 822667a0
THREAD 822667a0 Cid 07b4.07d8 Teb: 7ffdc000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
8233fe54 Semaphore Limit 0x1
IRP List:
845def68: (0006,0094) Flags: 40000070 Mdl: 00000000
82a32e70: (0006,0190) Flags: 40000884 Mdl: 00000000
Not impersonating
DeviceMap e1004460
Owning Process 0 Image:
Attached Process 81ef7190 Image: FreeAgentService.exe
Wait Start TickCount 41390 Ticks: 7680 (0:00:02:00.000)
Context Switch Count 444
UserTime 00:00:00.000
KernelTime 00:00:00.234
Win32 Start Address 0x00409510
Start Address 0x7c810856
Stack Init ba319000 Current ba318500 Base ba319000 Limit ba316000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16
ChildEBP RetAddr Args to Child
ba318518 8050017a 82266810 822667a0 804f99be nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
ba318524 804f99be 00000000 8233fe38 845def68 nt!KiSwapThread+0x46 (FPO: [0,0,0])
ba31854c f84b7d5e 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
ba318578 804eddf9 845defd8 8233fe54 806d02e8 MountMgr!MountMgrDeviceControl+0x2e (FPO: [2,1,4])
ba318588 8064b5a8 00000103 00000200 00000000 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
ba3185ac 804f0be3 00000000 ba318854 00000000 nt!IovCallDriver+0xa0 (FPO: [0,4,0])
ba3187fc ba525768 821d1220 81871c88 80531934 nt!IoVolumeDeviceToDosName+0x155 (FPO: [2,143,4])
ba318820 bae45121 ba318854 00000005 00000008 mydrv!MyInstanceSetup+0xd8 (FPO: [Non-Fpo]) (CONV: stdcall)
ba318838 bae3cebb ba318854 00000005 00000008 fltMgr!FltvInstanceSetup+0x1b (FPO: [4,0,0])
ba31886c bae3d442 821e6c10 00000005 80544080 fltMgr!FltpDoInstanceSetupNotification+0x4b (FPO: [2,6,4])
ba3188cc bae3d7cd 81da7248 81feac10 00000005 fltMgr!FltpInitInstance+0x272 (FPO: [Non-Fpo])
ba31893c bae3d8d8 81da7248 81feac10 00000005 fltMgr!FltpCreateInstanceFromName+0x295 (FPO: [7,17,0])
ba3189a4 bae4482d 81da7248 81feac10 00000005 fltMgr!FltpEnumerateRegistryInstances+0xf4 (FPO: [Non-Fpo])
ba3189f4 bae3c0da 81feac10 82288ee8 81e4a918 fltMgr!FltpDoFilterNotificationForNewVolume+0xf5 (FPO: [Non-Fpo])
ba318a28 804eddf9 82288ee8 82a32fdc 806d02e8 fltMgr!FltpCreate+0x16a (FPO: [2,7,4])
ba318a38 8064b5a8 82a32e80 82a32e70 8211e038 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
ba318a5c 805773bc 821d1208 81dc0ebc ba318c04 nt!IovCallDriver+0xa0 (FPO: [0,4,0])
ba318b3c 805b365e 821d1220 00000000 81dc0e18 nt!IopParseDevice+0xa58 (FPO: [Non-Fpo])
ba318bc4 805afb3f 00000000 ba318c04 00000040 nt!ObpLookupObjectName+0x56a (FPO: [11,19,4])
ba318c18 8056a133 00000000 00000000 5b534101 nt!ObOpenObjectByName+0xeb (FPO: [7,5,4])
ba318c94 8056aaaa 00bca90c c0100080 00bca8ac nt!IopCreateFile+0x407 (FPO: [Non-Fpo])
ba318cf0 8056d17c 00bca90c c0100080 00bca8ac nt!IoCreateFile+0x8e (FPO: [14,3,0])
ba318d30 8053c808 00bca90c c0100080 00bca8ac nt!NtCreateFile+0x30 (FPO: [11,0,0])
ba318d30 7c90eb94 00bca90c c0100080 00bca8ac nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ ba318d64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
00bca904 00000000 00000000 00000000 00000000 0x7c90eb94

kd> !thread 8235d3c8
THREAD 8235d3c8 Cid 0004.0038 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
81e13288 SynchronizationEvent
8235d4b8 NotificationTimer
Not impersonating
DeviceMap e1004460
Owning Process 0 Image:
Attached Process 8235f660 Image: System
Wait Start TickCount 48923 Ticks: 147 (0:00:00:02.296)
Context Switch Count 844
UserTime 00:00:00.000
KernelTime 00:00:00.546
Start Address nt!ExpWorkerThread (0x80533cd0)
Stack Init f88ff000 Current f88fe528 Base f88ff000 Limit f88fc000 Call 0
Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f88fe540 8050017a 8235d438 8235d3c8 804f99be nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
f88fe54c 804f99be 00000000 822ac10c 8235d3c8 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f88fe574 80531544 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
f88fe5b0 805319a3 822ac000 81b29430 f88fe5dc nt!ExpWaitForResource+0xd2 (FPO: [0,5,0])
f88fe5c0 bae44466 822ac10c 00000001 81883d00 nt!ExAcquireResourceExclusiveLite+0x6f (FPO: [2,0,0])
f88fe5dc bae37820 81b29430 822ac10c 00000000 fltMgr!FltpLinkVolume+0x6a (FPO: [2,0,4])
f88fe638 bae3beb4 81ade770 81883c48 82103020 fltMgr!FltpAttachDeviceObject+0xf4 (FPO: [Non-Fpo])
f88fe6b4 bae3c1b8 82103020 82cf4de0 81e4a918 fltMgr!FltpFsControlMountVolume+0x1de (FPO: [Non-Fpo])
f88fe6e0 804eddf9 82103020 82cf4de0 806d02e8 fltMgr!FltpFsControl+0x58 (FPO: [2,6,4])
f88fe6f0 8064b5a8 818fbd58 82cf4de0 82103020 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f88fe714 80575da7 f88fe864 806d0298 818fbd58 nt!IovCallDriver+0xa0 (FPO: [0,4,0])
f88fe764 804f4009 c000014f f88fe800 00000000 nt!IopMountVolume+0x1b9 (FPO: [5,15,0])
f88fe794 80576d2a 822c41e0 818fbd58 f88fe8c8 nt!IopCheckVpbMounted+0x5b (FPO: [4,2,4])
f88fe884 805b365e 818fbd58 00000000 81e6d008 nt!IopParseDevice+0x3c6 (FPO: [Non-Fpo])
f88fe90c 805afb3f 00000000 f88fe94c 00000240 nt!ObpLookupObjectName+0x56a (FPO: [11,19,4])
f88fe960 8056a133 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb (FPO: [7,5,4])
f88fe9dc 8056aaaa f88feb84 0012019f f88feb5c nt!IopCreateFile+0x407 (FPO: [Non-Fpo])
f88fea38 8056d17c f88feb84 0012019f f88feb5c nt!IoCreateFile+0x8e (FPO: [14,3,0])
f88fea78 8053c808 f88feb84 0012019f f88feb5c nt!NtCreateFile+0x30 (FPO: [11,0,0])
f88fea78 804fd569 f88feb84 0012019f f88feb5c nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f88feaac)
f88feb1c f84b10c8 f88feb84 0012019f f88feb5c nt!ZwCreateFile+0x11 (FPO: [11,0,0])
f88feb88 f84b4ca5 e1e2d901 00000000 82103a88 MountMgr!OpenRemoteDatabase+0xf8 (FPO: [2,11,4])
f88fed0c f84af45b 82103a9c 81d71688 8233fd80 MountMgr!ReconcileThisDatabaseWithMasterWorker+0x11d (FPO: [1,90,4])
f88fed60 8056abd5 8233fd80 8233fe38 8055a1fc MountMgr!WorkerThread+0x111 (FPO: [2,15,4])
f88fed74 80533dd0 81d71688 00000000 8235d3c8 nt!IopProcessWorkItem+0x13 (FPO: [1,0,4])
f88fedac 805c4a28 81d71688 00000000 00000000 nt!ExpWorkerThread+0x100 (FPO: [1,8,0])
f88feddc 80540fa2 80533cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Has anyone encountered such problem?? any pointers will be appreciated.

2

Uuh, this sounds like an issue with MountMgr locks which was not fixed in XP SP3 :frowning: (if upgrading to SP3 works
for you, then it’s probably not the issue, but it could be just the randomness)
Namely, calling IoVolumeDeviceToDosName is NOT safe in InstanceSetup routine :frowning: Check threads started by me on
this list, one of them was related to it. There is no real solution :frowning: IIRC, even getting the GUID name instead of
the DOS name (which is what any modern mini-filter should do) didn’t help.

Dejan.

xxxxx@rediffmail.com wrote:

i am calling IoVolumeDeviceToDosName from InstanceSetup routine. It’s working fine for all the USB hard disks.
But i encountered a problem with Seagate USB hard disk only on Windows XP SP2. The “Safely Remove Hardware” icon
in the system tray becomes unresponsive whenever i plug in that USB hard disk.

i also checked with swapbuffers sample in wdk which calls RtlVolumeDeviceToDosName from InstanceSetup routine.
it also produces the same problem.

i checked with !locks command which produces following output

kd> !thread 822667a0
THREAD 822667a0 Cid 07b4.07d8 Teb: 7ffdc000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
8233fe54 Semaphore Limit 0x1
IRP List:
845def68: (0006,0094) Flags: 40000070 Mdl: 00000000
82a32e70: (0006,0190) Flags: 40000884 Mdl: 00000000
Not impersonating
DeviceMap e1004460
Owning Process 0 Image:
> Attached Process 81ef7190 Image: FreeAgentService.exe
> Wait Start TickCount 41390 Ticks: 7680 (0:00:02:00.000)
> Context Switch Count 444
> UserTime 00:00:00.000
> KernelTime 00:00:00.234
> Win32 Start Address 0x00409510
> Start Address 0x7c810856
> Stack Init ba319000 Current ba318500 Base ba319000 Limit ba316000 Call 0
> Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16
> ChildEBP RetAddr Args to Child
> ba318518 8050017a 82266810 822667a0 804f99be nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
> ba318524 804f99be 00000000 8233fe38 845def68 nt!KiSwapThread+0x46 (FPO: [0,0,0])
> ba31854c f84b7d5e 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
> ba318578 804eddf9 845defd8 8233fe54 806d02e8 MountMgr!MountMgrDeviceControl+0x2e (FPO: [2,1,4])
> ba318588 8064b5a8 00000103 00000200 00000000 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
> ba3185ac 804f0be3 00000000 ba318854 00000000 nt!IovCallDriver+0xa0 (FPO: [0,4,0])
> ba3187fc ba525768 821d1220 81871c88 80531934 nt!IoVolumeDeviceToDosName+0x155 (FPO: [2,143,4])
> ba318820 bae45121 ba318854 00000005 00000008 mydrv!MyInstanceSetup+0xd8 (FPO: [Non-Fpo]) (CONV: stdcall)
> ba318838 bae3cebb ba318854 00000005 00000008 fltMgr!FltvInstanceSetup+0x1b (FPO: [4,0,0])
> ba31886c bae3d442 821e6c10 00000005 80544080 fltMgr!FltpDoInstanceSetupNotification+0x4b (FPO: [2,6,4])
> ba3188cc bae3d7cd 81da7248 81feac10 00000005 fltMgr!FltpInitInstance+0x272 (FPO: [Non-Fpo])
> ba31893c bae3d8d8 81da7248 81feac10 00000005 fltMgr!FltpCreateInstanceFromName+0x295 (FPO: [7,17,0])
> ba3189a4 bae4482d 81da7248 81feac10 00000005 fltMgr!FltpEnumerateRegistryInstances+0xf4 (FPO: [Non-Fpo])
> ba3189f4 bae3c0da 81feac10 82288ee8 81e4a918 fltMgr!FltpDoFilterNotificationForNewVolume+0xf5 (FPO: [Non-Fpo])
> ba318a28 804eddf9 82288ee8 82a32fdc 806d02e8 fltMgr!FltpCreate+0x16a (FPO: [2,7,4])
> ba318a38 8064b5a8 82a32e80 82a32e70 8211e038 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
> ba318a5c 805773bc 821d1208 81dc0ebc ba318c04 nt!IovCallDriver+0xa0 (FPO: [0,4,0])
> ba318b3c 805b365e 821d1220 00000000 81dc0e18 nt!IopParseDevice+0xa58 (FPO: [Non-Fpo])
> ba318bc4 805afb3f 00000000 ba318c04 00000040 nt!ObpLookupObjectName+0x56a (FPO: [11,19,4])
> ba318c18 8056a133 00000000 00000000 5b534101 nt!ObOpenObjectByName+0xeb (FPO: [7,5,4])
> ba318c94 8056aaaa 00bca90c c0100080 00bca8ac nt!IopCreateFile+0x407 (FPO: [Non-Fpo])
> ba318cf0 8056d17c 00bca90c c0100080 00bca8ac nt!IoCreateFile+0x8e (FPO: [14,3,0])
> ba318d30 8053c808 00bca90c c0100080 00bca8ac nt!NtCreateFile+0x30 (FPO: [11,0,0])
> ba318d30 7c90eb94 00bca90c c0100080 00bca8ac nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ ba318d64)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 00bca904 00000000 00000000 00000000 00000000 0x7c90eb94
>
> kd> !thread 8235d3c8
> THREAD 8235d3c8 Cid 0004.0038 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
> 81e13288 SynchronizationEvent
> 8235d4b8 NotificationTimer
> Not impersonating
> DeviceMap e1004460
> Owning Process 0 Image:
> Attached Process 8235f660 Image: System
> Wait Start TickCount 48923 Ticks: 147 (0:00:00:02.296)
> Context Switch Count 844
> UserTime 00:00:00.000
> KernelTime 00:00:00.546
> Start Address nt!ExpWorkerThread (0x80533cd0)
> Stack Init f88ff000 Current f88fe528 Base f88ff000 Limit f88fc000 Call 0
> Priority 12 BasePriority 12 PriorityDecrement 0 DecrementCount 16
> ChildEBP RetAddr Args to Child
> f88fe540 8050017a 8235d438 8235d3c8 804f99be nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
> f88fe54c 804f99be 00000000 822ac10c 8235d3c8 nt!KiSwapThread+0x46 (FPO: [0,0,0])
> f88fe574 80531544 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
> f88fe5b0 805319a3 822ac000 81b29430 f88fe5dc nt!ExpWaitForResource+0xd2 (FPO: [0,5,0])
> f88fe5c0 bae44466 822ac10c 00000001 81883d00 nt!ExAcquireResourceExclusiveLite+0x6f (FPO: [2,0,0])
> f88fe5dc bae37820 81b29430 822ac10c 00000000 fltMgr!FltpLinkVolume+0x6a (FPO: [2,0,4])
> f88fe638 bae3beb4 81ade770 81883c48 82103020 fltMgr!FltpAttachDeviceObject+0xf4 (FPO: [Non-Fpo])
> f88fe6b4 bae3c1b8 82103020 82cf4de0 81e4a918 fltMgr!FltpFsControlMountVolume+0x1de (FPO: [Non-Fpo])
> f88fe6e0 804eddf9 82103020 82cf4de0 806d02e8 fltMgr!FltpFsControl+0x58 (FPO: [2,6,4])
> f88fe6f0 8064b5a8 818fbd58 82cf4de0 82103020 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
> f88fe714 80575da7 f88fe864 806d0298 818fbd58 nt!IovCallDriver+0xa0 (FPO: [0,4,0])
> f88fe764 804f4009 c000014f f88fe800 00000000 nt!IopMountVolume+0x1b9 (FPO: [5,15,0])
> f88fe794 80576d2a 822c41e0 818fbd58 f88fe8c8 nt!IopCheckVpbMounted+0x5b (FPO: [4,2,4])
> f88fe884 805b365e 818fbd58 00000000 81e6d008 nt!IopParseDevice+0x3c6 (FPO: [Non-Fpo])
> f88fe90c 805afb3f 00000000 f88fe94c 00000240 nt!ObpLookupObjectName+0x56a (FPO: [11,19,4])
> f88fe960 8056a133 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb (FPO: [7,5,4])
> f88fe9dc 8056aaaa f88feb84 0012019f f88feb5c nt!IopCreateFile+0x407 (FPO: [Non-Fpo])
> f88fea38 8056d17c f88feb84 0012019f f88feb5c nt!IoCreateFile+0x8e (FPO: [14,3,0])
> f88fea78 8053c808 f88feb84 0012019f f88feb5c nt!NtCreateFile+0x30 (FPO: [11,0,0])
> f88fea78 804fd569 f88feb84 0012019f f88feb5c nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f88feaac)
> f88feb1c f84b10c8 f88feb84 0012019f f88feb5c nt!ZwCreateFile+0x11 (FPO: [11,0,0])
> f88feb88 f84b4ca5 e1e2d901 00000000 82103a88 MountMgr!OpenRemoteDatabase+0xf8 (FPO: [2,11,4])
> f88fed0c f84af45b 82103a9c 81d71688 8233fd80 MountMgr!ReconcileThisDatabaseWithMasterWorker+0x11d (FPO: [1,90,4])
> f88fed60 8056abd5 8233fd80 8233fe38 8055a1fc MountMgr!WorkerThread+0x111 (FPO: [2,15,4])
> f88fed74 80533dd0 81d71688 00000000 8235d3c8 nt!IopProcessWorkItem+0x13 (FPO: [1,0,4])
> f88fedac 805c4a28 81d71688 00000000 00000000 nt!ExpWorkerThread+0x100 (FPO: [1,8,0])
> f88feddc 80540fa2 80533cd0 00000001 00000000 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> Has anyone encountered such problem?? any pointers will be appreciated.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system 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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

3

Thanks Dejan for your prompt reply. Is this the thread which you were talking about: http://www.osronline.com/showthread.cfm?link=166850

Going by that, so I have to shift the Call of IoVolumeDeviceToDosName to other place. I can think of two options…
1> I can queue a work item from InstanceSetup and call IoVolumeDeviceToDosName from it. Or
2> I can call IoVolumeDeviceToDosName in frist PreCreate Notification for that volume. Will this race with InstanceSetup?

Which method is better? Will there be any issues with respective methods?

4

The first PreCreate (required for pre-vista only) would be a good place to do it instead of InstanceSetup.

xxxxx@rediffmail.com wrote:

Thanks Dejan for your prompt reply. Is this the thread which you were talking about: http://www.osronline.com/showthread.cfm?link=166850

Going by that, so I have to shift the Call of IoVolumeDeviceToDosName to other place. I can think of two options…
1> I can queue a work item from InstanceSetup and call IoVolumeDeviceToDosName from it. Or
2> I can call IoVolumeDeviceToDosName in frist PreCreate Notification for that volume. Will this race with InstanceSetup?

Which method is better? Will there be any issues with respective methods?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

5

thnx again for reply Dejan.

Can anyone from Microsoft point out the Knowledge Base (KB) article for XP SP3 fix? i can tell the customer to download the hotfix if he doesn’t wish to apply XP SP3.

6

For the issue I had, there is no fix, even in SP3.
If you upgrade the system that has the issue to SP3 and it no longer has the issue, this is probably just accidental (or a different issue, fixed rather by some FltMgr
fix).

xxxxx@rediffmail.com wrote:

thnx again for reply Dejan.

Can anyone from Microsoft point out the Knowledge Base (KB) article for XP SP3 fix? i can tell the customer to download the hotfix if he doesn’t wish to apply XP SP3.

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

7

That’s not correct, because the first preCreate requests are from MountMgr
:wink: and it would lead to a deadlock.

The only known solution is this:

  • reference fltObjects->Volume and even DeviceObject (because of XP SP2 bug,
    fixed in Win7)
  • create a workitem, where in loop (because DOS letter may not be assigned
    yet):
  • call FltReferenceObject(pVolume), checks if volume isn’t draining
  • call FltGetDiskDeviceObject + IoVolumeDeviceToDosName
  • dereference everything and return

if you need source code, let me know.

Petr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Tuesday, February 22, 2011 2:45 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] IoVolumeDeviceToDosName & USB hard disk

The first PreCreate (required for pre-vista only) would be a good place
to do it instead of InstanceSetup.

xxxxx@rediffmail.com wrote:

Thanks Dejan for your prompt reply. Is this the thread which you were
talking about: http://www.osronline.com/showthread.cfm?link=166850

Going by that, so I have to shift the Call of IoVolumeDeviceToDosName to
other place. I can think of two options…
1> I can queue a work item from InstanceSetup and call
IoVolumeDeviceToDosName from it. Or
2> I can call IoVolumeDeviceToDosName in frist PreCreate Notification for
that volume. Will this race with InstanceSetup?

Which method is better? Will there be any issues with respective methods?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

8

The pre-create path should be safe, and I only know of one case (reproducible) where it does occur.
Care to post the code, so I can test that scenario? It would be wonderful if indeed it does fix the issue.

That’s not correct, because the first preCreate requests are from MountMgr :wink: and it would lead to a deadlock.

The only known solution is this:

  • reference fltObjects->Volume and even DeviceObject (because of XP SP2 bug,
    fixed in Win7)
  • create a workitem, where in loop (because DOS letter may not be assigned
    yet):
  • call FltReferenceObject(pVolume), checks if volume isn’t draining
  • call FltGetDiskDeviceObject + IoVolumeDeviceToDosName
  • dereference everything and return

if you need source code, let me know.

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

9

BTW, FltReferenceObject?:slight_smile:

Petr Kurtin wrote:

That’s not correct, because the first preCreate requests are from MountMgr
:wink: and it would lead to a deadlock.

The only known solution is this:

  • reference fltObjects->Volume and even DeviceObject (because of XP SP2 bug,
    fixed in Win7)
  • create a workitem, where in loop (because DOS letter may not be assigned
    yet):
  • call FltReferenceObject(pVolume), checks if volume isn’t draining
  • call FltGetDiskDeviceObject + IoVolumeDeviceToDosName
  • dereference everything and return

if you need source code, let me know.

Petr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Tuesday, February 22, 2011 2:45 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] IoVolumeDeviceToDosName & USB hard disk

The first PreCreate (required for pre-vista only) would be a good place
to do it instead of InstanceSetup.

xxxxx@rediffmail.com wrote:

> Thanks Dejan for your prompt reply. Is this the thread which you were
talking about: http://www.osronline.com/showthread.cfm?link=166850
>
> Going by that, so I have to shift the Call of IoVolumeDeviceToDosName to
other place. I can think of two options…
> 1> I can queue a work item from InstanceSetup and call
IoVolumeDeviceToDosName from it. Or
> 2> I can call IoVolumeDeviceToDosName in frist PreCreate Notification for
that volume. Will this race with InstanceSetup?
>
> Which method is better? Will there be any issues with respective methods?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

10

hey Dejan and Petr,

thank you for your input.

so i take it that the bug is fixed in Vista.

still i have few questions:

why is referencing DeviceObject required because anyway the DeviceObject is one of the parameter to workitem.

is it required to loop in the WorkItem. i am assuming that when in InstanceSetup the DOS name is already assigned. are there any cases where this assumption is wrong.

i am not clear about the step “call FltReferenceObject(pVolume), checks if volume isn’t draining”

once again thank you for your guidance.

11

> why is referencing DeviceObject required because anyway the DeviceObject
is one of the parameter to workitem.

it’s not if you use FltQueueGenericWorkItem (there’s FltObject as parameter,
but prior to Win7 only instance (or volume) objects are referenced, not
device object) - you can check it in windbg (!object command shows you ref
counters)

is it required to loop in the WorkItem. i am assuming that when in
InstanceSetup the DOS name is already assigned. are there any cases where
this assumption is wrong.

I don’t remember it exactly, but dos letter may not be already assigned
(workitem is created in instance setup callback, you can assert if it’s not
assigned and check the scenario).

i am not clear about the step “call FltReferenceObject(pVolume), checks if
volume isn’t draining”

When volume is being torn down, FltObjectReference returns
STATUS_FLT_DELETING_OBJECT error code. If I don’t check this state, next
APIs I call they may lead to bsods (FltGetVolumeContext,
FltGetDiskDeviceObject or IoVolumeDeviceToDosName).

I’m lucky we have a lot of customers so I was able to debug all
synchronization scenarios (with using winqual dumps).

I just sent you the source code to your email.

Petr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@rediffmail.com
Sent: Wednesday, February 23, 2011 10:48 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] IoVolumeDeviceToDosName & USB hard disk

hey Dejan and Petr,

thank you for your input.

so i take it that the bug is fixed in Vista.

still i have few questions:

why is referencing DeviceObject required because anyway the DeviceObject is
one of the parameter to workitem.

is it required to loop in the WorkItem. i am assuming that when in
InstanceSetup the DOS name is already assigned. are there any cases where
this assumption is wrong.

i am not clear about the step “call FltReferenceObject(pVolume), checks if
volume isn’t draining”

once again thank you for your guidance.

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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