Описание ситуации:
Под W2K SP4 запущен драйвер фильтра ФС. По control code посланному из user mode драйвер приатачивается к диску C: . Вся его работа на данном этапе заключается в подключении, собственно к диску, и пропускании через себя запросов, ничего при этом над ними не выполняя. Шаблоном для всех необходимых действий явл. функции из FileSpy.
Проблема:
Запуск проходит успешно, драйвер успешно приатачивается к диску C:, и, как можно проследить через softice, пропускает запросы далее, вниз по стеку. Однако, при попытке открытия любого файла, расположенного скажем на раб. столе, или создании нового, скажем, в блокноте появляется SoftIce с Page Fault 0Eh Fault=0000. В стеке вызовов последним вызовом явл ntoskrnl!NtReadFile. Прикрученный к драйверу driver verifier ничего не дает. После сворачивания softice по F5 система не выпадает в BSOD(!) а продолжает "работать" при 100%-ной загрузке CPU.
Что здесь не так?! С какой стороны смотреть на проблему, учитывая что до присоединения драйвера все работает нормально.
Re: PAGE FAULT 0Eh
От:
Аноним
Дата:
08.03.05 14:46
Оценка:
Здравствуйте, altx, Вы писали:
A>Описание ситуации: A>Под W2K SP4 запущен драйвер фильтра ФС. По control code посланному из user mode драйвер приатачивается к диску C: . Вся его работа на данном этапе заключается в подключении, собственно к диску, и пропускании через себя запросов, ничего при этом над ними не выполняя. Шаблоном для всех необходимых действий явл. функции из FileSpy. A>Проблема: A>Запуск проходит успешно, драйвер успешно приатачивается к диску C:, и, как можно проследить через softice, пропускает запросы далее, вниз по стеку. Однако, при попытке открытия любого файла, расположенного скажем на раб. столе, или создании нового, скажем, в блокноте появляется SoftIce с Page Fault 0Eh Fault=0000. В стеке вызовов последним вызовом явл ntoskrnl!NtReadFile. Прикрученный к драйверу driver verifier ничего не дает. После сворачивания softice по F5 система не выпадает в BSOD(!) а продолжает "работать" при 100%-ной загрузке CPU. A>Что здесь не так?! С какой стороны смотреть на проблему, учитывая что до присоединения драйвера все работает нормально.
Ну в том, что система вижила после page fault'а ничего удивительного нет. Бывает такое. И как правило при этом у нее крутится вечный цикл внутри.
С устройством filespy я незнаком. Поэтому могу высказать только общие соображения:
0) Пропустить запрос совсем ничего не выполняя все-таки нельзя Как минимум нужно Irp Stack Location поправить.
Вот такое там есть ?
// Get this driver out of the driver stack and get to the next driver as
// quickly as possible.
Irp->CurrentLocation++;
Irp->Tail.Overlay.CurrentStackLocation++;
// Now call the appropriate file system driver with the request.return IoCallDriver( filterDevExt->lowerFSDeviceObject, Irp );
1) Почему упала... нужно смотреть на инструкции, вызвавшие падение. Разобраться, что это за кривой параметр и откуда он там взялся.
Если есть SRC (те самые), посмотреть, на чем упала и как мы могли дойти до такой жизни.
2) Какой был последний запрос ? Логи фильтр ведет ?
3) А сам filespy работает ?
Если работает, искать 33 различия.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, altx, Вы писали:
A>>Описание ситуации: A>>Под W2K SP4 запущен драйвер фильтра ФС. По control code посланному из user mode драйвер приатачивается к диску C: . Вся его работа на данном этапе заключается в подключении, собственно к диску, и пропускании через себя запросов, ничего при этом над ними не выполняя. Шаблоном для всех необходимых действий явл. функции из FileSpy. A>>Проблема: A>>Запуск проходит успешно, драйвер успешно приатачивается к диску C:, и, как можно проследить через softice, пропускает запросы далее, вниз по стеку. Однако, при попытке открытия любого файла, расположенного скажем на раб. столе, или создании нового, скажем, в блокноте появляется SoftIce с Page Fault 0Eh Fault=0000. В стеке вызовов последним вызовом явл ntoskrnl!NtReadFile. Прикрученный к драйверу driver verifier ничего не дает. После сворачивания softice по F5 система не выпадает в BSOD(!) а продолжает "работать" при 100%-ной загрузке CPU. A>>Что здесь не так?! С какой стороны смотреть на проблему, учитывая что до присоединения драйвера все работает нормально.
А>Ну в том, что система вижила после page fault'а ничего удивительного нет. Бывает такое. И как правило при этом у нее крутится вечный цикл внутри.
А>0) Пропустить запрос совсем ничего не выполняя все-таки нельзя Как минимум нужно Irp Stack Location поправить.
А>Вот такое там есть ?
А>
А>// Get this driver out of the driver stack and get to the next driver as
А>// quickly as possible.
Irp->>CurrentLocation++;
Irp->>Tail.Overlay.CurrentStackLocation++;
А>// Now call the appropriate file system driver with the request.
А>return IoCallDriver( filterDevExt->lowerFSDeviceObject, Irp );
А>
есть такое
IoSkipCurrentIrpStackLocation( Irp );
//
// Now call the next file system driver with the request.
//
status = IoCallDriver( ((PFILESPY_DEVICE_EXTENSION)DeviceObject->DeviceExtension)->AttachedToDeviceObject, Irp );
А>1) Почему упала... нужно смотреть на инструкции, вызвавшие падение. Разобраться, что это за кривой параметр и откуда он там взялся.
А>Если есть SRC (те самые), посмотреть, на чем упала и как мы могли дойти до такой жизни.
так вот как бы так узнать после какого-такого действия драйвера происходит page fault ведь последняя команда в стеке ntoskrnl!NtReadFile...
...кроме того, у меня есть подозрение насчет FAST I/O — я не включал его поддержку в свой драйвер может быть из-за этого ветка FAST I/O всего стека драйверов остается не задействованной и выдает такую муть?! или FAST I/O это не обязалово ?! (хотя на osr пишут что вроде как обяз...?!)
Здравствуйте, altx, Вы писали:
A>...кроме того, у меня есть подозрение насчет FAST I/O — я не включал его поддержку в свой драйвер может быть из-за этого ветка FAST I/O всего стека драйверов остается не задействованной и выдает такую муть?! или FAST I/O это не обязалово ?! (хотя на osr пишут что вроде как обяз...?!)
Здравствуйте, _cb_, Вы писали:
__>Здравствуйте, altx, Вы писали:
A>>...кроме того, у меня есть подозрение насчет FAST I/O — я не включал его поддержку в свой драйвер может быть из-за этого ветка FAST I/O всего стека драйверов остается не задействованной и выдает такую муть?! или FAST I/O это не обязалово ?! (хотя на osr пишут что вроде как обяз...?!)
__>для фильтров fs поддержка fast io обязательна.
__>cb.
в том же примере filespy описано множество функций поддерживающих fast i/o. Вопрос — какие из них нужно описать обязательно, и с каким минимальным кодом — можно ли скажем для всех описать только "pass through" как это сделано скажем для fastioreadfile:
Здравствуйте, altx, Вы писали:
A>в том же примере filespy описано множество функций поддерживающих fast i/o. Вопрос — какие из них нужно описать обязательно, и с каким минимальным кодом — можно ли скажем для всех описать только "pass through" как это сделано скажем для fastioreadfile:
список обязательных обработчиков fast io я сейчас не помню, для простоты я бы определил их все.
на сколько я помню для всех обработчиков достаточно реализовать логику pass through.
Здравствуйте, altx, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
Это был я
А>>Здравствуйте, altx, Вы писали:
A>>>Описание ситуации: A>>>Под W2K SP4 запущен драйвер фильтра ФС. По control code посланному из user mode драйвер приатачивается к диску C: . Вся его работа на данном этапе заключается в подключении, собственно к диску, и пропускании через себя запросов, ничего при этом над ними не выполняя. Шаблоном для всех необходимых действий явл. функции из FileSpy. A>>>Проблема: A>>>Запуск проходит успешно, драйвер успешно приатачивается к диску C:, и, как можно проследить через softice, пропускает запросы далее, вниз по стеку. Однако, при попытке открытия любого файла, расположенного скажем на раб. столе, или создании нового, скажем, в блокноте появляется SoftIce с Page Fault 0Eh Fault=0000. В стеке вызовов последним вызовом явл ntoskrnl!NtReadFile. Прикрученный к драйверу driver verifier ничего не дает. После сворачивания softice по F5 система не выпадает в BSOD(!) а продолжает "работать" при 100%-ной загрузке CPU. A>>>Что здесь не так?! С какой стороны смотреть на проблему, учитывая что до присоединения драйвера все работает нормально.
А>>Ну в том, что система вижила после page fault'а ничего удивительного нет. Бывает такое. И как правило при этом у нее крутится вечный цикл внутри.
A>
А>>0) Пропустить запрос совсем ничего не выполняя все-таки нельзя Как минимум нужно Irp Stack Location поправить.
А>>Вот такое там есть ?
А>>
А>>// Get this driver out of the driver stack and get to the next driver as
А>>// quickly as possible.
Irp->>>CurrentLocation++;
Irp->>>Tail.Overlay.CurrentStackLocation++;
А>>// Now call the appropriate file system driver with the request.
А>>return IoCallDriver( filterDevExt->lowerFSDeviceObject, Irp );
А>>
A>есть такое A> IoSkipCurrentIrpStackLocation( Irp ); A> // A> // Now call the next file system driver with the request. A> //
A> status = IoCallDriver( ((PFILESPY_DEVICE_EXTENSION)DeviceObject->DeviceExtension)->AttachedToDeviceObject, Irp );
Ага, это одно и тоже.
A>
А>>1) Почему упала... нужно смотреть на инструкции, вызвавшие падение. Разобраться, что это за кривой параметр и откуда он там взялся.
А>>Если есть SRC (те самые), посмотреть, на чем упала и как мы могли дойти до такой жизни.
A>так вот как бы так узнать после какого-такого действия драйвера происходит page fault ведь последняя команда в стеке ntoskrnl!NtReadFile... A>...кроме того, у меня есть подозрение насчет FAST I/O — я не включал его поддержку в свой драйвер может быть из-за этого ветка FAST I/O всего стека драйверов остается не задействованной и выдает такую муть?! или FAST I/O это не обязалово ?! (хотя на osr пишут что вроде как обяз...?!)
Ну поддержку сделать надо...
А что касается стека — смотрим где мы вообще находимся в момент падения, в какой ф-ции, на какой инструкции, что при этом в регистрах, откуда это что-то туда пришло (такой себе back trace в уме .
Для этого можно windbg использовать. Он даже сам умеет необходимые символы с MS тянуть. http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
Когда узнали, что это за ф-ция, пытаемся идентифицировать это место, сопоставить с исходниками На крайний случай — с входными параметрами или локальными переменными (типа там [EBP+/-xxxx]), дизассембрер натравить в конце концов...
Здравствуйте, altx, Вы писали:
A>Описание ситуации: A>Под W2K SP4 запущен драйвер фильтра ФС. По control code посланному из user mode драйвер приатачивается к диску C: . Вся его работа на данном этапе заключается в подключении, собственно к диску, и пропускании через себя запросов, ничего при этом над ними не выполняя. Шаблоном для всех необходимых действий явл. функции из FileSpy. A>Проблема: A>Запуск проходит успешно, драйвер успешно приатачивается к диску C:, и, как можно проследить через softice, пропускает запросы далее, вниз по стеку. Однако, при попытке открытия любого файла, расположенного скажем на раб. столе, или создании нового, скажем, в блокноте появляется SoftIce с Page Fault 0Eh Fault=0000. В стеке вызовов последним вызовом явл ntoskrnl!NtReadFile. Прикрученный к драйверу driver verifier ничего не дает. После сворачивания softice по F5 система не выпадает в BSOD(!) а продолжает "работать" при 100%-ной загрузке CPU. A>Что здесь не так?! С какой стороны смотреть на проблему, учитывая что до присоединения драйвера все работает нормально.
хм...действительно нужно было прикрутить обработку fast i/o с логикой pass through — типа все заработало, по крайней мере прежних казусов нет(тьфу * 3)
ВСЕМ СПАСИБО ЗА УЧАСТИЕ!