KMDF Filter Driver

device driver

    Sponsored Links


  • 1. DispatchReadWrite problem
    are there any side effects using that Method?
  • 2. WDK - new driver framework
    Trying to understand what DDK or WDK really is.... I was thinking WDK or DDK as the compiler & linker for driver code we develop. All other components that our drivers depend upon are dependent on OS. For example, calling my driver entry point, enumerating my driver stack, handling the IO requests passed down, allocating Irp when requested etc. With new framework, that idea is confusing. For example, driver entrypoint is little different, power management is different etc. Is this new framework applicable only for new OS Windows Vista or we can develop new framework driver for Windows XP and windows 2000. As far as I understand, we can use new framework for XP also. How is it possible to use it on XP target PC when new framework was not released by the time XP was released. How will IO manager and other OS components understand new frame work. Is it lot of internal work that goes on if we compile with WDK that can somehow convert finary binary to fit particular OS. All I am trying to understand is line between DDK/WDK and OS? Is DDK more than compiler and linker? Thanks, Raj
  • 3. Smart Card USB Reader (CCID) Driver Problem
    Hello, I develop Smart Card USB Reader device that compatible CCID class. The device has unremovable smart card, therefore interrupt pipe is not needed according CCID class specification. Regrettably the Microsoft CCID driver works incorrect with my device when the interrupt pipe is not implemented. When the device has interrupt pipe, all work correct. Does Microsoft CCID driver support CCID class devices without interrupt pipe? Does Microsoft CCID drivet incompatible CCID class specification? (Driver version 5.2.3790.2444 from 5/17/2005) Thank you in advance, Vlad ( XXXX@XXXXX.COM )
  • 4. list of drivers
    Hi all, I need to know what each and every driver in /devices does, is there a list for this?
  • 5. Linker issues Trying to use STL std:: map using DDK builds
    HwDecoderBase.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ) referenced in function "public: __thiscall std::_Tree<int,struct std::pair<int const ,int>,struct std::map<int,int,struct std::less<int>,class std::allocator<int> >::_Kfn,struct std::less<int>,class std::allocator<int> >::~_Tree<int,struct std::pair<int const ,int>,struct std::map<int,int,struct std::less<int>,class std::allocator<int> >::_Kfn,struct std::less<int>,class std::allocator<int> >(void)" (??1?$_Tree@HU?$pair@$$CBHH@std@@U_Kfn@?$map@HHU?$less@H@std@@V?$allocator@H@2@@2@U?$less@H@2@V?$allocator@H@2@@std@@QAE@XZ) I know what the problem is:: its looking for the LOCKIT class which is defined in xlock.cpp but then xloxk.cpp refers to another hearder file which defined critical sections and mutex objects which arent quite relevant in kernel mode. anyone got around this problem ? thanks.

KMDF Filter Driver

Postby Unlhbg » Sun, 14 Sep 2008 08:08:00 GMT

In creating the control device for a filter driver (KMDF) that sits on top of 
a USB driver, I decided that I want to keep around the control device as long 
as there were any open file handles for that control device (in this filter 
driver there is only one control device for all possible USB devices the 
filter driver is sitting over). Behaving in this manner makes it so that when 
the last device is unplugged and then re-inserted while an application file 
handle is referencing the control device, there are no symbolic name 
conflicts from trying to recreate the control device and communications to 
the control device can go on as normal (although it reports no devices 
attached during that period). The only odd part about this is that if you 
unplug the last device and then call CloseHandle on the file handle, the 
control device is correctly destroyed in my EvtFileClose but the driver is 
not unloaded. You have to plug in the device and then unplug it again to get 
the driver to unload. Other than being strange, this does not appear to be 
causing any problems in the system. Does anyone see any problems with doing 
it this way or is there a better way to do this?


Re: KMDF Filter Driver

Postby Tim Roberts » Sun, 14 Sep 2008 13:09:25 GMT

This is simply The Way It Works.  There was a long thread on the ntdev
mailing list about this earlier this year.

The basic issue is that you end up with a strange mix between a PnP and a
non-PnP driver here; the driver is PnP, but the control object is not.
Unloading would usually happen when the last file handle was closed for the
PnP device object, but PnP can't do that because there's still a handle
open on the control object.  When you close the last handle on the control
object, PnP isn't involved because it's not a PnP device, so no one
triggers the removal process.

The only issue is that it's inconvenient, because it means you need to
reboot to replace the driver.
Tim Roberts,  XXXX@XXXXX.COM 
Providenza & Boekelheide, Inc.

Re: KMDF Filter Driver

Postby chris.aseltine » Wed, 17 Sep 2008 01:11:03 GMT

One solution proposed on NTDEV (and noted as novel by Doron) was to
add a root enumerated HWID in the INF for your USB driver (and then
set up your driver to behave accordingly if it is sitting on top of a
root-enumerated PDO).

Then, if you close the control device but the driver is still loaded,
just bring up an instance of the root-enumerated PDO, and then bring
it down again.  Then PNP will unload your driver.

