Virtual PNP Device

NTDEV
1

Hi all, I want to create a “virtual PNP device” that looks exactly like a plug-in USB dongle to the operating system, except that there’s no physical hardware.

I want to “simulate” PNP events into and out of this device, so in other words, I will have something happening somewhere else in the system, that will result in a “Surprise Removal” event to this (virtual) device.

My question is, can I somehow finagle the PNP manager into handling this device, or does it actually have to be enumerated on a physical (hardware) bus in order for that to happen?

2

A root enumerated device is what you want, although root enumerated devices cannot be surprise removed. Is the driver you are loading expecting to talk to a usb device? Or is usb just an example?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@advancedbionics.com
Sent: Wednesday, November 24, 2010 10:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Virtual PNP Device

Hi all, I want to create a “virtual PNP device” that looks exactly like a plug-in USB dongle to the operating system, except that there’s no physical hardware.

I want to “simulate” PNP events into and out of this device, so in other words, I will have something happening somewhere else in the system, that will result in a “Surprise Removal” event to this (virtual) device.

My question is, can I somehow finagle the PNP manager into handling this device, or does it actually have to be enumerated on a physical (hardware) bus in order for that to happen?

NTDEV is sponsored by OSR

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

3

I recommend that you read the toaster example in DDK.

2010/11/25

> Hi all, I want to create a “virtual PNP device” that looks exactly like a
> plug-in USB dongle to the operating system, except that there’s no physical
> hardware.
>
> I want to “simulate” PNP events into and out of this device, so in other
> words, I will have something happening somewhere else in the system, that
> will result in a “Surprise Removal” event to this (virtual) device.
>
> My question is, can I somehow finagle the PNP manager into handling this
> device, or does it actually have to be enumerated on a physical (hardware)
> bus in order for that to happen?
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

4

Doron Holan wrote:

–> A root enumerated device is what you want, although root enumerated devices
cannot be surprise removed. Is the driver you are loading expecting to talk to
a usb device? Or is usb just an example?

Yes, thank you Doron. The driver I have is expecting to talk to a USB device. The device that it was written for is fairly complex, but I only really need a tiny part of its functionality, and the part that I need does not require an actual physical device (the information could live in a set of registry entries, or anywhere else), except that there is some pretty intricate logic that apparently is designed to ensure a synchronous series of events during PNP events like surprise-removal.

When you say that “root enumerated devices can not be surprise-removed”, what exactly do you mean? Let me amplify that question two different ways: firstly, wouldn’t it be possible to have some other driver just “create” a PNP surprise removal IRP and pass it in to my driver, thereby “simulating” a real PNP surprise-removal? And secondly, what happens if I just “surprise-remove” some other non-USB piece of hardware, like let’s say I suddenly unplugged a DMA-capable card from my PCI bus backplane, what kinds of events/activity would I expect my driver to see in that case?

5

> firstly, wouldn’t it be possible to have some other driver just “create” a PNP surprise removal IRP and pass it in to my driver, thereby “simulating” a real PNP surprise-removal?
No.
You cannot just send pnp state changing irps to a device. Only the pnp manager can send pnp state changing irps b/c only it has the lock to guarantee serialization of those requests.

And secondly, what happens if I just “surprise-remove” some other non-USB piece of hardware, like let’s say I suddenly unplugged a DMA-capable card from my PCI bus backplane, what kinds of events/activity would I expect my driver to see in that case?
The bus you yank your card from must support surprise removal. IIRC, PCI by itself does not support surprise removal, you need to have either an express card or a special chassis.

I really don’t see why surprise removal is really that important that the driver sees it, but if you insist on it, create a root enumerated bus driver (use the KMDF toaster bus sample,statbus or dynambus) and then enumerate a PDO for your virtual usb device. You can fake all the URB processing you want in the PDO and when you want it to disappear, you just report the PDO as missing and the child stack gets surprise removed.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@advancedbionics.com
Sent: Monday, November 29, 2010 12:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual PNP Device

