There is a well-defined and supported mechanism for filtering IRPs in a device stack: a filter driver. That way, you become part of the device stack, so you get notified any time something happens, and things all come up and shut down in an orderly way.
You mean IoAttachDeviceToDeviceStackSafe(âŚ) function? I can attach with this function to all device objects in another driver. But this function needs device object which is part of target driver. But in my case the device object has not been created yet. My goal is to capture the moment when the device object was created. Is there a better way to do what I want? If yes, can you direct me on where to look?
First of all, thank you for your comment. It does not mean that I do not follow your advice. Iâm doing this because Iâm looking for a way out. I noticed that WDM is lower level than other driver models and KMDF covers WDM. Am I wrong? Like MFC with Win32. I think the best way to learn the basics is to try to understand with WDM.
After understanding how things happen in the background, I prefer to write KMDF. If I find a ready solution for my current problem, I would delay my learning process and prefer KMDF again. I dont insist on WDM.
You are actually going about it backwards. Learn KMDF first, it is the
standard for kernel and user mode driver development. After you have
acquired a basic working knowledge of how to write a WDF driver, exploring
WDM apis is fine.
OP, You donât have an AddDevice function in your DriverEntry().
As other said, donât spend time on WDM unless you want to brain tease yourself. If you do, consider starting with a working example like toaster. Not sure if they still have it in DDK.
Hi Returning to the problem itself, as I mentioned before, I tried to understand windows driver examples and KMDF projects and did research. But I couldnât find a solution. (This does not mean that there is no solution.) Since I could find a more understandable source about wdm, I proceeded through wdm. There is no other reason. I want to summarize what I want to do again. When any device is plugged into the USB, I want to capture and attach device object of this device as soon as it is created. I donât want to make a distinction about these devices right now. I would be very pleased if you say that this can be done in acceptable ways in kmdf. Regards.
My goal is to capture the moment when the device object was created. Is there a better way to do what I want?
I TOLD you. Write a PnP filter driver. When you do that, the kernel will load your driver automatically for every new device that is created. Doing a filter driver is not just about which APIs you call. Itâs about marking yourself in the registry so the operating system handles the details for you. KMDF makes filter drivers almost trivially easy.
I noticed that WDM is lower level than other driver models and KMDF covers WDM. Am I wrong?
Only partially. It is true that KMDF is built on top of WDM, but thatâs almost entirely irrelevant. KMDF fixed things that are nearly impossible in WDM. KMDF manages the annoying details that everyone got wrong. It has been said that there has NEVER been a WDM driver that handles power management correctly until KMDF came along. Their state machine for handing PnP and Power events has hundreds of states.
No GUI programmer would think of doing a C++ Windows app direct to the API any more. Everyone uses MFC or WTL or Windows Forms, because those are provably better ways of doing things. The KMDF situation is very similar.
When any device is plugged into the USB, I want to capture and attach device object of this device as soon as it is created.
There is essentially nothing you can do that applies generically to all USB devices. You will only cause yourself pain. However, making yourself an upper filter to your USB hub devices would allow you to do this.
It has been said that there has NEVER been a WDM driver that handles power management correctly until KMDF came along.
Well, many things âhave been saidâ on this planet. The trick here is to filter the very obvious hype and nonsense, and to allow only those statements that may have at least some theoretical chance of being plausible, âdown the stackâ. If this filtering criteria was applied here,
the above âassertionâ (which was, indeed, made quite a few times in this NG) would have never stood a slightest chance, and would have been immediately discarded simply as âyet another ridiculous claim that one may hear from our usual suspectsâ by the topmost filter
in the stack right on the spot. However, as one can see, it gets repeated again and and again and again, for some reason.
Letâs imagine for a moment that this assertion is, indeed, true. It automatically implies that ABSOLUTELY all system-provided stacks, class drivers, bus drivers including ACPI.sys, and all other in-box drivers in existence that had been released before the advent of KMDF,
were âgetting it wrong all the wayâ.
This, in turn, makes one wonder how Win2K and Windows XP managed to run not only without causing widespread fires and explosions, but even without damaging the hardware on more or less regular basis (please note that we are speaking about the PM stuff here)âŚ
Your ability to troll a thread astounds me, even after all these years, you know that?
I donât know who authored the phrase about which you object, but it could have been me. And regardless, I stand by it as being a useful, if perhaps ever so slightly exaggerated, rubric.
Having BEEN there when KMDFâs PnP and Power State machine was being developed (and donât forget our own Mr. Holan is one of the primary designers and developers of this work), I can tell you that nobody⌠NOBODY⌠had EVER taken the considerable time and effort required to figure out how the complete PnP and Power state machine should work before KMDF. I remember one specific occasion standing in the hallway with Mr. Oshins and (I think) Mr. Holan, looking at a diagram of the huge, evolving, PnP/Power state machine on the wall, discussing one particular state (I donât remember what it was). None of us knew what should be done at that point. I remember one of the devs going down the hall to ask the guy who owned Power (I think) at the time exactly what he expected to happen, while we waited. He came back with the answer. And so it progressed through many, many, states.
It is a fact that I have never seen (prior to KMDF) a WDM driver (in-box or 3rd party) that handles PnP and Power via a State Machine. OSR is the only author that I am aware of that has always written PnP/Power code this way. This failing, by itself, almost guarantees getting the implementation wrong.
An even casually competent engineer will understand that there is a world of difference between an implementation being âcorrectâ and an implementation working well enough âmost of the time.â Clearly, the in-box WDM drivers handled PnP and Power right âmost of the time.â That does not make them correct.
Continue to troll, as you do. But at least try a little harder to make arguments that arenât so obviously ignorant.
While I donât have the insider knowledge that Peter had, I was at the Driver Developer Conference where they showed the state machines. They were huge. One of the comments in the presentation was that a number of drivers were getting some of their more major holes fixed now that there was a model for âdoing it rightâ.
So, Anton, Microsoft acknowledged years ago that there were significant holes in their implementation, why do you think you can get it right by yourself?
So, Anton, Microsoft acknowledged years ago that there were significant holes in their implementation, why do you think
you can get it right by yourself
OMGâŚ
I am DEFINITELY not saying anything like that. If you bother yourself with checking my very first statement on this thread, you will see that I am asking âWhy do you want to write a WDM driver in the year 2020,in the first place???â
The only thing that I am saying is that the assertion that I was/is arguing about is a very obvious (at least from my perspective) example of unnecessary hype. I am most certainly not saying that someone should try writing a PnP driver in WDM when WDF is available, which would be a very stupid thing indeedâŚ
I was/is arguing about is a very obvious (at least from my perspective) example of unnecessary hype
Actually, the more I think about it, I would assert that the statement âthere has NEVER been a WDM driver that handles power management correctly until KMDF came alongâ is either literally correct, or so very close to being literally correct that itâs not worth arguing.
Regardless of the statementâs literal correctness, consider the conclusions one is asked to come to from this statement. Among them:
In the days of WDM, drivers had enormous problems with PnP/Power handling â PnP/Power was The Number One problem pre-KMDF. That and IRP cancellation, actually, vie for first place in the pantheon of âWhy WDM drivers crash.â This is true regardless of whether the drivers were in-box or third party provided.
The KMDF team solved this problem by creating The Definitive State Machine for handling PnP/Power. Creating this was a lot of work, and took vast amounts of âinsiderâ resources (Windows source code, access to the dev owners of multiple components).
It is folly for anyone to think that they fully understand Power Management/PnP from the WDM perspective without having similar knowledge to that of the KMDF devs, or an understanding of The Definitive State Machine. And without such knowledge, how could an entirely âcorrectâ WDM driver be developed? I GUESS if you had a monkey and a keyboard and waited LONG enough it might happen at random EVENTUALLYâŚ
It is foolish to write a device driver that supports PnP/Power today using WDM, if WDF can be used for the purpose.
This, in turn, makes one wonder how Win2K and Windows XP managed to run not only without causing widespread
fires and explosions, but even without damaging the hardware on more or less regular basis âŚ
Maybe you werenât monitoring the forums at the turn of the century, when people were starting to try Win2K and early XP on laptops. The experience was not positive, in large part because drivers were Doing It Wrong.
The server experience was much better, of course, because such systems rarely get any power activity.
I think i am going on the right way. Are there any sources other than msdn that you can recommend to me? (e-books, class, article etc.)
Thatâs a good place to start. Itâs impossible to tell how much experience you have. Clearly, you were good enough with the mechanics to get a simple driver to run, but what youâre missing is design and philosophy. A key part of living in the kernel ecosystem is understanding how drivers are connected to each other to make up a stack, and how you can participate in that stack in a tested and well-ordered way.
OSR has a âlearning libraryâ of articles on drivers theyâve collected over the decades. An OSR driver class would never be a bad idea. There are books on WDF/KMDF, although a lot of them focus on mechanics as well. Back issues of OSRâs NT Insider are a good resource.
Your ability to troll a thread astounds me, even after all these years
Well, I do what I can
An even casually competent engineer will understand that there is a world of difference between an implementation
being âcorrectâ and an implementation working well enough âmost of the time.â
Well, I donât really know about you, but on my books. the very phrase "an implementation working well enough most of the time "
is just a very obvious euphemism for a âheisenbugâ, i.e for a buggy software that mostly works as expected but may fail
in some edge cases, while a âcorrectâ program is the one that works as expected in 100% cases. Please note that being âcorrectâ does not necessarily imply being optimal, but the results a correct program produces are correct and 100% predictable. This is what makes it different from the one that ""works well enough most of the timeâ.
In context of this discussion, a âcorrect but not optimalâ implementation of ACPI driver would imply, for example, not taking the full advantage of the laptop batteryâs capabilities, while "working well enough most of the time " one would imply, for example, occasional CPU resets (I mean abrupt and unpredictable resets, rather than âpoliteâ BSODs) due to overheating at the very minimum, and, probably, even occasional damage caused to the hardware in more extreme cases.
Clearly, the in-box WDM drivers handled PnP and Power right âmost of the time.â That does not make them correct.
So were they âcorrect but not optimalâ or "working well enough most of the timeâ?
try a little harder to make arguments that arenât so obviously ignorant.
Well, as you can see it yourself, I try my best to provide a technically sound argumentation, while some other posters prefer
to stay on âad hominem sideâ
Hi Tim < Itâs impossible to tell how much experience you have. 17 Thank you for your help. I also thank everyone else who wants to help. For now, I will move away from the forum and work on the subject. I will try to progress with your suggestions. There will probably be other things I would like to ask you. See you till then. Best Regards.
Iâm sure we miss the point by just deriding Anton.
Well, Marion, in fact, the only one who really missed the point here is Truly Yours.
This point is eternal and truly universal. It stands as âDonât argue with those who are in a position to pull the plug outâ, and I keep on missing this point all my life longâŚ