Re: KMDF Filter Driver

Postby Unlhbg » Wed, 17 Sep 2008 01:46:07 GMT

Thanks for pointing me in this direction - I think Matthew Carter's post 
summed it up best:

Re: Control Device Inhibits Unload

The solutions I've thought of and heard of to work around the problem are: 

1) implement a PnP device to use for receiving control messages instead of a 
control device so all devices are PnP 

2) implement a dummy PnP device to go along with your control device just so 
that you'll have a PnP device that can be shut down last so the PnP manager 
will properly unload 

3) stall the last filtered device from being removed right away when PnP 
requests it, send an order to your control application to immediately release 
the handle it holds, wait the handles to the control device to close, then 
remove it before the last PnP device 

4) make seperate drivers to control the PnP filtered devices and non-PnP 
control devices so that you don't end up with one driver with both PnP and 
non-PnP devices. 

I think pretty much all of those solutions have been suggested by people in 
this thread. Implementing any one of those solutions adds quite a bit of 
complexity to what otherwise might have been a very simple and 
straightforward filter driver. All of them require PnP code that normally may 
not be needed except #4, which has its own extra requirements of inter-driver 
communication and needing one driver to load the other. Instead of any of 
those I just kinda learn to live with it. If the situation does come up where 
the control device is the last to shut down then the driver gets stuck in 
memory, but if one of the devices starts again the same driver stuck in 
memory will handle it, so its not a situation where you have a memory leak 
that takes away more and more memory each time the driver is run. 

The only real problem with having the driver stuck there in memory is that 
if the user tries to update the driver, he will have to reboot the whole 
computer. A driver package that can unload and replace itself in all 
situations without requiring the user to reboot feels much more professional 
than one that can't so I can understand the desire to achieve that, and I 
share that desire, but in my own simple filter driver designs I just couldn't 
justify the additional complexity required to make it happen. 

I have decided not to concern myself over it - it would be a rare case and 
doesn't cause any technical errors even in those conditions. It seems like 
the extra effort to get it to unload at the correct time brings very little 
value to the driver.


Similar Threads:

1.KMDF filter driver not loading in safe boot mode

We have several filter drivers using KMDF, and we noticed that under Windows 
XP SP2 they fail to load when you boot in safe mode. Seems that wdf01000.sys 
is not loaded in safe mode, causing the filter driver to not load. Issue is 
not present in Vista.

Was able to fix this issue by adding the following registry key: 

Is this a known issue? Was not able to find any information on Microsoft, 
but seems that some other people had the same issue.

Thanks for any help,


2.Bluescreen when we try to attach a filter to another device stack in KMDF

Let me start by saying, I know this is the wrong way to do things, but 
it was the only hack we could figure out with MS's help in the pre-Vista 
days for working around the extremely quirky behavior of installing PS/2 
filter drivers (since 2k, the OS "conveniently" removes any existing 
filters when you do this... even if you tell it not to in the INF).

Basically, we have a PS/2 mouse filter driver that needs to dynamically 
create a filter on the *keyboard* driver stack. We've carefully analyzed 
that we are guaranteed to do this at the right time to avoid problems 
with stack depth and the like.

We may end up needing to find a way to reliably install ourselves as a 
PNP filter on the keyboard stack (without disturbing any other filters 
or losing ours if one is installed after us... groan... this takes a 
very delicate use of CoInstallers and wishing real hard that other 
keyboard driver installers were written well). But this is a big 
redesign, and Win7 is fairly imminent.

What I need in the mean time is a workaround for this problem.

A summary of what we're doing: we're creating a KMDF control device, 
first using WdfControlDeviceInitAllocate and WdfFdoInitSetFilter; then 
we're activating the "Great Escape" by calling 
WdfDeviceInitAssignWdmIrpPreprocessCallback. Finally, we WdfDeviceCreate 
it, and attach it to the keyboard stack.

Using a trivial passthrough PreprocessCallback gets around the problem 
that KMDF control devices don't have PNP handling code in them, and 
therefore can't normally be attached to PNP driver stacks.

Anyway, all is good in Vista and even Win7, up until WLK 1.4, which 
insists on using the 1.9 KMDF coinstaller, which in turn necessitates 
using the 1.9 KMDF itself (we were using 1.7, but of course, 1.9 will 
get picked up automatically at some point anyway).

In KMDF 1.9, it appears that some code changed that bluescreens when WDF 
Verifier is turned on (as *also* required for the first time by the 1.4 
WLK). The proximate location for this is WdfFdoInitSetFilter, but we've 
tried taking that out (and even manually setting that bit ourselves as 
an experiment), and it only postpones the problem until later.

A !analyze -v is attached at the bottom.

Any suggestions?



*                        Bugcheck Analysis 

Unknown bugcheck code (0)
Unknown bugcheck description
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

  ERROR: Could Not Find Target OS Version.  Please Update 
