Всем доброго времени суток. Не подскажете ли, как решить следующую задачу? Имеется legacy-драйвер, работающий в Windows 2000. Драйверу передаётся имя диска (диск на USB Flash), нужно определить производителя и серийный номер флешки (серийный номер у флешки заведомо есть). На данный момент: драйвер раскрывает символьную ссылку и получает имя диска типа \Device\Harddisk4\DP(1)0-0+7, получает DeviceObject и FileObject через IoGetDeviceObjectPointer... а дальше начинаются сложности (для меня, поскольку за драйверы взялся недавно). IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER - не работает в Windows 2000. IOCTL_STORAGE_QUERY_PROPERTY - возвращает VendorId, ProductId и ProductRevision, но SerialNumber пустой (кстати для IDE-дисков номер выдаётся - если кому надо решить такую задачу). IOCTL_INTERNAL_USB_SUBMIT_URB с USB_DEVICE_DESCRIPTOR_TYPE (для последующего USB_STRING_DESCRIPTOR_TYPE) - выдаёт STATUS_NOT_SUPPORTED. Прежде чем написать, внимательно просмотрел этот форум и форумы на схожие темы, однако полученная информация не помогла решить задачу. Если есть описание её решения - где его найти? (Просьба не предлагать абстрактные направления типа "читай MSDN" или "поищи у Walter Oney").
Если не секрет в каком виде вы получаете VendorId и ProductId??? В виде цифр (01fe) или в виде (Flash Disk, ну или что то типа того)???
Устраивает??? Если нет, то информацию можно получить у DeviceObject-а от usbhub (в цифровом виде имеется ввиду, там же можно получить и серийный номер) А вот как связать стек устройств в единую цепочку, пока и для меня загадка......((((
Не устраивает. Нужно получить и серийный номер флешки, а он, как было сказано, пустой в этом запросе. От хаба можно получить нужную информацию посредством IOCTL_USB_GET_NODE_CONNECTION_INFORMATION, но: 1) как получить правильный хаб (их может быть несколько) именно для данной флешки? 2) как определить номер ноды флешки для указания его в ConnectionIndex при запросе хабу?
Здесь можно так сказать идти от обратного.....) Ловить момент подключения флэшки и запоминать соответствующий DeviceObject от хаба., от него и узнавать всю инфу об устройстве
Поидее можно было бы просто ребутнуть ее))))) Но потом проследить весь стек устройств всеравно сложно (точнее у меня пока это не получилось). Ну а если нельзя ребутить то тогда хз.
IoRegisterPlugAndPlayNotification с флагом PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES Делал в обратном порядке. Для подключенной флешки через стек PnP определял и кэшировал точки монтирования (DEVICE_OBJECT для партишна). Далее все просто - по запросу смотрим кэш и выдаем DEVICE_OBJECT для флешки, к ней строим URB. В принципе никто не мешает пойти в обратную сторону: открываем девайс партишна, через Vpb переходим к DO файловой системы, далее через списки чайлдов и сиблингов можно спуститься по стеку к fdo девайса. Самый простой способ определить алгоритм - в WinDbg заюзать !devnode и пройтись по стеку
Если можно чуть по подробнее..... ну а если еще и вырезки из исходников приложишь то ваще МЕГАРЕСПЕКТ!!!! ) В принципе не важно сверху вниз или снизу вверх, главное связать DEVICE_OBJECT от хаба и DEVICE_OBJECT от диска (disk.sys)
devobj - указатель на DO для флешки (в PnPNotify обработчике получаем имя и референсим его). Тогда: devnode = devobj->DeviceObjectExtension->AttachedTo->DeviceObjectExtension->DeviceNode будет пнпшным devnod`ом для первого партишна на флешке. Дальше пусть devnode1 = devnode->FirstChild, тогда циклом по devnode1->NextSibling пока != NULL перечисляем все маунт-пойнты для флешки (ссылка на devnode для точки монтирования будет devnode1->FirstChild). В devnode есть ссылка на DeviceObject, но смещение различно для разных версий виндов (по сервис-пакам не различается). DeviceObject для devnode1->FirstChild будет DO для точки монтирования, т.е. объектом mountmgr. Про Vpb в предыдущем посте я что-то не то сказал, он здесь не нужен. В обратную сторону не пробовал спускаться, но по аналогии, думаю, все пройдет.
Может и поздно, но все же: кто тебе сказал, что у флешки обязательно д.б. серийный номер. у подавляющего большинства флех до 2006 его нет))) да и у новых тоже такое бывает))
[bold]asm007[/bold] Если он нулевой, это не значит, что его нет Раньше было рекомендовано заполнять это поле и все вендоры дружно на рекомендацию клали. Сейчас стали требовать, поэтому можно вполне полагаться на то, что поле заполнено, и просто посылать на фиг все девайсы с нулевым с/н
Хочу еще раз поднять эту тему. Все это верно. Но есть одно НО!!! это схема работает только если на usb флэшке файловая система FAT. На больших usb дисках идет ф.с. NTFS. Здесь добавляется драйвер ftdisk (драйвер повышения отказоустройчивости). И теперь если раньше devnode выглядел Код (Text): kd> !DevNode 8119ff28 1 DevNode 0x8119ff28 for PDO 0x811afe90 Parent 0x811a0d48 Sibling 0000000000 Child 0x8116ad68 InstancePath is "USB\Vid_0c76&Pid_0005\6&38c5a47&0&1" ServiceName is "USBSTOR" Flags (0x00040458) DNF_PROCESSED, DNF_ENUMERATED, DNF_ADDED, DNF_NO_RESOURCE_REQUIRED, DNF_STARTED CapabilityFlags (0x00000010) Removable DevNode 0x8116ad68 for PDO 0x8117aed0 Parent 0x8119ff28 Sibling 0000000000 Child 0x811c8aa8 InstancePath is "USBSTOR\Disk&Ven_JetFlash&Prod_TS128MJF2A&Rev_1.00\7&311ad6ac&0" ServiceName is "disk" Flags (0x00040458) DNF_PROCESSED, DNF_ENUMERATED, DNF_ADDED, DNF_NO_RESOURCE_REQUIRED, DNF_STARTED DevNode 0x811c8aa8 for PDO 0x8119bd90 Parent 0x8116ad68 Sibling 0000000000 Child 0000000000 InstancePath is "STORAGE\RemovableMedia\8&2aa6674d&0&RM" TargetDeviceNotify List - f 0xe24f0c88 b 0xe24f0c88 Flags (0x00040458) DNF_PROCESSED, DNF_ENUMERATED, DNF_ADDED, DNF_NO_RESOURCE_REQUIRED, DNF_STARTED CapabilityFlags (0x00000180) SilentInstall, RawDeviceOK то с NTFS будет тоже самое но без последнего узла. Вообщем суть вопроса в следующем: драйвер ftdisk является своего рода прослойкой между драйвером файловой системы и драйвером disk.sys, как можно связать между собой драйвера ftdisk и disk? может кто знает или есть какие то предположения, заранее спасибо!
