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

Yes it is possible to write a bus filter driver for usb. It is a lot of
work. KMDF does not support bus filter drivers, but with a bit of effort
you can use kmdf to do most of the work and then escape out of kmdf to do
the rest using WDM.

Mark Roddy

You need to open the handle as OVERLAPPED. A handle without OVERLAPPED will serialize IO requests at IO manager dispatching layer before it is sent to the driver.

a requirement to insert a VNIC between them

A "VNIC" that does WHAT, exactly? How do YOU define a VNIC?

How does the proverbial "10 line Python program" logically differ from your definition of a VNIC?

As we so very often say here: "What larger problem are you trying to solve?" Does A send socket traffic to B, which is on a different, pre-defined, IP Address? So, you want this VNIC to fake the IP address?? What is the problem that needs solving here?

Peter

No one is going to put Windows into embedded systems anymore,

Hmmm... I don’t know what you mean by this.

If you’re saying that this policy might cause folks to rethink their use of Windows Embedded... maybe. In many cases, moving to a new version of Windows in an embedded system is a Big Deal. If they view this policy as a violation of trust, then they might say “If we have to consider another version of the OS, we might as well consider a different OS and avoid getting screwed over like this in the future.”

I see that, for sure.

Peter

This is bad news... and it's serious.

In short: As of July 2021, Microsoft will no longer allow new releases of drivers to be cross-signed and loaded on Windows 7, Windows 8.1, or Windows Server 2012 R2 (including Windows Embedded 8 and Windows Embedded 8.1). You can read the policy here.

Folks have raised this issue several times here in this forum in the past. One of the most recent was Mr. Roddy in this thread. I have always urged posters not to worry, because I assumed that this policy would be "corrected" -- Apparently, I have been overly optimistic.

For more than a year, folks here at OSR have been been engaged with Microsoft over this issue. Our understanding (or, perhaps, it was simply our hope) was that this policy was going to be "fixed." Surely, we reasoned, Microsoft is not going to prevent us from releasing updated drivers for versions of Windows that are still supported by Microsoft. We heard rumors that Attestation Signing would be extended to cover versions of Windows prior to Windows 10.

Apparently we were mistaken. Despite all our efforts, we have been unable to identify ANY plan that'll allow folks to release updated drivers for versions of Windows prior to Windows 10.

So, as of July 2021, if you want to update a driver that runs on a Windows version other than Windows 10... forget it. You're screwed. And, worst of all, your customers are screwed.

According to Microsoft's published plans, the only way to update a driver for a version of Windows other than Windows 10 is to have that driver pass the HLK/WHQL tests. That is, assuming that your driver falls into a category where there are HLK tests. And your driver can pass those tests. There are many, many, drivers -- especially drivers for special-purpose systems -- that will never be able to pass the HLKs and have no reason or need to pass the HLKs.

I've written more about this here.

If we work together, we can get Microsoft to change this plan. This community has done it before.

Work your technical contacts. Get the message clearly presented to the folks you work with at MSFT.

Even more important, you must explain the problem to the managers at your company who regularly engage with MSFT. You must get your execs and your managers to raise this issue with their MSFT contacts.

Because if we don't change this policy, lots of Windows users are going to be put in very difficult positions.

The time to act is now, folks. Microsoft needs to hear from you and from your management team.

The clock is ticking...

You need to provide more details:

• How is the injected code mapped to the process?
• How do you try to get all the modules of the process in kernel space?
• What are you trying to do exactly?

The only place that contains "a list of modules" in a process is the loader database in user-mode which can be fetched by calling the Win32 (EnumProcessModules)

In kernel mode, as far as I know, other than maintaining your own list with the image load callback or hacky solutions like scanning the address space with ZwQueryVirtualMemory you won't be able to get the "loaded module list".

Unless you explain your intent, it's hard to answer your question.

I agree. The cost of C++ is not to the authors, but to the reviewers and maintainers.

I'm sorry, over the past 20+ years of doing this stuff debugging a driver written in anything other than C (no ++ variant) bleeds into a nightmare. Of course the caveat to this is if YOU wrote the driver. If you are debugging some other clients driver and they have implemented a perfectly written OO++ driver, it will take days of stepping through code, and reading their implementation, to understand what is happening. Just write it in C ... or assembly! My 2 cents ...