GetFunctionForOSVer to include target OS Version


8287022c cc              int     3

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 8287022c (nt!DbgBreakPoint)
    ExceptionCode: 80000003 (Break instruction exception)
   ExceptionFlags: 00000000
NumberParameters: 3
    Parameter[0]: 00000000
    Parameter[1]: 84aab4c0
    Parameter[2]: 00000000

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A 
breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more 
arguments are invalid







LAST_CONTROL_TRANSFER:  from 855957f6 to 8287022c

80e4aaf8 855957f6 82c126ee 92eb4470 0000fffe nt!DbgBreakPoint
80e4ab0c 8c8fd216 8d950508 8c1b0030 80e4abfc 
80e4ab1c 8c8fcadc 8c1b0030 00000000 84aab4c0 
[t:\tools\winddk\7100.0\inc\wdf\kmdf\1.9\wdffdo.h @ 295]
80e4abfc 8c9066fd 00000000 00000000 0000000b 
[c:\source\driver\kernel\winnt\lib\cntdevice.cpp @ 333]
80e4ac38 829ce55e 80e4acac 8c961d08 92eb4470 
[c:\source\driver\kernel\winnt\share\os\coskbfilter.cpp @ 604]
80e4ac78 8299f4cd 80e4acac 80e4aca0 00000000 
80e4acd8 829d4e86 92f2b3d4 80e4acf8 8db75ce0 
80e4ad00 8286d2f7 8db75ce0 00000000 84aab4c0 nt!PnpDeviceEventWorker+0x1e3
80e4ad50 829e420d 00000001 05a4e960 00000000 nt!ExpWorkerThread+0x10d
80e4ad90 82887dd9 8286d1ea 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


[t:\tools\winddk\7100.0\inc\wdf\kmdf\1.9\wdffdo.h @ 295]
8c8fd216 5d              pop     ebp

    291:     PWDFDEVICE_INIT DeviceInit
    292:     )
    293: {
WdfFunctions[WdfFdoInitSetFilterTableIndex])(WdfDriverGlobals, DeviceInit);
 > >  295: }
    297: //
    298: // WDF Function: WdfFdoInitSetDefaultChildListConfig
    299: //
    300: typedef


SYMBOL_NAME:  SynTP!WdfFdoInitSetFilter+16

FOLLOWUP_NAME:  MachineOwner




FAILURE_BUCKET_ID:  0x0_VRF_SynTP!WdfFdoInitSetFilter+16

BUCKET_ID:  0x0_VRF_SynTP!WdfFdoInitSetFilter+16

Followup: MachineOwner

3.Problem with uninstall of KMDF mouse filter driver

4.USB device upper filter in KMDF sending URBs to device PDO directly

Hello All:

I am writing a USB device upper filter in KMDF which will filter few
IOCTLs calls and send vendor specific controls requests
(synchronously) to the device PDO bypassing the FDO. I see that I can
accomplish this by getting the WDM physical device object and then
creating and sending the URBs to this object in old WDM way.

What I wanted to know is, can I do this using KMDF USB functions ?  Or
is it possible to get a IO Target for the  pdo?

Any directions or pointers or welcome.

Thanks in advance.



I'm working on a class filter driver but to start I have installed the
filter as a device upper filter on a device of the class that I am to
filter on  (both have services installed at boot time).  It works fine
as a device upper filter with the exception that in the registry key I
have noticed that it sets INITSTARTFAILED to 1 for the enum key of the
service (i.e. .../System/CurrentControlSet/Service/myService/Enum).
However the count is 1 as is the nextInstance.  I thought that if the
service truly did fail that the count would be zero?  The filter driver
installed correctly as it does what it is supposed to do.  Furthermore,
setting a breakpoint on my driver entry results in the behavior
expected (registers my device add and everything).

It works as far as I can tell except for the INITSTARTFAILED that is
set.  I have deleted the key and the next time I boot it is back again.

I think this may be a problem because when I try and have the filter be
a class filter driver, I get an INACCESSIBLE_BOOT_DEVICE (7b)

I just want to make sure this INITSTARTFAILED doesnt' have anything to
do with this... In order to make the filter a class filter I have added
to the key corresponding to the class guid in
currentcontrolset/control/classs with UpperFilters myFilt.  I have also
tried putting in a CoInstallers32
wdfcoinstaller01005.dll,WdfCoInstaller since when I installed the
filter as a device filter it put those values in the device instance
key (am I missing something else?)

So I guess I really have two questions

1.  Anyone know why INITSTARTFAILED would be set to 1, but yet load the
service and it function properly?

2. Anyone know if for a CLASS filter driver if there are any other
values I have to set besides the UpperFilters in the registry key for
the class?

Thanks in advance!

6. Difference of FS filter and mini-filter driver

7. TDI filter: filtering NETBIOS data

8. How to add filter DO on an PDO in a bus filter driver

Return to device driver


Who is online

Users browsing this forum: No registered users and 2 guest