Привет Всем.
Помогите плз разобраться с проблемой.
Имею драйвер, который аттачу к \Device\Tcp. В драйвере отслеживаю коннекты на удаленные узлы. Все ок.
Но если я запускаю драйвер, делаю прогой коннект (telnet в моем случае), коннект не рву и выгружаю драйвер, то потом, когда закрываю telnet выскакивает BSOD
Следующего содержания:
Вообще странно, что после выгрузки драйвера его еще вызвать система пытается. В процедуре выгрузки делаю следующее:
VOID DriverUnload(IN PDRIVER_OBJECT pDriverObject)
{
UNICODE_STRING ustrDeviceName; // Имя нашего устройства
UNICODE_STRING ustrSymbolicLink; // Имя символической ссылки нашего устройства
// Получаем расширение устройства
PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)pDriverObject->DeviceObject->DeviceExtension;
// Инициализируем имя устройства
RtlInitUnicodeString(&ustrDeviceName, DEVICE_NAME);
// Инициализируем символическую ссылку на устройства
RtlInitUnicodeString(&ustrSymbolicLink, SYM_LINK_NAME);
// Отсоединяем наш драйвер от стека
IoDetachDevice(pDevExt->pDeviceObject);
// Удаляем символическую ссылку
IoDeleteSymbolicLink(&ustrSymbolicLink);
// Удаляем устройство
IoDeleteDevice(g_pDeviceObject);
// Очищаем список
ClearConnInfoList();
// Освобождаем память под спин-лок
ExFreePoolWithTag(g_pClientConnToSrvListSpinLock, KSPIN_LOCK_POOL_TAG);
DbgPrint("DriverUnload: SUCCESS");
}
P>А разве такой вариант на висте и на 64 битных платформах работать будет?
Битность платформы тут не причем — целостность объекта DRIVER_OBJECT не контроллируется ни одной платформой. С вистой интереснее — если в стеке устройства \Device\tcp отсутствуют фильтры, то трафик идет вообще минуя это устройство. Для преодоления этого можно использовать такой "трик": сделать два драйвера — один с пустым фильтром над устройством \Device\tcp ( присутствие фильтра заставит драйвер afd.sys использовать TDI ), другой — с патчем мажор тейбл. Второй драйвер можно будет перегружать ( в принципе ).
Здравствуйте, TarasCo, Вы писали:
TC>Битность платформы тут не причем — целостность объекта DRIVER_OBJECT не контроллируется ни одной платформой. С вистой интереснее — если в стеке устройства \Device\tcp отсутствуют фильтры, то трафик идет вообще минуя это устройство. Для преодоления этого можно использовать такой "трик": сделать два драйвера — один с пустым фильтром над устройством \Device\tcp ( присутствие фильтра заставит драйвер afd.sys использовать TDI ), другой — с патчем мажор тейбл. Второй драйвер можно будет перегружать ( в принципе ).
Благодарю!
Еще маленький вопросик...
Всегда отправляемые приложением TCP-данные я смогу посмотреть в своем фильтре при наступлении TDI_SEND?
P>Благодарю! P>Еще маленький вопросик... P>Всегда отправляемые приложением TCP-данные я смогу посмотреть в своем фильтре при наступлении TDI_SEND?
netbt.sys может использовать т.н "Direct Send" — вызывать напрямую ф. tcpip.sys, полученную ранее через IOCTL_TDI_QUERY_DIRECT_SEND_HANDLER. "Обычный" сокетный трафик, проходящий через afd.sys за этим замечен не был.
Здравствуйте, TarasCo, Вы писали:
TC>netbt.sys может использовать т.н "Direct Send" — вызывать напрямую ф. tcpip.sys, полученную ранее через IOCTL_TDI_QUERY_DIRECT_SEND_HANDLER. "Обычный" сокетный трафик, проходящий через afd.sys за этим замечен не был.
P>Я пока на Висте не пробовал. Там тоже данные могу увидеть в TDI_SEND?
Да если вы установите фильтр в стек устройства \device\tcp — все будет точно также. Одно отличие — в висте ( в релизе, в первой бэте было не так ) устройство \Device\tcp обслуживает также TCPv6 трафик, в XP для этого есть отдельное устройство — \device\tcp6. Ну и стоит помнить, что драйвер tdx.sys нужен только для совместимости со старыми драйверами и возможно в Windows 7 его ( и соответственно TDI вообще ) не будет.
Здравствуйте, TarasCo, Вы писали:
TC>Невозможно сделать выгружаемый TDI фильтр. Аминь.
TC>Если хочется все таки выгружаться, надо делать не фильтр, а патчить мажор тейбл у \Driver\tcp.
TC>>Невозможно сделать выгружаемый TDI фильтр. Аминь. TC>>Если хочется все таки выгружаться, надо делать не фильтр, а патчить мажор тейбл у \Driver\tcp. F>Еще как возможно.
Голословно как-то. Давай конкретику, раз такой умный.
Здравствуйте, x64, Вы писали:
TC>>>Невозможно сделать выгружаемый TDI фильтр. Аминь. TC>>>Если хочется все таки выгружаться, надо делать не фильтр, а патчить мажор тейбл у \Driver\tcp. F>>Еще как возможно.
x64>Голословно как-то. Давай конкретику, раз такой умный.
Не вижу большой проблемы ....
Нужно дождаться пока сетевые запросы, которые прошли через фильтр завершатся
( закроются порты, снимутся callback-и ... ) и тогда делать Detach и выгружаться
Другое дело, что есть например тонкости : типа ресурсы могут и не освободиться
а в-общем и целом когда-то давно у меня был TDI фильтр который благополучно выгружался.
Видишь ёжика? Нет? А он есть!
F>а в-общем и целом когда-то давно у меня был TDI фильтр который благополучно выгружался.
А я-то уж подумал нам сейчас расскажут ну хотя бы о какой-нибудь очередной недокументированной багофиче, которой можно определённым образом воспользоваться, чтобы сделать свой legacy-фильтр относительно стабильно выгружаемым. Ну ты на досуге подумай, к примеру, что будет, когда придёт запрос к \Device\Tcp при условии, если третий драйвер прицепился сверху на твой FiDO-девайс до того, как ты выгрузился. Подсказка: DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS.
Моё мнение: фактически при определённых условиях legacy-фильтр может быть выгружаемым, но для этого требуется уж слишком много совпадений, как то: девайсы драйвера должны быть самыми верхними на стеке, должен быть вызван соответствующий callback из fast I/O (хотя fast I/O в TDI-фильтрах не поддерживается) и т.п. Конечно, можно вспомнить ручную правку структур I/O менеджера и прочую гадость, но... В общем виде задача не решаема. Аминь.
x64>А я-то уж подумал нам сейчас расскажут ну хотя бы о какой-нибудь очередной недокументированной багофиче, которой можно определённым образом воспользоваться, чтобы сделать свой legacy-фильтр относительно стабильно выгружаемым. Ну ты на досуге подумай, к примеру, что будет, когда придёт запрос к \Device\Tcp при условии, если третий драйвер прицепился сверху на твой FiDO-девайс до того, как ты выгрузился. Подсказка: DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS.
x64>Моё мнение: фактически при определённых условиях legacy-фильтр может быть выгружаемым, но для этого требуется уж слишком много совпадений, как то: девайсы драйвера должны быть самыми верхними на стеке, должен быть вызван соответствующий callback из fast I/O (хотя fast I/O в TDI-фильтрах не поддерживается) и т.п. Конечно, можно вспомнить ручную правку структур I/O менеджера и прочую гадость, но... В общем виде задача не решаема. Аминь.
Все так
Но, с моей точки зрения, стакан скорее наполовину полон ... С помощью зубила и молотка в-принципе дотачивается что угодно
Все зависит от постановки задачи.
F>Но, с моей точки зрения, стакан скорее наполовину полон ...
Он не полон ни на половину ни на сотую часть. Задача не решаема, обсуждать тут нечего.
F>Все зависит от постановки задачи.
Задача "написать выгружаемый legacy-фильтр" не решаема. И даже с кучей дополнительных условий и формулировок никто не будет эту задачу решать, ибо бессмысленно, всё равно всё будет держаться на соплях.
С помощью зубила и молотка в-принципе дотачивается что угодно 