Is FastIoDispatch pointer required in a legacy filter?

Hi everyone.

I’ve been looking at a crash dump from a customer who has his own legacy file system filter. The crash happens inside IopWriteFile when I/O Manager tries to get the FastIoWrite function pointer from DriverObject→FastIoDispatch, which is NULL.

As far as I recall, fast I/O routines are optional, but the table itself must be allocated and initialized.

I could not find anything at Rajeev Nagar’s book that was specific for filters. I also looked at the old SFILTER sample that checks the FastIoDispatch pointer before reaching the routine on it.

I know legacy filters are out of support and every filter should be ported to a filter manager solution, but I’m curious about what are the system requirements when dealing with a legacy filter in this case.

Any thoughts?

Short answer is, yes, you need to have valid Fast I/O entry points if you’re a legacy filter. The I/O Manager assumes them if the File Object has had caching established on it (i.e. CcInitializeCacheMap).

The way Fast I/O works is that the I/O Manager looks at the FastIoDispatch of the device/driver object at the top of the stack. So, if there are no filters the Fast I/O would go to the file system. Once you add a filter the Fast I/O goes to the filter’s driver object. In a legacy filter the “right” thing to do then is to pass these all through to the underlying driver object. Nowadays Filter Manager handles all that stuff.

1 Like