Doron Holan wrote:

–> A root enumerated device is what you want, although root enumerated
–> devices
cannot be surprise removed. Is the driver you are loading expecting to talk to a usb device? Or is usb just an example?

Yes, thank you Doron. The driver I have is expecting to talk to a USB device. The device that it was written for is fairly complex, but I only really need a tiny part of its functionality, and the part that I need does not require an actual physical device (the information could live in a set of registry entries, or anywhere else), except that there is some pretty intricate logic that apparently is designed to ensure a synchronous series of events during PNP events like surprise-removal.

When you say that “root enumerated devices can not be surprise-removed”, what exactly do you mean? Let me amplify that question two different ways: firstly, wouldn’t it be possible to have some other driver just “create” a PNP surprise removal IRP and pass it in to my driver, thereby “simulating” a real PNP surprise-removal? And secondly, what happens if I just “surprise-remove” some other non-USB piece of hardware, like let’s say I suddenly unplugged a DMA-capable card from my PCI bus backplane, what kinds of events/activity would I expect my driver to see in that case?

NTDEV is sponsored by OSR

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

6

xxxxx@advancedbionics.com wrote:

The driver I have is expecting to talk to a USB device. The device that it was written for is fairly complex, but I only really need a tiny part of its functionality, and the part that I need does not require an actual physical device (the information could live in a set of registry entries, or anywhere else), except that there is some pretty intricate logic that apparently is designed to ensure a synchronous series of events during PNP events like surprise-removal.

The WDK contains the Device Simulation Framework that might be of help
here. It lets you create a simulation of a device that does not yet exist.

When you say that “root enumerated devices can not be surprise-removed”, what exactly do you mean? Let me amplify that question two different ways: firstly, wouldn’t it be possible to have some other driver just “create” a PNP surprise removal IRP and pass it in to my driver, thereby “simulating” a real PNP surprise-removal?

That will tell your DEVICE there has been a surprise removal, but the
PnP subsystem won’t know anything about it. It will still think your
device is alive and well. PnP is a delicate dance between the operating
system and a number of different driver components.

And secondly, what happens if I just “surprise-remove” some other non-USB piece of hardware, like let’s say I suddenly unplugged a DMA-capable card from my PCI bus backplane, what kinds of events/activity would I expect my driver to see in that case?

Think about how a surprise removal happens. A bus driver is the entity
that initiates things. It notices, through some hardware mechanism,
that a device has disappeared. It then calls
IoInvalidateDeviceRelations to tell PnP that there has been a change.
PnP will then send the bus driver an IRP_MN_QUERY_DEVICE_RELATIONS
request, asking it to enumerate all of its child devices. PnP compares
that list to the list it had previously received, and notices that
someone went missing. THAT’S what triggers the surprise removal
notification to your driver. It isn’t just a single message.

PCI is not a “hot-pluggable” bus, so the standard PCI bus driver does
not look for devices to disappear. If you unplug a PCI board, you will
generally trigger a bus fault and a blue screen.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

> If you unplug a PCI board, you will generally trigger a bus fault and a blue screen.

Well, on the normal low-end PC operation like that is more than likely to result in electrical damage to the machine
(and, probably, to the user as well). However, I wonder how things work on high-end servers that allow you to go as far as dynamically adding/removing CPUs and IOAPICs to/from the running system (at least according to ACPI Specs)…

Anton Bassov

8

xxxxx@hotmail.com wrote:

(and, probably, to the user as well). However, I wonder how things work on high-end servers that allow you to go as far as dynamically adding/removing CPUs and IOAPICs to/from the running system (at least according to ACPI Specs)…

It’s quite possible for a high-end vendor to provide their own PCI bus
driver that understands hot-plugging and reports to PnP. Mark probably
has some knowledge of some of that, having spent a good portion of his
life in the extreme high-availability world.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

> (and, probably, to the user as well)

