Hi,
i try to map a volume name (something like C:, D:, E:, etc.) to a device instance id, but i couldnt find any information somewhere how to do that. What i want to do is to “restart” the USB pen as if it was disconnected and reconnected to the usb port. I know that i can send a DIF_PROPERTYCHANGE to the device but i need to know what device instance id the volume is to do that. I do have the handle to the volume and maybe i can do that with a IOCTL of some sort to restart/reinitiate the usb pen but i dont know how. What i am doing is that i change the usb pens (flash drive pen) content and i have to plug it out and plug it back to the usb slot it is currently connected without user intervention so the operating system can mount/put it back to the system and assign a drive letter to it.
Thanks in advance
K.
>, but i couldnt find any information somewhere how to do that. What i want to do is to “restart” the USB >pen as if it was disconnected and reconnected to the usb port.
Why? what is “restart”? for all hardware, disconnect+reconnect is restart, so, the drive was already restarted.
What do you want to do? send some URBs to the flash drive, given its drive letter?
Then sorry, what you need is to write a filter driver, which will filter both USBSTOR’s FDO both as lower (to be able to meddle with the URBs) and upper (to be able to see the PDO children) filter, and then also filter all USBSTOR-created PDOs (just to build the PDO-FDO association which is hidden from the kmode code otherwise), and then match the drive letter with the USBSTOR PDO (storage LUN) using IOCTL_STORAGE_GET_DEVICE_NUMBER called from both side.
Sorry, all of this is because there is no CM_Get_Parent in kmode, and also due to moronic design decision in Windows of making the simple single-partition disk volumes to be another PnP tree separate from the PnP tree of the physical disks, so matching by IOCTL_STORAGE_GET_DEVICE_NUMBER or IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS is the only solution of building a relation between the two.
If you can afford user-mode components here - then there is no need in complex filtering of USBSTOR, just get the LUN PDO (by IOCTL_STORAGE_GET_DEVICE_NUMBER matching) and call CM_Get_Parent on it.
If being “drive-letter-aware” is not a requirement, then you can just create a lower filter for USBSTOR FDO and send your URBs from there.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi Maxim,
thank you for your detailed answer. What i (simply) would like to do is to map a drive name like “F:” (where F: can be a class of a storage device like CDROM, DISKDRIVE, etc.) to a specific device which is seen in my Device Information Set like this:
“DeviceFriendlyName”,“takeMS colorline USB Device”
“DeviceNameAndFriendlyName”,“Laufwerk [takeMS colorline USB Device]”
“DeviceClassPnPEnumeratorName”,“DiskDrive”
“DeviceCompatibleIDs”,“USBSTOR\Disk;USBSTOR\RAW”
“DeviceHardwareIDs”,“USBSTOR\DisktakeMS__colorline_______8.07;USBSTOR\DisktakeMS__colorline_______;USBSTOR\DisktakeMS__;USBSTOR\takeMS__colorline_______8;takeMS__colorline_______8;USBSTOR\GenDisk;GenDisk”
“DeviceEnumeratorType”,“USBSTOR”
“DevicePhysicalDeviceObjectName”,“\Device\000000aa”
“DeviceHardwareID”,“USBSTOR\DisktakeMS__colorline_______8.07”
“DeviceNodeStatus”,“CR_SUCCESS”
“DeviceInstanceID”,“USBSTOR\DISK&VEN_TAKEMS&PROD_COLORLINE&REV_8.07\2AA0D7AB&0”
“DeviceSoftwareRegistryKey”,“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4d36e967-e325-11ce-bfc1-08002be10318}\0002”
“DeviceHardwareRegistryKey”,“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\DISK&VEN_TAKEMS&PROD_COLORLINE&REV_8.07\2AA0D7AB&0”
“DeviceVendorID”,“TAKEMS”
This is the device as seen on file system and object manager:
Name: F:
Device Name: \Device\HarddiskVolume7
Mount Point: \?\Volume{b6374871-fa9d-11e0-880b-837128c089b7}\
Now i would like to find a way to map the “F:” to the Device in the Device Information Set. This has to be done from user mode, no kernel mode code available.
regards
K.
Something interessting:
MSDN gives this definition of the STORAGE_DEVICE_NUMBER structure:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff566974(v=vs.85).aspx
typedef struct _STORAGE_DEVICE_NUMBER {
DEVICE_TYPE DeviceType;
ULONG DeviceNumber;
ULONG PartitionNumber;
} STORAGE_DEVICE_NUMBER, *PSTORAGE_DEVICE_NUMBER;
but this is what the latest WinSDK headers show me (SDK 7.1):
typedef struct _STORAGE_DEVICE_NUMBER {
//
// The FILE_DEVICE_XXX type for this device.
//
DEVICE_TYPE DeviceType;
//
// The number of this device
//
DWORD DeviceNumber;
//
// If the device is partitionable, the partition number of the device.
// Otherwise -1
//
DWORD PartitionNumber;
} STORAGE_DEVICE_NUMBER, *PSTORAGE_DEVICE_NUMBER;
Both have the same size in memory, but what is the correct defintion?
K.
> Both have the same size in memory, but what is the correct defintion?
ULONG and DWORD are the same.
Just the kernel-mode headers use ULONG and not DWORD.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Both definitions are correct *as long as both come directly from
Microsoft and maintained by their owners*.
DWORD and ULONG is “almost” same type for the MS compiler.
– pa
On 24-Oct-2011 17:40, xxxxx@arcor.de wrote:
Something interessting:
MSDN gives this definition of the STORAGE_DEVICE_NUMBER structure:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff566974(v=vs.85).aspx
typedef struct _STORAGE_DEVICE_NUMBER {
DEVICE_TYPE DeviceType;
ULONG DeviceNumber;
ULONG PartitionNumber;
} STORAGE_DEVICE_NUMBER, *PSTORAGE_DEVICE_NUMBER;
but this is what the latest WinSDK headers show me (SDK 7.1):
typedef struct _STORAGE_DEVICE_NUMBER {
//
// The FILE_DEVICE_XXX type for this device.
//
DEVICE_TYPE DeviceType;
//
// The number of this device
//
DWORD DeviceNumber;
//
// If the device is partitionable, the partition number of the device.
// Otherwise -1
//
DWORD PartitionNumber;
} STORAGE_DEVICE_NUMBER, *PSTORAGE_DEVICE_NUMBER;
Both have the same size in memory, but what is the correct defintion?
K.