Based on the results of the experiment, I came to the conclusion that it is more optimal to remove minifilter support and assign it to the user and accurately documenting the behavior.
The reasons:
unjustified complication of linking - it is necessary to provide stubs for unused (but included into the precompiled library) functions from fltmgr.lib by using the undocumented #pragma comment (linker, "alternatename = ...");
сalling FltRegisterFilter()after DriverEntry forces the driver developer to completing (possibly expensive) initialization in the DriverEntry();
controlling FltStartFiltering() and `FltUnregisterFilter() by the driver developer becomes not flexible enough;
the interaction of FltUnregisterFilter() and the CRT mechanisms for destroying static objects becomes really opaque.
Based on the results of the experiment, I came to the conclusion that it is more optimal to remove minifilter support and assign it to the user and accurately documenting the behavior. The reasons:
#pragma comment (linker, "alternatename = ...")
;FltRegisterFilter()
after DriverEntry forces the driver developer to completing (possibly expensive) initialization in theDriverEntry()
;FltStartFiltering()
and `FltUnregisterFilter() by the driver developer becomes not flexible enough;FltUnregisterFilter()
and the CRT mechanisms for destroying static objects becomes really opaque.