This does not work for a pnp driver, the sc and underlying SCM APIs can only install a pnp driver, they do not start/stop it. I would recommend you write a second driver, an NT4/legacy driver that can be start/stopped by the SCM APIs and can load without underlying hardware. You can use WDF to implement the driver. If your user mode DLL is going to load/unload the driver, the calling process must have the load driver privilege enabled (essentially it must be running as admin and elevated)
d
Now I have a new task where existing applications should be able to use our own API calls even if none of of our own cards is installed,
but instead there’s some 3rd party PCI card installed which provides a similar functionality. Of course the 3rd party PCI card has
its own driver, which is loaded automatically, and the 3rd party driver exports some functions at the kernel level which could be
imported and called by my own mbgclock driver to access the 3rd party device.
I would say that your approach is totally wrong in itself…
I think the best thing to do here is to put all your “proprietary” API (i.e. the one deals with an app) into an upper filter driver, rather than in the one for a physical device FDO. Your filter will register a named standalone control device object that is not on any stack so that your app is in a position to send IOCTLs to this device. In response to these IOCTLs, your filter will send a request down the stack that its filter DO is attached to.
If you take this approach you will be able to use your proprietary API with any card of a given class, no matter if it is actually your card or some third-party one with a similar functionality. Simple,ugh…
on old Windows NT without PnP support it was possible to start (load) or stop (unload) a kernel service/module from the command
line to let it check if a supported device was detected.
It is still possible to do it with a non-PnP driver (i.e the one that does not implement AddDevice() and, instead, creates DOs in its DriverEntry() routine). However, as it has been pointed out already, it cannot be done with a PnP driver, so that it does not apply in your case…
Anton Bassov
This does not work for a pnp driver, the sc and underlying SCM APIs can only install a pnp driver, they do not start/stop it.
You are right. If we have AddDevice (probably) then we have error 1058. Never tried this before.
I would recommend you write a second driver, an NT4/legacy driver that can be start/stopped by the SCM APIs and can load without underlying hardware.
Or just make some registry setting to skip AddDevice initialization in DriverEntry. But second separate driver is more robust solution, of course.
into an upper filter driver
How do you insert your filter into not your device stack? It’s not standard action, AFAIK.
How do you insert your filter into not your device stack? It’s not standard action, AFAIK.
You don’t “insert” anything anywhere. What you do is writing a PnP upper filter driver, and installing it as the one with the Device Manager. Its corresponding .INF file must specify that it has to be installed as an upper filter for the target driver’s( which, in this particular case, happens to be written by you as well, because it actually interfaces your physical device) FDO. The rest will ensue automatically. When the target stack gets set up your AddDevice() routine will get invoked. This routine will create a DO, and attach it to the device that happens to be on top of the stack at the moment.
Or just make some registry setting to skip AddDevice initialization in DriverEntry.
You don’t do it this way - you either write a PnP driver or a “legacy” one. In the former case you have, at the very minimum, to implement AddDevice() and IRP_MJ_PNP handler, provide an .INF file, and install it with the Device Manager. In the latter one you have different possibilities, but you have to create at least one device object in DriverEntry(). Otherwise, the system is going to unload your driver immediately after its DriverEntry() has returned control.
Anton Bassov
@anton_bassov said:
How do you insert your filter into not your device stack? It’s not standard action, AFAIK.
installing it as the one with the Device Manager. Its corresponding .INF file must specify that it has to be installed as an upper filter for the target driver’s( which, in this particular case, happens to be written by you as well, because it actually interfaces your physical device) FDO.
Never hear that. Did you test this yourself? On what OS? Because early PnP platforms don’t support this, AFAIK.
P.S. And, of course, link to documentation highly welcome.
All,
thanks for your thoughts which brought up some new aspects.
I’m going to do some tests and see which will be the best solution for me.
Never hear that.
Never heard of what? Of the roles of the devices in a PnP stack (i.e PDO - lower_filter(s) - FDO -upper_filter(s)) ? Of these roles being specified in the Registry settings? Or of the fact that you are not supposed to mess around with these settings manually and, instead, have to provide an INF file that gets installed by the Device Manager?
Judging from everything that you have said on this thread in so far, it looks like you have to learn A LOT (which is perfectly fine)…
Did you test this yourself? On what OS? Because early PnP platforms don’t support this, AFAIK.
Well, I don’t really know what you mean by “early PnP platforms”, but, IIRC, it worked this way at least as early as under Windows NT 5.0.
In fact, I am almost sure that it worked this way since the advent of PnP to the NT world, but I cannot confirm it from the personal experience, so that I am going to refer to NT 5.0 (a.k.a Windows 2000) as to a starting point in order to avoid putting a foot in my mouth yet another time…
P.S. And, of course, link to documentation highly welcome.
At the risk of provoking “The Hanging Judge’s” (and not only his) wrath, I would highly recommend Walter Oney’s WDM book. Although it is hopelessly outdated and does not promote WDF ( by the virtue of predating it by almost a decade), I would say it is, probably, one of the best sources for anyone who wants to understand PnP - it covers PnP roles of the devices, and describes an .INF file in a great detail.
Therefore, I would highly recommend it as an educational source, although, certainly, not as a hand-on guide for writing Windows drivers in the year 2019…
Anton Bassov
Walter Oney’s WDM book
Beware… it’s power management discussions were out of date and incorr ct when the book was published.
Peter
Back to the OP’s request, if you don’t mind.
What if the PCI (PnP) driver is also installed for a root enumerated device (via same or separate INF).
It will load for the root enumerated device even when PCI instances are not present, and stay loaded
as long as you want.
It can then create helper control devices for the application, register for arrival of 3rd party devices etc.
Of course, the driver should support loading on a fake device without resources.
What is the best way to handle these 3rd party devices - by filtering or otherwise - is hard to tell
not knowing details.
– pa
it’s power management discussions were out of date and incorr ct when the book was published.
According to Doron, not all PM issues were fully understood at the time even at MSFT. Incredibly enough, but, according to him, the subsequent code review had discovered that NONE(!!!) of the existing at the time in-box drivers was handling it properly. Therefore, it would be VERY surprising if a book written in the year 2001 was 100% correct in this respect.
Certainly, using it as a driver writer’s guide would be pretty unwise in the year 2019. However, I think that for someone who has “never heard” of either PnP roles of the devices in PnP stack or of .INF files this book is, probably, the best source of info…
Anton Bassov
What if the PCI (PnP) driver is also installed for a root enumerated device (via same or separate INF).
It will load for the root enumerated device even when PCI instances are not present, and stay loaded as long as you want.
In fact, if you want a driver that is not on the target device’s stack, it does not really need to be a PnP one - you can easily get away with a “legacy” one that gets started via SCM. I would rather suggest an upper filter, but a driver that is not in the same stack is fine as well.
The main point is that all the “proprietary” stuff that is exposed to the userland has to be placed into a separate hardware-agnostic driver and not in the one that actually drives the target device. As long as the OP does it this way everything is going to be just fine…
Anton Bassov
At the risk of provoking “The Hanging Judge’s” (and not only his) wrath, I would highly recommend Walter Oney’s WDM book.
Unlike you i read this book carefully more than one and a half decade ago.
“Installing a Device Filter for an Existing Device”
“Microsoft hasn’t provided a way to install a filter driver for an existing device. The problem you face when you try to do this is determining the name of the hardware key in the registry, and there’s no general way to do that.”
That’s why i asked “Because early PnP platforms don’t support this, AFAIK.”
And my asking is NOT pure academic because in one of my project i definitely have to do exactly this thing.
Unlike you i read this book carefully
Fair enough - you seem to have found one more minor inconsistency in it that I have simply overlooked. More on it below
“Microsoft hasn’t provided a way to install a filter driver for an existing device. The problem you face when you try to do this is determining > the name of the hardware key in the registry, and there’s no general way to do that.”
As it turns out, the book was a bit imprecise not only in respect of PM at the time when it was published - IIRC, both SetupDixxx() functions and InstallHinfSection() were available at the time it was published.However, please note that it was targeting both NT and Win9X at once, so that we can excuse Mr.Oney for having had overlooked certain OS-specific caveats …
That’s why i asked “Because early PnP platforms don’t support this, AFAIK.”
And my asking is NOT pure academic because in one of my project i definitely have to do exactly this thing.
There are different ways of doing what you want. The most obvious ways to go are described in the following article
https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/using-an-inf-file-to-install-a-file-system-filter-driver
They require an .INF file.
Otherwise, you can do everything manually. Assuming that your target OS supports SetupDiGetClassDevs(), SetupDiGetDeviceRegistryProperty() and SetupDiSetDeviceRegistryProperty() you can use these functions to modify the UpperFilters or LowerFilters keys for the device you want to filter. You also have to copy your driver to the system folder, and to create the corresponding service registry entry with SCM API (i.e CreateService()) . Although it may sound a bit “scary”, the whole thing is, in actuality, pretty straightforward…
Anton Bassov
@anton_bassov said:
There are different ways of doing what you want. The most obvious ways to go are described in the following article
https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/using-an-inf-file-to-install-a-file-system-filter-driverThey require an .INF file.
This is not filter for DEVICE.
Otherwise, you can do everything manually. Assuming that your target OS supports SetupDiGetClassDevs(), SetupDiGetDeviceRegistryProperty() and SetupDiSetDeviceRegistryProperty() you can use these functions to modify the UpperFilters or LowerFilters keys for the device you want to filter. You also have to copy your driver to the system folder, and to create the corresponding service registry entry with SCM API (i.e CreateService()) . Although it may sound a bit “scary”, the whole thing is, in actuality, pretty straightforward…
Once again. Unlike you i wrote such code in 2005.
But I’m still waiting the example of installing filter driver for existing device through Device Manager (or some other standard way) by using .INF:
What you do is writing a PnP upper filter driver, and installing it as the one with the Device Manager. Its corresponding .INF file must specify that it has to be installed as an upper filter for the target driver’s
Once again. Unlike you i wrote such code in 2005.
Thats enough, children. We are (actually have already been for a while) veering off in the wrong direction here.
Mr. SweetLow, you’re new here and you have tried to be helpful to others in several instances, so I’ll patiently explain the rules: Stop the ad hominem attacks. Mr. Bassov was answering questions in this forum years before you got here, occasionally even being helpful (though it’s hard to remember), probably while you were still so studiously reading Mr. Oney’s magnum opus.
I’m not sure WTF you’re arguing about here. INFs can make arbitrary registry mods… you can definitely install a filter with an INF. I did it Friday.
I’m absolutely in favor of arguing the rightness or wrongness of implementation details. Go for it. And we definitely do have posters who assert things that are incorrect, and about which they have no personal knowledge (one of my own hot buttons), and they need corrected. So, while I’m all for giving another poster a sound beating, it’s got to by demonstrating overwhelming mastery of the technical details. This is the 21st Century and the September That Never Ended was a long time ago, whether we all like it or not.
Peter
This is not filter for DEVICE.
Well, what this doc describes is InstallHinfSection() call that can be done either on the command line
(RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 132 path-to-inf\infname.inf) or from a dedicated setup application.
This call assumes that your .INF file has a DefaultInstall section, which means that you can right-click-install it. Although you cannot use this section with a service associated with a devnode, still you can use this function to install a class filter driver. …
Once again. Unlike you i wrote such code in 2005.
Well, if “unlike me” you were writing such code in 2005, how come that you still don’t know that AddDevice() is not the kind of thing that can get toggled by some registry switch, and that drivers implementing this function cannot get started by StartService()? Just a thought…
But I’m still waiting the example of installing filter driver for existing device through Device Manager
(or some other standard way) by using .INF:
WEll, I have to admit that it was the year 2007 when I saw the Windows screen the last time, so that my recollection of it may be already “not-so-fresh”, so to say…
Anton Bassov
SweetLow wrote:
But I’m still waiting the example of installing filter driver for existing device through Device Manager (or some other standard way) by using .INF:
Until Windows 10, there was no way to do such a thing using an INF. A
device filter was installed using software that created a service entry
and then called the SetupDi APIs to modify the appropriate key in the
registry. That method still works. But in Windows 10, we now have the
concept of an “extension INF” that allows you to add upper and lower
filters and set additional registry entries to an existing device. I do
not know if this is considered a “PnP driver package” in signature
terms. It certainly makes the PnP job more challenging, because it has
to scan through ALL of the packages in the driver store, remember all of
the ones that matched, and call them in the appropriate order.
Peter,
Mr. SweetLow, you’re new here and you have tried to be helpful to others in several instances, so I’ll patiently explain the rules:
Stop the ad hominem attacks.
Well, I have to admit that it was me and not Mr/Ms. SweetLow who first assumed the condescending tone. To be honest, I was just set off by the assertion that AddDevice() might be arbitrarily toggled on and off in the registry settings,effectively switching between PnP and SCM service types. My apologies to Mr/Ms. SweetLow
Mr. Bassov was answering questions in this forum years before you got here, occasionally even being helpful
(though it’s hard to remember),
You forgot to mention the fact that I am, apparently, the only list member whose every post had, at some point, to get approved by
“The Hanging Judge” himself (!!!) before making its way “to general public”…
Anton Bassov
@Tim_Roberts said:
SweetLow wrote:But I’m still waiting the example of installing filter driver for existing device through Device Manager (or some other standard way) by using .INF:
But in Windows 10, we now have the
concept of an “extension INF” that allows you to add upper and lower
filters and set additional registry entries to an existing device.
Thanks, Mr. Roberts.
@anton_bassov said:
Well, I have to admit that it was me and not Mr/Ms. SweetLow who first assumed the condescending tone. To be honest, I was just set off by the assertion that AddDevice() might be arbitrarily toggled on and off in the registry settings,effectively switching between PnP and SCM service types. My apologies to Mr/Ms. SweetLow
Ok. I know that our tone isn’t the tone of scientific discussion, so i apologies to you and site owner.
@“Peter_Viscarola_(OSR)” said:
I’m not sure WTF you’re arguing about here.
Portability of different solutions, of course:
SweetLow wrote:
Because early PnP platforms don’t support this, AFAIK.