Fast I/O Functions not being called

I'm developing a file system filter driver - same base functionality as
FileSpy, but without all the useless bloat, complication, inefficiency and
fluff.

I have set up my fast I/O table in Driver Entry ... allocated it, checked
and double checked every last field (including size ... it's 0x70), assigned
it by

DriverObject->FastIoDispatch = fastIoDispatch;

I broke into KD and double checked every address. No crashes are occurring,
no bugs are occurring. DriverObject exits with its FastIoDispatch field
assigned to my very valid table. But no fast I/O functions ever get called.
When I open non-Microsoft programs, all the disk I/O passes through my filter
driver. The very first line of every fast I/O dispatch is a DbgPrint
statement. I even tried DbgBreakPoint and a straight inline assembler _asm
int 3. They're never called. The standard dispatch routines are being
called just fine. Any program I run that comes from Microsoft leaves my
driver dead in the water. There is no activity. All other programs run all
disk I/O through my driver - when the disk is hit. I understand the
difference; when fast I/O is used and why, but I don't understand why such a
simple process is not working.

Assuming nothing is wrong with my code, it must be something I'm leaving out
(although this process is not difficult; how many things are there to leave
out?). So I must be doing something stupid to disable these calls.
Conceptually, are there any ideas?

David
Thu Aug 23 20:39:48 CDT 2007

Wrong newsgroup for file systems and file system filters.

--
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation


"Dakota Ridge" <DakotaRidge@discussions.microsoft.com> wrote in message
news:6D49B105-62C5-4622-9FB7-D4A593D33D96@microsoft.com...
> I'm developing a file system filter driver - same base functionality as
> FileSpy, but without all the useless bloat, complication, inefficiency and
> fluff.
>
> I have set up my fast I/O table in Driver Entry ... allocated it, checked
> and double checked every last field (including size ... it's 0x70),
> assigned
> it by
>
> DriverObject->FastIoDispatch = fastIoDispatch;
>
> I broke into KD and double checked every address. No crashes are
> occurring,
> no bugs are occurring. DriverObject exits with its FastIoDispatch field
> assigned to my very valid table. But no fast I/O functions ever get
> called.
> When I open non-Microsoft programs, all the disk I/O passes through my
> filter
> driver. The very first line of every fast I/O dispatch is a DbgPrint
> statement. I even tried DbgBreakPoint and a straight inline assembler
> _asm
> int 3. They're never called. The standard dispatch routines are being
> called just fine. Any program I run that comes from Microsoft leaves my
> driver dead in the water. There is no activity. All other programs run
> all
> disk I/O through my driver - when the disk is hit. I understand the
> difference; when fast I/O is used and why, but I don't understand why such
> a
> simple process is not working.
>
> Assuming nothing is wrong with my code, it must be something I'm leaving
> out
> (although this process is not difficult; how many things are there to
> leave
> out?). So I must be doing something stupid to disable these calls.
> Conceptually, are there any ideas?
>

Maxim
Sat Aug 25 13:59:32 CDT 2007

Is FastIoCheckIfPossible ever called?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Dakota Ridge" <DakotaRidge@discussions.microsoft.com> wrote in message
news:6D49B105-62C5-4622-9FB7-D4A593D33D96@microsoft.com...
> I'm developing a file system filter driver - same base functionality as
> FileSpy, but without all the useless bloat, complication, inefficiency and
> fluff.
>
> I have set up my fast I/O table in Driver Entry ... allocated it, checked
> and double checked every last field (including size ... it's 0x70), assigned
> it by
>
> DriverObject->FastIoDispatch = fastIoDispatch;
>
> I broke into KD and double checked every address. No crashes are occurring,
> no bugs are occurring. DriverObject exits with its FastIoDispatch field
> assigned to my very valid table. But no fast I/O functions ever get called.
> When I open non-Microsoft programs, all the disk I/O passes through my filter
> driver. The very first line of every fast I/O dispatch is a DbgPrint
> statement. I even tried DbgBreakPoint and a straight inline assembler _asm
> int 3. They're never called. The standard dispatch routines are being
> called just fine. Any program I run that comes from Microsoft leaves my
> driver dead in the water. There is no activity. All other programs run all
> disk I/O through my driver - when the disk is hit. I understand the
> difference; when fast I/O is used and why, but I don't understand why such a
> simple process is not working.
>
> Assuming nothing is wrong with my code, it must be something I'm leaving out
> (although this process is not difficult; how many things are there to leave
> out?). So I must be doing something stupid to disable these calls.
> Conceptually, are there any ideas?
>