Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Filter Verifier complaining about a completion context
Hello,
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
FLTMGR!_FLT_CALLBACK_DATA
+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.
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Internals & Software Drivers | 19-23 June 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
Comments
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
!fldkdwindbg extension will help you a lot. It will tell you what FltMgr thinks is going on andfltkd.cbdwill even find the IRP for youFWIW 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 :
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
FltRegisterFilter would have failed already
Kind regards, Dejan Maksimovic.
FS Lead: http://www.alfasp.com
It is definitely possible. You probably shouldn’t do that and at least register unload callback but code like this works:
extern "C" NTSTATUS DriverEntry(PDRIVER_OBJECT driver, PUNICODE_STRING)
{
FLT_REGISTRATION fltReg{ sizeof(fltReg), FLT_REGISTRATION_VERSION };
return FltRegisterFilter(driver, &fltReg, &minifilter);
}
that fails.