Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
This just plain and simple isn’t supported. Seriously. The OS has no provision to allow you to safely enumerate and/or interrogate memory pages that you do not own.
Peter
DigiCert can go burn in hell. I checked on them 9 years ago, and again 6 years ago, and again 3 years ago, and again now, and each time their price has doubled. And this for a product that has ZERO dollars of incremental cost to them. It really burns me up. It shows an ugly mercenary streak and a cavalier disregard for their customer base. I'll never buy a DigiCert product again. I use GlobalSign.
You OUGHT to be worried about compatibility, and I don't think we know the answers.
So any idea how can i find the port driver of a given miniport?
I think you are still unclear on the concept. What are you expecting here? You cannot reach the port separate from the miniport. The two do not exist as separate entities. There is no such thing as a "port device object" -- that's just not how it works. If you want to send IRPs to the port, you sent them to the port/miniport pair. If you want to send IRPs to the miniport, you send them to the port/miniport pair. That's all there is.
If the port driver is only loaded as an export driver, there is no driver object.
First of all, thanks ThatsBerkan, I'll give it a try!
2Peter_Viscarola_(OSR) and Don_Burn: Much worse than malware, but a security product. Also, I don't get it - malware or not, this forum is devoted to system development, drivers etc. My question is valid, so what's the point? Do you think driver development is VIP club or something? Do you really want to keep 'simple mortals' in a dark while looking with superiority from your Ivory Towers? This is not gonna work guys. You can't hide knowledge, just delay its spread.
I've split Mr. @DavidXanatos question/issue into a separate topic in NTDEV...
and I've closed this thread on the base issue, which is MSFT's impending policy that will prevent drivers on systems other than Win10 from being updated without passing WHQL.
If there are other questions on the base issue, folks can post them wherever and we can discuss whether we should re-open this thread.
Peter
Can this thread just quietly end now? Please?
I think Mr @Mark_Holiday has gotten as much help from us this specific issue as he’s likely to get. If he has additional questions, let him ask in a separate thread.
But we’re going in circles at this point.
Peter
How about just not registering the device interface for your PDOs. This is effectively a private device object that you’re using. Just don’t call WdfDeviceCreateDeviceInterface. Open the device from your app(s) by name. Problem solved.
Peter
But I am still confused as to what you need. These UM components obviously communicate via network protocols now right? It could be TCP or UDP or CDP, but it is some kind of network protocol, or else there would be no use in a virtual NIC - they couldn't use it unless they use the winsock APIs somehow
Windows has support for bridging interfaces in box since at least Vista IIRC, so just making a bridge driver would be a waste of time
if the IP spaces conflicted, it would be far cheaper to buy a router and program a hairpin NAT than to develop a driver like this
perhaps you want your PDC to stop using a network protocol? In that case, the sockets opened by the other UM processes would have to terminate in your driver, and you could then use inverted call to pass the data up to PDC. KM sockets are well understood and long supported, but the performance difference versus well (or even poorly) coded UM sockets is usually small and they are much more complex to work with (just as everything is harder in KM)
perhaps you want to multi-plex or proxy your PDC in some way? That might be reasonable, but I don't read that into anything you have said.
I'm intrigued, but confused