+5 V is unlikely to cause damage to the user.

Usual PCI/PCI Express is not hot plug and can damage the card/motherboard, but there are hotplug PCI implementations.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

10

Hot add cpus yes, hot remove, not so easy.

The systems I worked on kept the top of the PCI root bridge intact
while allowing the lower parts of the bridge to come and go. IOAPICs
were not hot plugged, nor were processors. However we struggled
through three major releases of Windows getting various pci devices
that never expected to go away to behave correctly. It was lots of
fun. By Server 2008 most of the inbox stuff worked correctly.

If you have specific questions let me know.

Mark Roddy

On Tue, Nov 30, 2010 at 1:32 PM, Tim Roberts wrote:
> xxxxx@hotmail.com wrote:
>>
>> (and, probably, to the user as well). However, I wonder how things work on high-end servers that allow you to go as far as dynamically adding/removing CPUs and IOAPICs to/from ?the running system (at least according to ACPI Specs)…
>
> It’s quite possible for a high-end vendor to provide their own PCI bus
> driver that understands hot-plugging and reports to PnP. ?Mark probably
> has some knowledge of some of that, having spent a good portion of his
> life in the extreme high-availability world.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

11

You might think differently if you have ever seen a 5v 35A rail get shorted out by a gold wedding ring. :slight_smile:
Surviving the burn is easy. Surviving the thrashing from the bride when explaining why you have vaporized the symbol of her unending love …

From: xxxxx@storagecraft.com
Subject: Re:[ntdev] Virtual PNP Device
Date: Thu, 2 Dec 2010 19:52:59 +0300
To: xxxxx@lists.osr.com

> (and, probably, to the user as well)

+5 V is unlikely to cause damage to the user.

Usual PCI/PCI Express is not hot plug and can damage the card/motherboard, but there are hotplug PCI implementations.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

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

12

Hmm, let me see now … I’ve seen 1/4 watt resisters turn cherry red and simply disappear, power-supplies literally blow-up in my face and provide a rain of confettie on my desk from the rupturing cans, and managed to go blind a time or two when the screw driver provided a brilliant blue white arc as I touched the wrong thing, but I must admit facing the wife with a melted wedding band is something I would prefer not to have ever done.

Gary Little

----- Original Message -----
From: “Dave Cattley”
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 2, 2010 11:48:27 AM
Subject: RE: [ntdev] Virtual PNP Device

You might think differently if you have ever seen a 5v 35A rail get shorted out by a gold wedding ring. :slight_smile:
Surviving the burn is easy. Surviving the thrashing from the bride when explaining why you have vaporized the symbol of her unending love …

> From: xxxxx@storagecraft.com
> Subject: Re:[ntdev] Virtual PNP Device
> Date: Thu, 2 Dec 2010 19:52:59 +0300
> To: xxxxx@lists.osr.com
>
> > (and, probably, to the user as well)
>
> +5 V is unlikely to cause damage to the user.
>
> Usual PCI/PCI Express is not hot plug and can damage the card/motherboard, but there are hotplug PCI implementations.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> 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

—
NTDEV is sponsored by OSR

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

13

Mm… did you ever touch an antenna while it’s transmitting? It works the same way a microwave oven cooks a roast - from the inside out! By the time you feel any pain, your finger is already charred and smoking. (Don’t know what brought that thought on, maybe it was the bit about the wedding band…)

Thank you everyone, for the helpful information and thoughts you’ve posted. The description of IoInvalidateDeviceRelations() led me to another question, which I’ll add here in context rather than starting a whole new thread:

What happens when someone (an app) has a valid handle to a device, that it opened via the device’s interface - and then the device driver disables the interface?

If it were an ordinary scenario I would expect that if a device simply “goes away” it will result in INVALID_HANDLE_VALUE being returned from a read, write, or device i/o control.

But this situation is different - here, the device is still there and still functioning, it’s just that its interface has been removed (so presumably no one “new” can open it thereafter).

