KMDF Filter Driver

device driver

    Sponsored Links

    Next

  • 1. netvmini.sys still not working on Windows 7 even after driver signing disabled ?! (Windows debug mode necessary for debug drivers ???)
    Hello, I installed the netvmini.sys "debug/checked" driver on Windows 7 x64. I learned how to deactive "driver signing enforcement" during boot of Windows 7 x64. Now I boot into Windows 7 and the virtual network adapters are present in connection settings and such. They have IPv4 and IPv6 bindings and such and local area network addresses. I open the "test program". They ("Microsoft Virtual Ethernet Adapter") show up in the list. I try to sent "IOCTL"'s to them but it says: "Failed read". "Failed write". I suspect this might be because I booted into "normal mode". Maybe checked/debug drivers only work in "windows debug mode" ??? I shall now attempt to: 1. Boot Windows 7 x64 RTM in debug mode. and 2. Disable driver signing. and 3. Test again to see if this helped ?! Bye, Skybuck.
  • 2. VMware tray icon: unknown network, windows 7: no network access kinda weird ?!
    There is still one little thing irritating me... The VM tray icons have an exclamation mark... complaining about "unknown network" and network properties says: "no network access" ? Also something asked me if I wanted to create some kind of network or something... I didn't have time to look into it at that moment and I simplied pissed it off but entering some stupid network name without reading wtf I was doing... So I am not sure if that has anything to do with it... If so... how to remove stupid network groups or whatever ??? ^ Weird ^. It's not a big deal.. it's just a bit weird. Bye, Skybuck.
  • 3. How to remove "Microsoft point to point adapter" ?
    Hello, I "accidently" installed "Microsoft point to point adapter"... I am not sure what this is... maybe some kind of tunneling thingy... I thought like I am gonna try it out... But it doesn't show up in any windows controls ? It only shows up in some kind of test program. I think it might be intefering with other drivers/settings... so the big question is: 1. How do I remove "Microsoft point to point adapter" ? and optionally: 2. Is it part of the default system or not ? (Can I safely remove it ?) (If it's not part of default system then I think it would be safe...) (I think it's not part of the default system... I think I installed it...) Bye, Skybuck.
  • 4. Hardware ERROR ?!?!?
    C:\Documents and Settings\Administrator>ping 192.168.0.61 Pinging 192.168.0.61 with 32 bytes of data: Hardware error. Hardware error. Hardware error. Hardware error. That's supposed to be the VMware connection 1. Computers are assigned as follows: Local Area Network connection: 192.168.0.1 VM network connection1: 192.168.0.61 VM network connection8: 192.168.0.68 Windows 7 Guest in VM: 192.168.0.67 Netmask all: 255.255.255.0 Why can't this work ? Also why must the internet have stupid network masks ?!? Isn't the ip just enough... ?!? Anyway can this configuration work like this under normal circumstances/vm ware usage ? Maybe something got damaged... I remove Microsoft Point to Point Adapter from Windows 7. Not sure if it was there before... Maybe I should add it back to see if it helps... I will do so now.. Bye, Skybuck.

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?

Thanks,
Ryan


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:

<quote>
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. 
</quote>

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.

Thanks,
Ryan

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: 
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\WdfLoadGroup

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,

Olivier

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?

Thanks,

Ray


*******************************************************************************
* 
       *
*                        Bugcheck Analysis 
       *
* 
       *
*******************************************************************************

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
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


PROCESS_NAME:  System

FAULTING_IP:
nt!DbgBreakPoint+0
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

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  84aab4c0

EXCEPTION_PARAMETER3:  00000000

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x0

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 855957f6 to 8287022c

STACK_TEXT:
80e4aaf8 855957f6 82c126ee 92eb4470 0000fffe nt!DbgBreakPoint
80e4ab0c 8c8fd216 8d950508 8c1b0030 80e4abfc 
Wdf01000!imp_WdfFdoInitSetFilter+0x6e
80e4ab1c 8c8fcadc 8c1b0030 00000000 84aab4c0 
SynTP!WdfFdoInitSetFilter+0x16 
[t:\tools\winddk\7100.0\inc\wdf\kmdf\1.9\wdffdo.h @ 295]
80e4abfc 8c9066fd 00000000 00000000 0000000b 
SynTP!CntDevice::InitializeControl+0x1ec 
[c:\source\driver\kernel\winnt\lib\cntdevice.cpp @ 333]
80e4ac38 829ce55e 80e4acac 8c961d08 92eb4470 
SynTP!CosKBFilter::PnPNotifyInterfaceChange+0xbd 
[c:\source\driver\kernel\winnt\share\os\coskbfilter.cpp @ 604]
80e4ac78 8299f4cd 80e4acac 80e4aca0 00000000 
nt!PnpNotifyDriverCallback+0x107
80e4acd8 829d4e86 92f2b3d4 80e4acf8 8db75ce0 
nt!PnpNotifyDeviceClassChange+0x159
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


STACK_COMMAND:  kb

FOLLOWUP_IP:
SynTP!WdfFdoInitSetFilter+16 
[t:\tools\winddk\7100.0\inc\wdf\kmdf\1.9\wdffdo.h @ 295]
8c8fd216 5d              pop     ebp

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


SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  SynTP!WdfFdoInitSetFilter+16

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: SynTP

IMAGE_NAME:  SynTP.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a1dbf33

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.
Bala

5.KMDF Class Filter Drive INITSTARTFAILED

Hi,

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 0 guest