Hi all,
I am trying to develop a simple umdf filter driver to intercept messages between the device and the PC. Hence I would like to implement an upper filter on the device. However I am encountering problems trying to install the driver (standalone) at the top of the MTP stack.
I would be very grateful if anyone with experience on installing standalone umdf filter drivers can offer some assistance on this matter.
Thanks!!
Hi Sze,
Can you please post the logs in \windows\inf\setupapi.dev.log &c:\windows\setupact.log for the installation?
In order to install a UM filter driver for an MTP device, you’d need to the include/needs directives in your inf file as given in the link (http://msdn.microsoft.com/en-us/library/windows/hardware/ff597687(v=vs.85).aspx).
There is a thread (http://stackoverflow.com/questions/14359871/umdf-filter-driver-for-mtp-devices) where you can find a modified sample inf which can be used to install the sample (http://code.msdn.microsoft.com/windowshardware/umdffilterumdf-a0094c5e) as a upper filter to the MTP device.
Thanks
Sri Harsha
Hi Sri,
Thanks for your reply; I used dpinst to install the inf file instead, is there a difference? I did use the modified sample inf from the stackoverflow thread but the dpinst installation log says device not found and that it will install driver upon plugging in of device. However when I plugged in the device it installs the default Microsoft provided mtp and wpd drivers instead.
So I was told another way will be to edit the registry directly to reference to the driver but I can find very little on that subject. There is a thread about installing standalone filter driver on this forum but the it does not provide the details of how to do that. Do you think that editing registry is a good option?
Regards,
Sze
xxxxx@gmail.com wrote:
Thanks for your reply; I used dpinst to install the inf file instead, is there a difference? I did use the modified sample inf from the stackoverflow thread but the dpinst installation log says device not found and that it will install driver upon plugging in of device. However when I plugged in the device it installs the default Microsoft provided mtp and wpd drivers instead.
You can’t use DPInst to pre-install a filter driver, unless your INF
specifies ALL of the drivers that the device needs. If you think you
specified all of the drivers, then the most obvious explanation for that
is that the identifier in your INF file does not actually match your device.
So I was told another way will be to edit the registry directly to reference to the driver but I can find very little on that subject.
No, because installing a UMDF driver as a filter is somewhat tricky
business.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Thanks, that would explain why the device reinstalled its own drivers instead. So I will have to install the device drivers first and then install my filter driver on top of the device stack? How do I do that using Inf file?
Regards,
Sze
xxxxx@gmail.com wrote:
Thanks, that would explain why the device reinstalled its own drivers instead. So I will have to install the device drivers first and then install my filter driver on top of the device stack? How do I do that using Inf file?
Well, let’s take a step back.
Are you writing a class filter, or a device filter? The situations are
different. With a class filter, you install it once using either an
application or a non-PnP INF file, and then it will get loaded for every
device that comes around.
For a device filter, remember that each INF completely replaces the one
before it. You cannot “add on” to a PnP INF. There is no way to
pre-install an INF so that it automatically adds a device filter to
devices that get plugged in later. It cannot be done.
Now, you CAN write your own full INF that duplicates the original INF
and adds your filter. New arrivals would then use your replacement INF
instead of the original.
But if you need the device to use its original INF, then you need to
have an installer application to add your filter.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
As of now I am attempting to write a device filter but I wouldn’t mind doing a class filter for the entire MTP/WPD class. However I am under the impression that it is not possible to implement a user-mode class filter and I will have to do a kmdf filter instead; is this view accurate?
Duplicating the original INF sounds plausible; I will attempt to do that and see how it works out. Thank you!
Can I trouble you to elaborate on what is an installer application and what does it do? Would I have to write a driver installer?
xxxxx@gmail.com wrote:
As of now I am attempting to write a device filter but I wouldn’t mind doing a class filter for the entire MTP/WPD class. However I am under the impression that it is not possible to implement a user-mode class filter and I will have to do a kmdf filter instead; is this view accurate?
Duplicating the original INF sounds plausible; I will attempt to do that and see how it works out. Thank you!
Can I trouble you to elaborate on what is an installer application and what does it do? Would I have to write a driver installer?
Installing a kernel-mode device filter requires three steps:
KMDF adds an additional step to that, because you have to run the
co-installer. The NONPNP sample shows how to do that.
UMDF, however, adds yet another twist, because it needs more registry
entries. The OSRUSBFX2 sample in the WDK includes an INF that installs
a function driver PLUS a UMDF filter, although it doesn’t show how to do
the filter by itself. It is possible to do that.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
KMDF adds an additional step to that, because you have to run
the co-installer. The NONPNP sample shows how to do that.
Just a thought, now that XP is unsupported and Vista shipped out of the box with KMDF, is running the coinstaller still truly necessary?
If you know the version of KMDF you need will be on every machine you care about (and that you should care about) then you don’t need the coinstaller for KMDF.
If you want a newer version than the Vista baseline, then you do need the coinstaller.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, July 23, 2014 11:40 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF Filter for MTP/WPD Devices
Tim Roberts wrote:
KMDF adds an additional step to that, because you have to run the
co-installer. The NONPNP sample shows how to do that.
Just a thought, now that XP is unsupported and Vista shipped out of the box with KMDF, is running the coinstaller still truly necessary?
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
On 23-Jul-2014 21:39, xxxxx@gmail.com wrote:
Just a thought, now that XP is unsupported and Vista shipped out of the box with KMDF, is running the coinstaller still truly necessary?
/* Sadly, MS is the only company that doesn’t support XP …
All others are wherever the users are. */
Hi all,
Thanks for your replies. I managed to get the UMDF filter loaded following the registry tweaks as detailed in a previous thread by Tim (http://www.osronline.com/ShowThread.cfm?link=251699)
And also I have gotten the KMDF class filter up and running as well. This is via using the installer provided by the NT insider guide (http://www.osronline.com/article.cfm?article=446).