14

xxxxx@advancedbionics.com wrote:

What happens when someone (an app) has a valid handle to a device, that it opened via the device’s interface - and then the device driver disables the interface?

If it were an ordinary scenario I would expect that if a device simply “goes away” it will result in INVALID_HANDLE_VALUE being returned from a read, write, or device i/o control.

But this situation is different - here, the device is still there and still functioning, it’s just that its interface has been removed (so presumably no one “new” can open it thereafter).

A device interface is just a way to FIND a device. It is an
advertisement that you offer certain services. It doesn’t affect
whether or not users can ACCESS the device. Typically, the device
interface isn’t disabled until the device is actually shutting down, but
you typically do not shut down a device while there are open handles.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

15

The handle of course remains valid until closed. New IO requests
should fail (for simple app to device stacks), but if there are no new
IO requests, there will be no IO errors to inform an application that
the device has problems, and no reason for the application to close
its handle, unless the application registered for PnP notification.

It is remarkably routine for systems in actual use to stall pnp
surprise removal because some application has not closed a handle.

Mark Roddy

On Thu, Dec 2, 2010 at 6:27 PM, Tim Roberts wrote:
> xxxxx@advancedbionics.com wrote:
>> What happens when someone (an app) has a valid handle to a device, that it opened via the device’s interface - and then the device driver disables the interface?
>>
>> If it were an ordinary scenario I would expect that if a device simply “goes away” it will result in INVALID_HANDLE_VALUE being returned from a read, write, or device i/o control.
>>
>> But this situation is different - here, the device is still there and still functioning, it’s just that its interface has been removed (so presumably no one “new” can open it thereafter).
>
> A device interface is just a way to FIND a device. ?It is an
> advertisement that you offer certain services. ?It doesn’t affect
> whether or not users can ACCESS the device. ?Typically, the device
> interface isn’t disabled until the device is actually shutting down, but
> you typically do not shut down a device while there are open handles.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

16

> A device interface is just a way to FIND a device. It is an

advertisement that you offer certain services. It doesn’t affect
whether or not users can ACCESS the device. Typically, the device
interface isn’t disabled until the device is actually shutting down, but
you typically do not shut down a device while there are open handles.

Yes. Which makes the “device interface” pretty useless for security, right?

And, isn’t that the whole reason they said they were forcing us to use
“device interfaces” in the first place? For security?

Any first-year system administrator can easily see the problem in this
scenario, right?

“Your credentials are valid till the next time you try to open the device,
or as long as you don’t close it - whichever comes LAST”. Duh. :wink:

I never did buy all that “we’re giving this to you because of security” stuff.
But hey, what do I know, I’m just a programmer.

17

xxxxx@advancedbionics.com wrote:

Yes. Which makes the “device interface” pretty useless for security, right?

Yes.

And, isn’t that the whole reason they said they were forcing us to use
“device interfaces” in the first place? For security?

Not in the slightest. That’s never been a goal of device interfaces, as
far as I know. Further, no one is forcing you to use device interfaces
at all.

People want to talk to their devices (naturally). To do that, the
device has to have a name. The traditional way to assign a name was to
create a symbolic link, \.\MyDevice.

That has two major problems. First, it fails if you have two or more
instances. So, people tack on a number. Now you have \.\MyDevice0 and
\.\MyDevice1. This causes its own set of problems; if I have device 0,
1, and 2, and device 1 goes away, now the set of device numbers is not
contiguous. A user-mode program can’t just start at 0 and query the
devices. Instead, you have to have some upper limit (10? 99? 255?) and
try them all. Does a new device fill in the hole, or just append to the
end? These are awkward decisions.

Second, it causes collisions. How many drivers out there use the
symbolic link “MyDevice”? How many use “PciDrv”? It can’t be predicted.

Those are the problems that device interfaces solve. With a device
interface, I can create a GUID that no one else will use. I can create
multiple devices that come and go at will, and the operating system will
manage the set for me. My user mode applications just use the
(admittedly verbose) SetupDi APIs to enumerate through all of the
devices that support my device interface.

