Filter Verifier complaining about a completion context


I’m porting a legacy filter driver that does File Encryption to minifilter.

Lately I started using Driver Verifier (the old legacy driver failed passing it). I went solving various problems thanks to it.

But I’m stuck on this one, I’ve disabled all my FLT_OPERATION_REGISTRATION Callbacks so now I’m not filtering any I/Os and while I shutdown the computer this message appears :

FILTER VERIFIER WARNING: A filter has set a completion context for a callback data which will be
lost. Probable cause of this is that no post-operation callback was requested
or routine was registered for this operation or the request was being pended
or completed. (Filter = FFFFC902E4C59010 (driver_name_here), Cbd = FFFFC902E8705998)
Break, ignore, zap or remove ? 

In windbg I can print the FLT_CALLBACK_DATA structure and the FLT_IO_PARAMETER_BLOCK and the IO_STATUS_BLOCK :

kd> dt !_flt_callback_data FFFFC902E8705998
   +0x000 Flags            : 2
   +0x008 Thread           : 0xffffc902`e7f40040 _KTHREAD
   +0x010 Iopb             : 0xffffc902`e87059f0 _FLT_IO_PARAMETER_BLOCK
   +0x018 IoStatus         : _IO_STATUS_BLOCK
   +0x028 TagData          : (null) 
   +0x030 QueueLinks       : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`00000000 ]
   +0x040 QueueContext     : [2] (null) 
   +0x030 FilterContext    : [4] (null) 
   +0x050 RequestorMode    : 0 ''
kd> dx -id 0,0,ffffc902e2aaf080 -r1 ((FLTMGR!_FLT_IO_PARAMETER_BLOCK *)0xffffc902e87059f0)
((FLTMGR!_FLT_IO_PARAMETER_BLOCK *)0xffffc902e87059f0)                 : 0xffffc902e87059f0 [Type: _FLT_IO_PARAMETER_BLOCK *]
    [+0x000] IrpFlags         : 0x0 [Type: unsigned long]
    [+0x004] MajorFunction    : 0x10 [Type: unsigned char]
    [+0x005] MinorFunction    : 0x0 [Type: unsigned char]
    [+0x006] OperationFlags   : 0x0 [Type: unsigned char]
    [+0x007] Reserved         : 0x0 [Type: unsigned char]
    [+0x008] TargetFileObject : 0x0 [Type: _FILE_OBJECT *]
    [+0x010] TargetInstance   : 0xffffc902e69c1010 [Type: _FLT_INSTANCE *]
    [+0x018] Parameters       [Type: _FLT_PARAMETERS]
kd> dx -id 0,0,ffffc902e2aaf080 -r1 (*((FLTMGR!_IO_STATUS_BLOCK *)0xffffc902e87059b0))
(*((FLTMGR!_IO_STATUS_BLOCK *)0xffffc902e87059b0))                 [Type: _IO_STATUS_BLOCK]
    [+0x000] Status           : -1 [Type: long]
    [+0x000] Pointer          : 0xffffffff [Type: void *]
    [+0x008] Information      : 0x0 [Type: unsigned __int64]

But they are quite empty…

And since I’m not filtering any I/Os where can I be using a FLT_CALLBACK_DATA ?
Without Driver Verifier it goes to shutdown normally (no BSOD or freezes).
If anybody has ever encountered this message … any help appreciated !

(I also registered some callback in pDriverObject->MajorFunction to communicate with the driver, but I don’t think it can come from this).

Thank you.

And you absolutely don’t have a IRP_MJ_CONTROL callback registered? Sounds very fishy.

What is the IOCTL being sent? I’d also chase up the thread in question (if there is one) and see if that suggests anything.

I think that the !fldkd windbg extension will help you a lot. It will tell you what FltMgr thinks is going on and fltkd.cbd will even find the IRP for you

FWIW I have never seen this before - which adds to my “very fishy” comment, because the obvious causes are also filtered out by verifier earlier (if you set up the completion context and do not have a post call registered for instance)

Perfect ! Thank you so much.

!fltkd.cbd gave me the answer :

kd> !fltkd.cbd FFFFCA039BE5FC08

IRP_CTRL: ffffca039be5fb20  SHUTDOWN (16) [00000002] FastIo
Flags                    : [10000004] DontCopyParms FixedAlloc
DeviceObject             : ffffca03964b95d0 "\Device\HarddiskVolume2"
[... more stuff here ...]

When I said that I didn’t register any Pre-op and Post-op I lied, not on purpose obviously, I registered a pre and post but there were transparent/generic.
The pre-op returned FLT_PREOP_SUCCESS_WITH_CALLBACK, and I registered it for the IRP_MJ_SHUTDOWN. This was the problem it should not returned this code.

Again, thank you :slight_smile:

I was going to say that (no callback) is not possible, because
FltRegisterFilter would have failed already :slight_smile:

Kind regards, Dejan Maksimovic.
FS Lead:

@Dejan_Maksimovic said:
I was going to say that (no callback) is not possible, because
FltRegisterFilter would have failed already :slight_smile:

Kind regards, Dejan Maksimovic.
FS Lead:

It is definitely possible. You probably shouldn’t do that and at least register unload callback but code like this works:

return FltRegisterFilter(driver, &fltReg, &minifilter);

Peculiar, I went with the OperstionCallbacks having just the end marker and
that fails.