driver verifier error on unload for handles closed on IRP_MJ_CLOSE

Hi all,

I have a minifilter which reparses to another file in pre_create, storing the original file handle in ECP then stream_handle_context of reparsed file.
The original file handle is released on IRP_MJ_CLOSE where a stream_handle_context exists.
When I unload the filter manually, driver verifier obviously bug checks the system for leaked FILE_OBJECT structures.

Is it ok to have such design?(closing handles in IRP_MJ_CLOSE)

If it is ok, then in this situation I think its better to remove the filter unload callback. Am I right?

If this is the case then you may need to check the graceful shutdown case too in this case only sometimes you may get a crash on win 8 and above.
Why don’t you deny the unload at the first place.???

/nT

On what OS did you test with verifier ?
I believe you should not get the BSOD.
Make you if you used FltCreate to use the FltClose not ZwClose and the other way around for the
IoCreate/ZwCreate etc… use ZwClose not FltClose for the handles or otherwise it will confuse verifier.
Nevertheless you should not have the leak.
If you want to make sure you are not leaking references/handles or whatever, verifier also gives you the leaked objects. Check in the debugger to see if they are valid FO’s or not.
If they appear not to be valid FO’s it means that verifier cannot handle your scenario, otherwise you leaked something.

Cheers,
Gabriel
www.kasardia.com

Thanks for replying,

> Why don’t you deny the unload at the first place.???
I think I should do this as well. I asked if this is correct or not. so you think I should deny unload too.

@Gabriel,

It is not a bug as I mentioned. It is just my design. I do not close the handles before unload. I just asked if my design is correct or not