Further, I can use the device interface like a COM interface. I might
have two or three different “capability sets” that my devices support,
and a driver can enable the ones that apply to that particular instance.

The device interface and the symbolic link are both mechanisms for
getting a file name to open. The security for that “open” process is up
to the device.

I never did buy all that “we’re giving this to you because of security” stuff.
But hey, what do I know, I’m just a programmer.

Where did you read that? I’ve never seen that mentioned as an attribute
of device interfaces.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

18

Device interfaces have nothing to do with security, they have as much to do with security as symbolic links (b/c they are really the same thing). The underlying device object that registers the device interface is what sets the security on its stack, the device interface is just a way to find the stack. Device interfaces were added so that finding a device stack did not involve fixed names and interating over them (COM1, COM2, etc) without knowing when to stop (COM99?) or if there were holes in the namespace (COM2, COM4 exist, but not COM3). They also provide the ability to be notified dynamically when they arrive (RegisterDeviceNotification) as well as having the driver which registers it able to send async messages to anyone who has registered for those notifications (WM_DEVICECHANGE, DBG_CUSTOMEVENT)

Security in windows is evaluated when you create the handle to the secure object. Once granted, it is not checked again.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@advancedbionics.com
Sent: Friday, December 03, 2010 3:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual PNP Device

A device interface is just a way to FIND a device. It is an
advertisement that you offer certain services. It doesn’t affect
whether or not users can ACCESS the device. Typically, the device
interface isn’t disabled until the device is actually shutting down,
but you typically do not shut down a device while there are open handles.

Yes. Which makes the “device interface” pretty useless for security, right?

And, isn’t that the whole reason they said they were forcing us to use “device interfaces” in the first place? For security?

Any first-year system administrator can easily see the problem in this scenario, right?

“Your credentials are valid till the next time you try to open the device, or as long as you don’t close it - whichever comes LAST”. Duh. :wink:

I never did buy all that “we’re giving this to you because of security” stuff.
But hey, what do I know, I’m just a programmer.

NTDEV is sponsored by OSR

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

19

wrote in message news:xxxxx@ntdev…
>
> And, isn’t that the whole reason they said they were forcing us to use
> “device interfaces” in the first place? For security?

The story about device interfaces is related to security, rather indirectly.
To make this story short… MS promotes using devinterfaces because
the device object that you open by devinterface names is always the PDO
of the stack.
Security on PDOs can be easily set, either in the INF at install time,
or in the registry, or inherited from the setup class.

But the stack can consist of several drivers, each of them can assign
different names and security to their device objects.
So if you use “legacy” name to open the device, you can land to random
device object of some filter, with bogus security settings.
To minimise possibility of this, MS advices to use devicenterfaces,
and leave other thinghs in the stack unnamed.
Security-wise this is worth as much as any other MS commandment.

–pa

20

“Pavel A.” wrote in message news:xxxxx@ntdev…
> wrote in message news:xxxxx@ntdev…
>>
>> And, isn’t that the whole reason they said they were forcing us to use
>> “device interfaces” in the first place? For security?
>
> The story about device interfaces is related to security, rather
> indirectly.
> To make this story short… MS promotes using devinterfaces because
> the device object that you open by devinterface names is always the PDO
> of the stack.
> Security on PDOs can be easily set, either in the INF at install time,
> or in the registry, or inherited from the setup class.
>
> But the stack can consist of several drivers, each of them can assign
> different names and security to their device objects.
> So if you use “legacy” name to open the device, you can land to random
> device object of some filter, with bogus security settings.

Here’s example: look at the recent thread “Device object usage”.

p.

> To minimise possibility of this, MS advices to use devicenterfaces,
> and leave other thinghs in the stack unnamed.
> Security-wise this is worth as much as any other MS commandment.
>
> --pa